1 / 39

CASL-Common Algebraic Specification Language

CASL-Common Algebraic Specification Language. Anis Yousefi Ph.D. Candidate Department of Computing & Software McMaster University yousea2@mcmaster.ca. Outline. Introduction CASL’s Basic Specifications CASL’s Structured Specifications CASL’s Architectural Specifications

tyra
Download Presentation

CASL-Common Algebraic Specification Language

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CASL-Common Algebraic Specification Language Anis Yousefi Ph.D. Candidate Department of Computing & Software McMaster University yousea2@mcmaster.ca

  2. Outline • Introduction • CASL’s Basic Specifications • CASL’s Structured Specifications • CASL’s Architectural Specifications • Tools & Case Study

  3. The Common Algebraic Specification Language • Common • CoFI: the international common framework initiative • Designed to replace existing algebraic languages and provide a standard • Algebraic Specification • Programs as algebraic structures • Data Values + Functions • Specification in terms of axiom

  4. CASL Layers • Basic (Unstructured) Specifications • Specifications in terms of signatures and sentences • Structured Specifications • Naming, Parameterization, etc. • Architectural Specifications • Reusable implementation units • Libraries of named specifications

  5. Basic Specifications • Declaration of symbols + set of axioms and constraints (restricting the interpretations of the declared symbols) Σ Symbols Class of Σ-Models  Interpretations of Σ which satisfy the axioms and constraints of the specifications • M ╞═ SP : “Model M satisfies specification SP” or “M is a model of SP”

  6. Specifications and Institutions • To develop concepts of a spec language independent of the underlying logical system • I = (Sign, Sen, Mod,╞═) • Sign: category of signatures • Sen: set of sentences for each signature • Senσ : sentence translation map • Mod: category of models for each signature • Modσ : model reduction functor • ╞═: satisfaction relations for each signature (whether a sentence holds in a model or not)

  7. Notations • Σ = (S,F) • σ : Σ Σ’ • Sign: category of signatures • Sen(Σ): set of sentences for signature Σ • Senσ: Sen(Σ)  Sen(Σ’) • Mod(Σ): set of models for signature Σ • Modσ:Mod(Σ’)  Mod(Σ) • ╞═Σ |Mod(Σ)| Sen(Σ)

  8. Discussion on signatures • Signatures define (non-logical) symbols used in sentences & interpreted in models • Signature Morphisms allow to extend signatures, change notations,… • Signature Morphisms lead to translation of sentences & models such that satisfaction is preserved

  9. Logic • Institutions + Entailment System • Extending institutions with proof-theoretic entailment relations compatible with semantic entailment • LOG = (Sign, Sen, Mod,╞═,├─) ├─ Σ P(Sen(Σ)) Sen(Σ) (derivation rules) • Soundness: if Γ├─Σφ then Γ╞═Σφ • Completeness: if Γ╞═Σφ then Γ├─Σφ

  10. CASL’s Basic Specifications • Adds sub-sorting, partiality, first order logic & induction • To add sub-sorts • Many-sorted institutions with partial functions, FOL, sort generation constraints • Constructing sub-sorted institutions from many-sorted institutions

  11. Many-Sorted Institutions • I = (Sign, Sen, Mod,╞═) • Sign: category of many-sortedsignatures • Sen: set of many-sorted sentences for each signature • Senσ : sentence translation map • Mod: category of many-sorted models for each signature • Modσ : model reduction functor • ╞═: satisfaction relation for each signature

  12. Many-Sorted Signature • Σ = (S, TF, PF, P) • S: set of sorts • TF: total function symbols • PF: partial function symbols • P: predicates • Signature Morphism

  13. Many-Sorted Σ-Models • M = (MS, TFM, PFM, PM) • MS: a family of non-empty carrier sets indexed by sort s in S, for each sort in Σ • TFM: Mw Ms , for each TF in Σ Mw: Cartesian product of Ms for sorts in the domain of TF • PFM: Mw? Ms , for each PF in Σ • PM Mw , for each P in Σ

  14. Many-Sorted Σ-Sentences • Closed many-sorted first-order formulae (no variables) • Sort generation constraint over Σ • Σ X  T  Many-Sorted Atomic Σ-Formulae  Many-Sorted First-Order Formulae • Variables X over Σ • Terms T: X + applications of Σ-functions over X

  15. Many-Sorted First-Order Formulae • Many-Sorted Atomic Σ-Formulae • Application of a predicate symbol to terms • Existential equation • Strong equation • Assertion def t: defining value of term t • Many-Sorted First-Order Formulae • Add formula “false” and closing under implication and universal quantification

  16. Sort Generation Constraint Over Σ • A given set of sorts is generated by a given set of functions • Along with a signature morphism that allows translation • ({nat}, {0; suc}, id)

  17. ╞═ ╞═ Satisfaction of sentences • P(t1,…,tn) is satisfied if the value of t1 to tn is defined and give a tuple belonging to PM • “def t” is satisfied if the value of t is defined • is satisfied if values of t1 and t2 are defined and equal • is satisfied if values of t1 and t2 are defined and equal or both values are undefined • A sort-generation constraint is satisfied if the carriers of the sorts in are generated by the function symbols in from the values in the carriers of sorts not in . Then

  18. Entailment System • Rules of derivation

  19. Soundness and Completeness • Soundness: • CASL institutions equipped with the provided entailment system is sound • Completeness: • it is complete if sort generation constraints are not used.

  20. Sub-Sorting in CASL • Injective embedding between carriers (not necessarily as inclusions) • Allows for more general models in which values of a sub-sort and super-sort are represented differently • Integers (represented as 32-bit words) and Reals (represented using floating-point representation)

  21. Sub-sorted Institutions • A category of sub-sorted signatures is defined • A functor from this category into the category of many-sorted signatures is defined • The notations of models, sentences, and satisfaction is borrowed from the many-sorted institutions via this functor

  22. Sub-sorted Signature • Σ = (S, TF, PF, P, ≤) • ≤: reflexive and transitive relation on set of sorts • Sub-sorted signature morphism: many-sorted signature morphism that preserves “≤” and “overloading relations” between functions • Overloading relation • Shared sub-sort in their domain • Shared super-sort in their range

  23. em Constructing Sub-Sorted Signatures from Many-Sorted Signatures s s’ • em: embedding • pr: projection • in: membership predicate for each pair of sorts s ≤ s’ • Construction ^ is a functor from category of sub-sorted signatures into the category of many-sorted signatures pr

  24. Sub-Sorted Models • Many-sorted models satisfying some axioms • Embedding functions are injective. • The embedding of a sort into itself is the identity function. • All compositions of embedding functions between the same two sorts are equal functions. • Projection functions are injective when defined. • Embedding followed by projection is identity. • Membership in a sub-sort holds just when the projection to the sub-sort is defined. • Embedding is compatible with those functions and predicates that are in the overloading relations.

  25. Sub-Sorted Sentences • Sub-sorted Σ-sentences are ordinary many-sorted sentences for • Translation of sentences along a sub-sorted signature morphism σ is ordinary many-sorted translation along

  26. Satisfaction and proofs • Reuse satisfaction conditions from many-sorted • Proof calculus can borrowed from the many-sorted case Φ├─ΣφΦ UAx(Σ)├─Σφ • Soundness and completeness follow from the many-sorted case ^

  27. Structured Specifications

  28. Structured Specifications • SPEC1 and SPEC2 (Union): Combines specifications (re-use) • SPEC1 with Symbol Mapping (Translation) : Renaming of symbols • SPEC1 hide Symbol List (Reduction): Hiding symbols • SPEC1 Then SPEC2 (Extension): Enriching models by declaring new symbols and asserting their properties and/or specializing the interpretation of already declared symbols • Free {SPEC}: Restricting to free data-types

  29. Naming, Parameterization, & Views • Name to refer to the specification • Generic specifications: parameters • Instantiation: providing an argumentfor each parameter + a fitting morphismfrom the parameter to the argument • Fitting may also be achieved by use of named views between the parameter and argument specifications • view VN : SP to SP’ = Symbol Mapping

  30. Architectural Specifications • Provides a means for stating how implementation units are used as building blocks for larger components • Consist of declaration and/or definition of units together with a way of assembling them

  31. Architectural Specifications

  32. Architectural Specifications Keywords • given: imported units • with: renaming (mapping of symbols) • hide/reveal: unit reduction (hide some symbols in unit) • and: amalgamation of units • fit: fitting an argument to the corresponding formal argument for the generic unit, via a signature morphismin the same

  33. Specification Refinement • Fixes some expected properties but says nothing about implementation • Model class becomes smaller and smaller • Techniques: • Views: model class inclusion • Refinement R1 = SP1 refined to SP2 • Refinement R1 = SP1 refined to arch spec ASP • Reducing to implementation of smaller specifications via an architectural specification

  34. Tools • Hets: The Heterogeneous Tool Set • Support for all layers of CASL + CASL sub-languages and extensions • Parsing, analysis, proof • Supporting multiple logics • Hets web-based interface: http://www.informatik.uni-bremen.de/cgi-bin/cgiwrap/maeder/hets.cgi • Other tools: CASL consistency checker, CASLtoPVS, CATS, HOL-CASL

  35. Case Study: Warehouse System

  36. Case Study: Warehouse System

  37. Case Study: Warehouse System

  38. Conclusion • CASL is a complex specification language that provides formal semantics and proof calculus for all its constructs • Orthogonal layers • Basic specs: writing theories in a specific logic • Structured and architectural specs: logic independent semantics • Tool support

  39. References • T. Mossakowski, A. Haxthausen, D. Sannella and A. Tarlecki. CASL -- the Common Algebraic Specification Language: semantics and proof theory. Computing and Informatics 22:285-321 (2003). An extended version of this paper appeared in the book Logics of Specification Languages, 241--298, D. Bjørner and M. Henson eds., Springer (2008). • P.D. Mosses and M. Bidoit. Casl – The Common Algebraic Specification Language: User Manual, volume 2900 of Lecture Notes in Computer Science, Springer, 2004. • P.D. Mosses (ed.). Casl – The Common Algebraic Specification Language: Reference Manual, volume 2960 of Lecture Notes in Computer Science, Springer, 2004. • Hets is available from http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/ . • R. Khedri, Formal Methods for Software Specification and Development, McMaster University.

More Related