400 likes | 847 Views
Formal Methods. CIS 376 Bruce R. Maxim UM-Dearborn. Levels of Rigor for Formal Methods. Informal manual reviews, inspections Low modeling using logical and discrete mathematics Medium formal specification language with type checking High
E N D
Formal Methods CIS 376 Bruce R. Maxim UM-Dearborn
Levels of Rigor for Formal Methods • Informal • manual reviews, inspections • Low • modeling using logical and discrete mathematics • Medium • formal specification language with type checking • High • fully formal specification language with rigorous semantics and proof checking
Necessary Mathematics • Set builder notation • Set operations • Logic operators • Sequence properties • order, domain, range • Sequence operators • concatenation, head, tail, front, last
Weaknesses of Less Formal Approaches - part 1 • Contradictions • statements do not agree with one another • Ambiguities • statements have more than one interpretation • Vagueness • specifications in large documents are often not written precisely enough
Weaknesses of Less Formal Approaches - part 2 • Incompleteness • e.g. failing to list limitations and error handling required of a function • Mixed levels of abstraction • occurs when very abstract statements are intermixed randomly with statements written at lower levels of detail
Why Consider Formal Methods? • Systems are increasingly dependent on software components • fault protection and safety are no longer allocated solely to hardware • software must be able to detect and isolate failures and then execute recovery scenarios • software systems fail in way different than hardware systems • Complexity of systems with embedded software has increase rapidly
Reliability and Traditional Methods • Maintaining reliability in software intensive systems is very difficult • Quality ceilings are encountered using traditional measures (which means that reliability asymptotically approaches some level considerably less than 100%) • New approaches seem to be needed to achieve increases in quality measures
Limitations to Formal Methods • Use formal methods as supplements to quality assurance methods not a replacement for them • Formal methods can increase confidence in a product’s reliability if they are applied skillfully • Useful for consistency checks, but formal methods cannot guarantee the completeness of a specifications • Formal methods must be fully integrated with domain knowledge to achieve positive results
Ten Commandments of Formal Methods - part 1 • Choose the appropriate notation • Do not over-formalize • Estimate costs • Have a formal methods guru on call • Do not abandon traditional development methods • Document sufficiently
Ten Commandments of Formal Methods - part 2 • Do not compromise quality standards • Do not be dogmatic in assuming formal specifications are flawless • Use of formal methods does not eliminate the need to test products • Reuse is still important
Choosing a Life Cycle Phase • Formal methods can be applied to all phase of the life cycle • The benefit-to-cost ratio seems highest for the specification and design phases • The makes sense because the earlier defect is removed the cheaper it will be to correct
Formal Methods and Specification Phase • This phase is the least automated and is not tightly coupled to specific languages or notations • Specification work products are less effectively analyzed that products from later phases • Using formal methods in this phase does not interfere much with other existing processes and can dramatically improve analysis capability
Benefits of Formal Specification - part 1 • Higher level of rigor leads to better problem understanding • Defects are uncovered that would be missed using traditional specification methods • Allows earlier defect identification • Formal specification language semantics allow checks for self-consistency • Enables the use of formal proofs to establish fundamental system properties and invariants
Benefits of Formal Specification - part 2 • Repeatable analysis allows reasoning to be checking by colleagues • Encourages and abstract view of the system, focusing on what a system should do rather than how to accomplish it • An abstract view of the system helps separate specification from design • Enhances existing processes by adding rigor
Formal Specification Methods • Formal specifications • Formal Proofs • Model Checking • Abstraction
Formal Specification • The translation of non-mathematical description (diagrams, table, natural language) into a formal specification language • It represents a concise description of high-level behavior and properties of a system • Well-defined language semantics support formal deduction about the specification
Formal Proofs • Provide a complete and convincing and convincing argument for validity of some system property description • Proofs are constructed as a series of small steps, each of which is justified using a small set of rules • Eliminates the ambiguity and subjectivity inherent when drawing informal conclusions • Proofs can be done manually, but they usually constructed with some automated assistance
Model Checking • Checking is operational rather than analytic • The finite state machine model of a system is expressed in a suitable language • A model checker determines if the finite state model satisfies the requirements expressed as formulas in a given logic • The basic method is to derive a computational tree from the finite state machine model and explore all plausible execution paths
Abstraction • The process of simplifying or ignoring irrelevant details • Allows you to focus on and generalized the most important central properties and characteristics • Helps to avoid premature commitment to design and implementation choices
Using Formal Methods • Define the data invariant, state, and operations for each system function • Specification is represented in some set theoretic type notation from some formal language • Specification correctness can be verified using mathematical proofs
Review of Terms • data invariant • a condition true throughout execution of function that contains a collection of data • state • defined by the stored data accessed and altered by a particular function • operations • system actions that take place when data are read or written to the state • precondition and post condition is associated with each operation
Formal Specification Properties • Unambiguous • formal syntax used by formal methods has only one interpretation (unlike natural language statements) • Consistency • ensuring through mathematical proof that initial facts can be mapped (using inference rules)into later statements within the specification • Completeness • difficult to achieve in a large system even using formal methods
Writing Formal Specifications • Begin by defining state in terms of abstract items to be manipulated by the function (similar to variable declaration in a programming language) • Define the data invariant by writing the data relations that will not change during the execution of the function using mathematical notation • Write the precondition and post-condition for the function using mathematical notation to show the system state before and after function execution
Formal Specification Language Components • Syntax • defines the specific notation used to represent a specification • Semantics • help to define the objects used to define the system • Set of relations • define the rules that indicate which objects properly satisfy the specification
Algebraic Specification • Particularly appropriate from sub-system interface specification • Involves specifying operations for abstract data types or objects in terms of their interrelationships • Contains a syntax part which defines its signature and a semantic part defined by axioms • Algebraic specifications may be developed by defining the semantics of each inspection operation for each constructor operation • Display operations are hard to define algebraically and need to be defined informally instead
Specification Operations • Constructor operations • create entities of the type specified • Inspection operations • evaluate entities of the type being specified • Behavior specification is created by defining the inspector operations for each constructor operation
Algebraic Specification Example 5 language primitives (Guttag & Liskov) • Functional composition • Equality relation • Constants • "true and false" • infinite set of free variables
Queue Specification - part 1 Syntactic specification • structure queue • newQ = queue • addQ(queue, item) = item • delQ(queue) = queue • frontQ(queue) = item • isNew(queue) = boolean
Queue Specification - part 2 Semantic specification • declare q : queue i : item • delQ(addQ(q, i)) = if isNewQ() then newQ() else addQ(delQ(q), i)
Queue Specification - part 3 Semantic specification (continued) • isNewQ(addQ(q, i)) = false • isNewQ(newQ()) = true • frontQ(addQ(q, i)) = if isNewQ(q) then i else FrontQ(q)
Queue Specification - part 4 Restriction specification • delQ(newQ()) = error • frontQ(newQ()) = error
Error Specification • It is important to define the behavior of an operation under both normal and abnormal conditions • This might be done using one of these approaches • Use a special flag constant like “error” or “undefined” that conforms to the operation return type • Define the return type to be a tuple with an element that indicates success or failure of the operation • Include a special failure or exception section in the specification (this may need to be defined informally)
Primitive Constructors • Sometimes is it useful to introduce additional constructors to simplify a specification • This allows other constructors to be specified using these more primitive constructors • For example, adding a node constructor to simplify the specification of other list operators
Structured Specification • Whenever possible specifications should be reused in the construction of other specifications • Similar to work in object-oriented design, a generic specification is instantiated to yield a particular specification • For example a generic specification may call for a sorted list and this might later be instantiated with a particular list node type and representation
Incremental Specification • This involves developing a simple specification and then using this in more complex specifications • The development of a library reusable specification building blocks would be useful • For example, the specification of a Cartesian coordinate might be useful in the specification of screen objects in a GUI
Specification Enrichment • Starting with a reusable specification definition, new operations are added to create a more complex type • Similar to the process of inheritance in object-oriented programming • Can be carried on for several levels • Enrichment creates a new type which is not the same as import/export which more like macro expansion (can only use an definition literally)
Multi-value Operations • Some operations return more than one entity (for example pop may return an element and a modified stack in some specifications) • One solution is to define the operation using multiple operations • A more natural approach would be to extend our notation to allow operations to return tuples (e.g. structs or records) rather than just a single values
Establishing Formal Methods • The use of formal methods is not an all or nothing proposition • The level of rigor employed can be tailored to fit • budgets • schedules • technical environments • Formal methods can be modified and integrated into existing processes
Process Prerequisites • To make use of formal method a development process must be mature • has discrete phases • work products are defined for each phase • analysis procedures should be in place for work products • scheduled review of work products is present • The preferred type of analysis will be strongly influenced by the level of rigor needed by the project objectives
Process Modifications with Formal Specification Methods • If the requirements analysis procedures are well-defined then few changes to the process will be required to integrate formal methods • Initial modeling activity employees finite-state machines, object diagrams, etc. • Model would be formalized by converting it to a formal language representation