THE TEN COMMANDMENTS OF FORMAL METHODS The decision to use of formal methods in the real world is not one that is taken lightly.
25.6 THE TEN COMMANDMENTS OF FORMAL METHODS The decision to use of formal methods in the real world is not one that is taken lightly.
Bowan and Hinchley [BOW95] have coined “the ten commandments of formal meth- ods” as a guide for those who are about to apply this important software engineer- ing approach. 5
1. Thou shalt choose the appropriate notation. In order to choose effec- The decision to use
tively from the wide array of formal specification languages, a software engi- formal methods should
neer should consider language vocabulary, application type to be specified, not be taken lightly.
and breadth of usage of the language. Follow these
“commandments” and
2. Thou shalt formalize but not overformalize. It is generally not necessary
be sure that everyone to apply formal methods to every aspect of a major system. Those compo- has received proper
nents that are safety critical are first choices, followed by components whose training.
failure cannot be tolerated (for business reasons).
3. Thou shalt estimate costs. Formal methods have high startup costs. Training staff, acquisition of support tools, and use of contract consultants result in high first-time costs. These costs must be considered when examin- ing the return on investment associated with formal methods.
4. Thou shalt have a formal methods guru on call. Expert training and on- going consulting is essential for success when formal methods are used for the first time.
5. Thou shalt not abandon thy traditional development methods. It is
WebRef possible, and in many cases desirable, to integrate formal methods with con-
ventional or object-oriented methods (Chapters 12 and 21). Each has Useful information on
formal methods can be strengths and weakness. A combination, if properly applied, can produce obtained at
excellent results. 6
www.cl.cam.uk/ users/mgh1001
6. Thou shalt document sufficiently. Formal methods provide a concise, unambiguous, and consistent method for documenting system requirements. However, it is recommended that a natural language commentary accom- pany the formal specification to serve as a mechanism for reinforcing the reader’s understanding of the system.
5 This treatment is a much abbreviated version of [BOW95]. 6 Cleanroom software engineering (Chapter 26) is an example of an integrated approach that uses formal methods and more conventional development methods.
7. Thou shalt not compromise thy quality standards. “There is nothing magical about formal methods” [BOW95] and for this reason, other SQA activities (Chapter 8) must continue to be applied as systems are developed.
8. Thou shalt not be dogmatic. A software engineer must recognize that formal methods are not a guarantee of correctness. It is possible (some would say, likely) that the final system, even when developed using formal methods, may have small omissions, minor bugs, and other attributes that do not meet expectations.
9. Thou shalt test, test, and test again. The importance of software testing has been discussed in Chapters 17, 18, and 23. Formal methods do not absolve the software engineer from the need to conduct well-planned, thor- ough tests.
10. Thou shalt reuse. Over the long term, the only rational way to reduce soft- ware costs and increase software quality is through reuse (Chapter 27). For- mal methods do not change this reality. In fact, it may be that formal methods are an appropriate approach when components for reuse libraries are to be created.
Parts
» The Concurrent Development Model
» SUMMARY Software engineering is a discipline that integrates process, methods, and tools for
» PEOPLE In a study published by the IEEE [CUR88], the engineering vice presidents of three
» THE PROCESS The generic phases that characterize the software process—definition, development,
» THE PROJECT In order to manage a successful software project, we must understand what can go
» METRICS IN THE PROCESS AND PROJECT DOMAINS
» Extended Function Point Metrics
» METRICS FOR SOFTWARE QUALITY
» INTEGRATING METRICS WITHIN THE SOFTWARE PROCESS
» METRICS FOR SMALL ORGANIZATIONS
» ESTABLISHING A SOFTWARE METRICS PROGRAM
» Obtaining Information Necessary for Scope
» An Example of LOC-Based Estimation
» QUALITY CONCEPTS 1 It has been said that no two snowflakes are alike. Certainly when we watch snow
» SUMMARY Software quality assurance is an umbrella activity that is applied at each step in the
» R diagram 1.4 <part-of> data model; data model <part-of> design specification;
» SYSTEM MODELING Every computer-based system can be modeled as an information transform using an
» Facilitated Application Specification Techniques
» Data Objects, Attributes, and Relationships
» Entity/Relationship Diagrams
» Hatley and Pirbhai Extensions
» Creating an Entity/Relationship Diagram
» SUMMARY Design is the technical kernel of software engineering. During design, progressive
» Data Modeling, Data Structures, Databases, and the Data Warehouse
» Data Design at the Component Level
» A Brief Taxonomy of Styles and Patterns
» Quantitative Guidance for Architectural Design
» Isolate the transform center by specifying incoming and outgoing
» SUMMARY Software architecture provides a holistic view of the system to be built. It depicts the
» The User Interface Design Process
» Defining Interface Objects and Actions
» D E S I G N E VA L U AT I O N
» Testing for Real-Time Systems
» Organizing for Software Testing
» Criteria for Completion of Testing
» The Transition to a Quantitative View
» The Attributes of Effective Software Metrics
» Architectural Design Metrics
» Component-Level Design Metrics
» SUMMARY Software metrics provide a quantitative way to assess the quality of internal product
» Encapsulation, Inheritance, and Polymorphism
» Identifying Classes and Objects
» The Common Process Framework for OO
» OO Project Metrics and Estimation
» Event Identification with Use-Cases
» SUMMARY Object-oriented analysis methods enable a software engineer to model a problem by
» Partitioning the Analysis Model
» Designing Algorithms and Data Structures
» Program Components and Interfaces
» SUMMARY Object-oriented design translates the OOA model of the real world into an
» Testing Surface Structure and Deep Structure
» Deficiencies of Less Formal Approaches 1
» What Makes Cleanroom Different?
» Design Refinement and Verification
» SUMMARY Cleanroom software engineering is a formal approach to software development that
» Structural Modeling and Structure Points
» Describing Reusable Components
» SUMMARY Component-based software engineering offers inherent benefits in software quality,
» Guidelines for Distributing Application Subsystems
» Middleware and Object Request Broker Architectures
» An Overview of a Design Approach
» Consider expert Web developer will create a complete design, but time and cost can be appropriate
» A Software Reengineering Process Model
» Reverse Engineering to Understand Data
» Forward Engineering for Client/Server Architectures
» SUMMARY Reengineering occurs at two different levels of abstraction. At the business level,
Show more