1 / 16

Overview of Components and Specifications in RESOLVE System

Learn how specifications in RESOLVE can address efficiency, hide implementation details, and offer multiple implementation options. By using formal languages like ANNA and principles of data abstraction, users can define contracts through unambiguous mathematical logic. Explore examples of stack operation specifications and the responsibilities of clients and implementers. Gain insights on reusable components and multiple implementations that offer performance trade-offs.

fredas
Download Presentation

Overview of Components and Specifications in RESOLVE System

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. Introduction to Components and Specifications Using RESOLVE Murali Sitaraman Clemson University

  2. Overview • Specifications provide user-oriented cover story • Designs address efficiency and sufficient functional completeness issues • Specifications hide implementation-specific information • Multiple implementations may be developed to satisfy the same specification

  3. Languages for Formal Specification ANNA (and SPARK) for Ada JML for Java Larch/C++ for C++ Spec# for C# … Eiffel RESOLVE … VDM Z

  4. Common Principles: Data Abstraction Specification Specifications are contracts Formal; unambiguous Mathematical logic Use a combination of well-known mathematical theories and notation Specify mathematical models for objects Specify the behavior of operations using those models

  5. Example: Use of Mathematical Theories Concept Stack_Template(type Entry; …); uses String_Theory; Type Family Stack is modeled by … Operation Push… Operation Pop… … end Stack_Template;

  6. Alternative Specification of Push Operation Operation Push_1 (restores E: Entry; updates S: Stack); requires |S| < Max_Depth; ensures S = <E> o #S; Note: Implementation needs to make a copy of the Entry E. This could be inefficient if entries are large.

  7. Alternative Specification of Push Operation Operation Push_2 (clears E: Entry; updates S: Stack); requires |S| < Max_Depth; ensures S = <#E> o #S; Note: Implementation needs to “clear”, i.e., initialize the Entry E. …

  8. Alternative Specification of Push Operation Operation Push (alters E: Entry; updates S: Stack); requires |S| < Max_Depth; ensures S = <#E> o #S; Note: Implementation may change Entry E in any way, so it permits the most efficient implementations; it is the most flexible specification

  9. Clients have flexibility… Operation Push (alters E: Entry; updates S: Stack); requires |S| < Max_Depth; ensures S = <#E> o #S; Example code to do Push_1 (i.e., “restore” pushed entry): Copy(E, Temp); Push(Temp, S); Example code to do Push_2 (i.e., “clear” the pushed entry: Push(E, S); Clear(E);

  10. Specification of Operations Operation Push (alters E: Entry; updates S: Stack); requires |S| < Max_Depth; ensures S = <#E> o #S; Operation Pop (replaces R: Entry; updates S: Stack); requires |S| > 0; ensures #S = <R> o S; Operation Depth (restores S: Stack): Integer; ensures Depth = |S|; …

  11. Specification of Operations Operation Push (alters E: Entry; updates S: Stack); requires |S| < Max_Depth; ensures S = <#E> o #S; Operation Pop (replaces R: Entry; updates S: Stack); requires |S| > 0; ensures #S = <R> o S; Operation Depth (restores S: Stack): Integer; ensures Depth = |S|; …

  12. Requires and Ensures clauses • Requirements and guarantees • Requires clauses are preconditions • Ensures clauses are postconditions • Who is responsible for requires clauses? • Client (i.e., caller) • Implementer • Neither • Both • Discussion of consequences

  13. Requires and Ensures clauses • Requirements and guarantees • Requires clauses are preconditions • Ensures clauses are postconditions • Who is responsible for requires clauses? • Client (i.e., caller) • Implementer • Neither • Both • Discussion of consequences

  14. Understanding specifications • Please see the tutorials at the web interface under help on: • String theory notations • Understanding specification parameter modes • Understanding details of specifications

  15. Using Reusable Components • Users (clients) need to know only interface specifications • Users need to supply appropriate parameters to instantiate • Depending on the paradigm, special operations are automatically available on objects • Assignment in Java (e.g., S = T) • Swap in RESOLVE (e.g., S :=: T)

  16. Multiple Implementations • Alternative implementations provide the same functionality • Provide performance trade-offs • time vs. space • average case vs. worst case • Efficiency vs. predictability • some subset of methods vs. some others • Users pick ones best fitting their requirements when instantiating

More Related