Mathematical Modeling and Formal Specification Languages

1
Mathematical Modeling and Formal Specification
Languages

• CIS 376
• Bruce R. Maxim
• UM-Dearborn

2
Mathematical Models

• Abstract representations of a system using
  mathematical entities and concepts
• Model should captures the essential
  characteristics of the system while ignoring
  irrelevant details
• If model is to be used for deductive reasoning
  about the system it needs to provide sufficient
  analytic power

3
Mathematical Model Benefits

• Mathematical model is more concise and more
  precise than natural language, pseudo-code, or
  diagrams
• Mathematical model can be used to calculate and
  predict system behavior
• Model can be analyzed using mathematical
  reasoning to prove system properties or derive
  new behaviors

4
Types of Mathematical Models

• Continuous Models
• uses calculus and continuous function theory
  (e.g. derivatives, integrals, differential
  equations)
• a function f would define the state of the
  system with an infinite number of states and
  smooth transitions
• Discrete Models
• based on logic and set theory
• state transition functions are used to model
  transitions among a finite number of states

5
Discrete Modeling Techniques

• Informal models
• natural language
• charts
• tables
• Structural Models (employ formalisms)
• data flow diagrams
• ER diagrams
• object models

• Formal Models (use formal semantics)
• function models
• state machine models
• formal specification

6
Object Models

• Object models represent systems as structured
  collections of classes and object relations
• Object models provide a static view of a system
• Some object models rely on a combination of DFD,
  ER diagrams, and STD to yield a composite
  static/dynamic system model
• Object models are structural in nature and can be
  useful for creating initial system models that
  can be mapped to a formal model if needed

7
Function Models

• Similar to circuit design work
• A logic table for a full adder might be captured
  and represented as
• Adder(x, y, cinput) (s, coutput)
• ((x y cinput) mod 2, (x y cinput) div 2)
• Also similar to the algebraic specification we
  have seen in data type semantic specification

8
Function Modeling ExampleAbstract Stack - 1

• Being by defining stack and element to be
  unspecified types
• stack TYPE
• element TYPE
• Use a subtype to define a non-empty stack type
• nonempty_stack a TYPE s stack s / empty

9
Function Modeling ExampleAbstract Stack - 2

• Basic operations are defined as functions
• push element, stack ? nonempty_stack
• pop nonempty_stack ? stack
• top nonempty_stack ? element
• Behavior is described by axioms
• Pop_Push AXIOM
• pop(push(e, s)) s
• Top_Push AXIOM
• top(push(e, s)) e

10
Function Modeling ExampleAbstract Stack - 3

• Type checking assures that the expression
  pop(empty) is never allowed
• The theorem below follows from the type
  declarations
• Push_Empty THEOREM
• push(e, s) / empty
• The use of subtypes and theorems provides a
  powerful tool for capturing requirements in your
  type definitions

11
Formal Specification Language

• Based on formal mathematical logic with some
  programming language support (e.g. type system
  and parameterization)
• Generally non-executable models
• Designed to specify what is to be computed and
  not how the computation should be accomplished
• Most formal languages are based on axiomatic set
  theory or higher-order logic

12
Specification Language Features - part 1

• Explicit semantics
• language must have a mathematical basis
• Expressiveness
• flexibility
• convenience
• economy of expression
• Programming language data types
• arrays, structs, strings, sets, lists, etc.

13
Specification Language Features - part 2

• Convenient syntax
• Diagramatic notation
• Strong typing
• can be richer than ordinary programming languages
• provides economy and clarity of expression
• type checking provides consistency checks
• Total functions
• most logics assume total functions
• subtypes help make total functions more flexible

14
Specification Language Features - part 3

• Axioms and definitions
• axioms should be used carefully to avoid
  introducing inconsistencies
• definitional principle ensures well-formed
  definitions
• in some languages type checking assertions will
  be generated to ensure valid definitions
• Modularization
• ability to break specifications into independent
  modules
• parameterized modules allow for easier reusability

15
Specification Language Features - part 4

• Built-in model of computation
• handles simple type checking constraints
• enhance proof-checking
• Maturity
• documentation
• tool support
• theoretical basis
• specification library availability
• standardization

16
Importance of Type Checking

• Specification languages can have much richer type
  systems than programming languages since type do
  not have to be implemented directly
• Type checking can be used to detect faults and
  inconsistencies
• Essential model features can be embedded in types
  and subtypes

17
System Operations as Functions

• Basic system operations are often modeled as
  functions
• Functions can modify the system state so
  invariant conditions are often imposed on
  appropriate combinations of functions (e.g.
  similar to algebraic specification)
• Theorems and axioms can be used to model other
  system invariants employing functions

18
Logical Errors in Formal Specifications

• Logical inconsistency
• Easiest logic errors to detect
• Accuracy
• Does specification match intended meaning?
• System invariants can help in detecting these
  errors.
• Completeness
• Does specification identify all contingencies?
• Are appropriate behaviors defined for all cases?
• Peer review can aid in detection.

19
Techniques for Detecting Specification Errors

• Manual
• Formal specification inspection
• Theorem proving, proof checking, and model
  checking for logic defects
• Automated
• Parsing specification for syntactic correctness
• Type checking for semantic consistency
• Simulation or animation based on the specification

20
Formal Specification Process Model

• Clarify requirements and high level design
• Articulate implicit assumptions
• Identify undocumented or unexpected assumptions
• Expose defects
• Identify exceptions
• Evaluate test coverage