mathematical modeling and formal specification languages n.
Download
Skip this Video
Download Presentation
Mathematical Modeling and Formal Specification Languages

Loading in 2 Seconds...

play fullscreen
1 / 20

Mathematical Modeling and Formal Specification Languages - PowerPoint PPT Presentation


  • 279 Views
  • Uploaded on

Mathematical Modeling and Formal Specification Languages. CIS 376 Bruce R. Maxim UM-Dearborn. 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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Mathematical Modeling and Formal Specification Languages' - pembroke


Download Now An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
mathematical models
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
mathematical model benefits
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
types of mathematical models
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
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

Discrete Modeling Techniques
object models
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
function models
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
function modeling example abstract stack 1
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}

function modeling example abstract stack 2
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

function modeling example abstract stack 3
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
formal specification language
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
specification language features part 1
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.
specification language features part 2
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
specification language features part 3
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
specification language features part 4
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
importance of type checking
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
system operations as functions
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
logical errors in formal specifications
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.
techniques for detecting specification errors
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
formal specification process model
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