Managed Assertions : language-neutral behavioral contracts for components 2 nd Rotor Workshop 25 April 2003 Nam Tran Monash University

Slides:



Advertisements
Similar presentations
Copyright © 2006 The McGraw-Hill Companies, Inc. Programming Languages 2nd edition Tucker and Noonan Chapter 18 Program Correctness To treat programming.
Advertisements

Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 8.
Extensibility, Safety and Performance in the SPIN Operating System Presented by Allen Kerr.
Copyright © 2006 Addison-Wesley. All rights reserved.1-1 ICS 410: Programming Languages Chapter 3 : Describing Syntax and Semantics Axiomatic Semantics.
ISBN Chapter 3 Describing Syntax and Semantics.
Dept. of Computer Science A Runtime Assertion Checker for the Java Modeling Language (JML) Yoonsik Cheon and Gary T. Leavens SERP 2002, June 24-27, 2002.
ITEC200 Week02 Program Correctness and Efficiency.
Aarhus University, 2005Esmertec AG1 Implementing Object-Oriented Virtual Machines Lars Bak & Kasper Lund Esmertec AG
1 Specifying Object Interfaces. 2 Major tasks in this stage: --are there any missing attributes or operations? --how can we reduce coupling, make interface.
Software Testing and Quality Assurance
CS-550 (M.Soneru): Protection and Security - 1 [SaS] 1 Protection and Security.
Ensuring Non-Functional Properties. What Is an NFP?  A software system’s non-functional property (NFP) is a constraint on the manner in which the system.
McGraw-Hill/Irwin Copyright © 2007 by The McGraw-Hill Companies, Inc. All rights reserved. Chapter 5 Understanding Entity Relationship Diagrams.
OOP #10: Correctness Fritz Henglein. Wrap-up: Types A type is a collection of objects with common behavior (operations and properties). (Abstract) types.
A Type System for Expressive Security Policies David Walker Cornell University.
Page 1 Building Reliable Component-based Systems Chapter 6 - Semantic Integrity in Component Based Development Chapter 6 Semantic Integrity in Component.
Describing Syntax and Semantics
Eiffel Language and Design by Contract Contract –An agreement between the client and the supplier Characteristics –Expects some benefits and is prepared.
CS884 (Prasad)Java Goals1 “Perfect Quote” You know you've achieved perfection in design, Not when you have nothing more to add, But when you have nothing.
Computer Science 340 Software Design & Testing Design By Contract.
Ranga Rodrigo. Class is central to object oriented programming.
C++ Code Analysis: an Open Architecture for the Verification of Coding Rules Paolo Tonella ITC-irst, Centro per la Ricerca Scientifica e Tecnologica
PROGRAMMING IN VISUAL BASIC.NET VISUAL BASIC BUILDING BLOCKS Bilal Munir Mughal 1 Chapter-5.
COP 4620 / 5625 Programming Language Translation / Compiler Writing Fall 2003 Lecture 10, 10/30/2003 Prof. Roy Levow.
Computer Science and Engineering College of Engineering The Ohio State University Interfaces The credit for these slides goes to Professor Paul Sivilotti.
Semantic Web Fred: Project Objectives & SWF Framework Michael Stollberg Reinhold Herzog Peter Zugmann - 07 April
Tammy Dahlgren with Tom Epperly, Scott Kohn, and Gary Kumfert Center for Applied Scientific Computing Common Component Architecture Working Group October.
Design by Contract in Java Concept and Comparison.
Low-Level Detailed Design SAD (Soft Arch Design) Mid-level Detailed Design Low-Level Detailed Design Design Finalization Design Document.
1 Compiler Construction (CS-636) Muhammad Bilal Bashir UIIT, Rawalpindi.
07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking.
Semantics In Text: Chapter 3.
PRIOR TO WEB SERVICES THE OTHER TECHNOLOGIES ARE:.
Spec# Andreas Vida. Motivation Correct and maintainable software Correct and maintainable software Cost effective software production Cost effective software.
A Specification Logic for Exceptions and Beyond Cristina David Cristian Gherghina National University of Singapore.
Object-Oriented Programming Chapter Chapter
ANU COMP2110 Software Design in 2003 Lecture 10Slide 1 COMP2110 Software Design in 2004 Lecture 12 Documenting Detailed Design How to write down detailed.
SWE 4743 Abstract Data Types Richard Gesick. SWE Abstract Data Types Object-oriented design is based on the theory of abstract data types Domain.
PROGRAMMING PRE- AND POSTCONDITIONS, INVARIANTS AND METHOD CONTRACTS B MODULE 2: SOFTWARE SYSTEMS 13 NOVEMBER 2013.
CSSE501 Object-Oriented Development. Chapter 10: Subclasses and Subtypes  In this chapter we will explore the relationships between the two concepts.
1 Verification of object-oriented programs with invariants Mike Barnett, Robert DeLine, Manuel Fahndrich, K. Rustan M. Leino, Wolfram Schulte ECOOP 2003.
Recap Introduction to Inheritance Inheritance in C++ IS-A Relationship Polymorphism in Inheritance Classes in Inheritance Visibility Rules Constructor.
C HAPTER 3 Describing Syntax and Semantics. D YNAMIC S EMANTICS Describing syntax is relatively simple There is no single widely acceptable notation or.
DBC NOTES. Design By Contract l A contract carries mutual obligations and benefits. l The client should only call a routine when the routine’s pre-condition.
David Evans CS201j: Engineering Software University of Virginia Computer Science Lecture 10: Programming Exceptionally.
Object Design More Design Patterns Object Constraint Language Object Design Specifying Interfaces Review Exam 2 CEN 4010 Class 18 – 11/03.
Design by Contract. The Goal Ensure the correctness of our software (correctness) Recover when it is not correct anyway (robustness) Correctness: Assertions.
PREPARED BY: MS. ANGELA R.ICO & MS. AILEEN E. QUITNO (MSE-COE) COURSE TITLE: OPERATING SYSTEM PROF. GISELA MAY A. ALBANO PREPARED BY: MS. ANGELA R.ICO.
1 Compiler Construction (CS-636) Muhammad Bilal Bashir UIIT, Rawalpindi.
Interfaces CMSC 202. Public Interfaces Objects define their interaction with the outside world through the their public interface. A class' public interface.
© Bertrand Meyer and Yishai Feldman Notice Some of the material is taken from Object-Oriented Software Construction, 2nd edition, by Bertrand Meyer (Prentice.
A Single Intermediate Language That Supports Multiple Implemtntation of Exceptions Delvin Defoe Washington University in Saint Louis Department of Computer.
Chapter 3 of Programming Languages by Ravi Sethi
Chapter 6 CS 3370 – C++ Functions.
Design by Contract Jim Fawcett CSE784 – Software Studio
Design by Contract Jim Fawcett CSE784 – Software Studio
Compilers Principles, Techniques, & Tools Taught by Jing Zhang
CSE 374 Programming Concepts & Tools
Accessible Formal Methods A Study of the Java Modeling Language
Specifying Object Interfaces
CSC 143 Error Handling Kinds of errors: invalid input vs programming bugs How to handle: Bugs: use assert to trap during testing Bad data: should never.
Semantics In Text: Chapter 3.
Java Modeling Language (JML)
Assertions References: internet notes; Bertrand Meyer, Object-Oriented Software Construction; 4/25/2019.
Computer Science 340 Software Design & Testing
Contract-Based Programming with/without Ada 2012
Controlling Program Flow
Procedure Linkages Standard procedure linkage Procedure has
Abstract Types Defined as Classes of Variables
Presentation transcript:

Managed Assertions : language-neutral behavioral contracts for components 2 nd Rotor Workshop 25 April 2003 Nam Tran Monash University

Agenda Introduction Language-neutral assertions & contracts System design and properties Implementation in Rotor Wrap-up

Introduction Rotor project at Monash university Advisors: Prof. David Abramson, Prof. Christine Mingins Related: Guard.NET, Eiffel.NET Motivation from Common Type System Language neutral typing semantics Motivation from Design by Contract Behavioral contracts Rotor for its multi-language components

Language-neutral contracts: why? Components are inherently language-neutral Components integration requires precise interfaces (contracts) more than just typing contracts (syntactic) behavioral contracts Need for a language-neutral contracts system Similar in spirit to the common type system

Language-neutral contracts: what? Behavioral component contracts Interface invariants Method pre- and post-conditions Assertions on visible state Common contract system Common designated meaning of constructs Common binary representation Common runtime treatment

Language-neutral contracts: how? Managed assertions Assertions are first class constructs Binary format neutral of source syntax  represented separately from program code Assertions checking is managed  runtime service understands assertions  decisions to check assertions are made at runtime

Language-neutral contracts: again? Source with assertionsNormal sourceAssertion specs Augmented compilerNormal compilerAssertion compiler Contracted components Runtime System Managed assertion runtime Garbage collector Just-in-Time compiler Figure 1. Managed assertions system architecture Common binary representation Common runtime treatment

Design and properties (1/6) Common representation Assertions are compiled to code blocks Separate from method bodies Roles are designated explicitly by metadata Properties  contracts become part of binary components but remain first class entities  flexibility in checking policies  enabling correct and efficient dynamic checks

Design and properties (2/6) Native runtime support enforcement policies checked at runtime runtime service collects and executes assertions  follows metadata designation  relies on dynamic dispatch resolution  walks subtyping hierarchies

Design and properties (3/6) Runtime support properties Behavioral subtyping rules  subtype’s pre-condition implied by base type’s  subtype’s post-condition implies base type’s Upheld by  specification of partial conditions, e.g. require and require else  runtime combinations via OR and AND for pre- and post-conditions, respectively

Design and properties (4/6) Runtime support properties (cont.) Exception handling  Pre-condition violation raised to caller  Post-condition violation indicates (to caller) callee’s fault  Invariant violation indicates (to caller) callee’s fault if upon method return prior error if upon method entry

Design and properties (5/6) Runtime support properties (cont.) Object re-entrance  invariants checking of external calls prevents dangerous re-entrant calls  internal calls are allowed to temporarily break invariants  indirect external re-entrant calls are still subjected to invariants checking  enabling flexible implementation while regulating external interactions

Design and properties (6/6) Runtime support properties Reflection  Assertions are first class entities  Assertion objects can be constructed and retrieved at runtime  Enabling possible classes of tools verifiers to check contract at load-time adapters to liaise between components

Implementation in Rotor (1/9) Binary representation Named assertions are special methods Assertions metadata table Table number 0x2a: mdtAssertion = 0x2a class AssertionRec { public:…… enum { COL_TargetRVA, // target of general check COL_Flags, // what kind of assertion COL_Owner, // owner type or method COL_Eval, // evaluation method COL_Name, }; }

Implementation in Rotor (2/9) Typedef table Method table Assertion table ownernameflagcode inv. pre. Figure 3. Contracts in CLI binary format

Implementation in Rotor (3/9) Runtime support Extensions to metadata interfaces, classes  IMetaDataEmit, IMetaDataImport  RegMeta and related classes  No extensions to managed APIs yet Checking policies  Configuration facility extension  Object identities check to see if caller and callee are the same object for invariant checks

Implementation in Rotor (4/9) Runtime checking concerns Correctness (subtyping, dynamic dispatch) Sensible exception handling Least overhead Runtime checking choices Native stubs Extra wrapper method Inlined wrapping

Implementation in Rotor (5/9) Runtime checking of assertions Perform IL body re-writing Weave checking code into callee method Just before a method is JIT-compiled Replace method body using profiling APIs But does not go through external interface  Improve efficiency and leaving the interface for user code profiler

Implementation in Rotor (6/9) IL body re-writing Create extra local variables if necessary  one to hold return value if non-void To check pre-conditions  Collect and inline all relevant pre-condition methods  Jump to exception raising code if all resultant boolean are false

Implementation in Rotor (7/9) IL body re-writing (cont.) Inline old body  Replace ‘return’ by assignment and jump Assignment to extra local variable Jump to label after end of old body

Implementation in Rotor (8/9) IL body re-writing (cont.) To check post-conditions  Collect and inline all relevant post-condition methods  Jump to exception raising code if any resultant boolean is false  Return normally otherwise Invariant checks code weaving is similar

Implementation in Rotor (9/9) IL body re-writing (cont.) Adjust exception tables to reflect offset changes  Ensure that no assertion exceptions are accidentally caught by callee code Adjust max stack value as appropriate

Wrap-up What’s next Complete implementation  Modifications to ILASM/ILDASM Extra textual IL syntax constructs for assertions  Modifications to source compilers Adopt/create source assertion notation Eiffel.NET to compile to new format C# compiler

Thank you! Q & A