DOCSLIB.ORG

C# Compiler Extension to Support the Object Constraint Language Version 2.0

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

C# COMPILER EXTENSION TO SUPPORT THE OBJECT CONSTRAINT LANGUAGE VERSION 2.0 by David Arnold A thesis submitted to the Faculty of Graduate Studies and Research in partial fulfillment of the requirements for the degree of Masters of Computer Science Ottawa-Carleton Insititute for Computer Science School of Computer Science Carleton University Ottawa, Ontario 2004 Copyright c 2004 by David Arnold The undersigned hereby recommend to the Faculty of Graduate Studies and Research acceptance of the thesis, C# Compiler Extension to Support the Object Constraint Language Version 2.0 submitted by David Arnold Dr. Douglas Howe (Director, School of Computer Science) Dr. Francis Bordeleau (Thesis Supervisor) Dr. Jean-Pierre Corriveau (Thesis Supervisor) Carleton University 2004 Abstract The Object Management Group’s Object Constraint Language (OCL), is part of the Unified Model- ing Language (UML). The OCL is a formal language for the specification of behavioral constraints in software models. When models are transformed into executable code, such constraints are often lost or converted into non-executable comments. This research examines the integration of the OCL at the code level. Microsoft’s .NET initiative introduces a new high-level language: C#. The C# language introduces several new concepts; including properties, delegates and events. The integration of the OCL into C# consists of creating not only a syntactical integration but, also a semantic one. Such integration will contribute to the verification of the OCL specification, as well as to provide a mechanism for the transformation of OCL expressions across the modeling levels defined under Model Driven Architecture (MDA). i Acknowledgements Acknowledgements I am grateful for the encouragement and feedback provided by my thesis supervisors: Jean-Pierre Cor- riveau and Francis Bordeleau. Without their help and support the thesis and implementation would not be what it is today. A special thanks to Toby McClean and Juan Pablo Zamora Zapata. Toby pointed out errors and provided invaluable critiques of the implementation at various stages of its development. Juan Pablo showed me that Fritos and hot sauce are in fact breakfast foods. Kevin Parker, my best friend, helped me to procrastinate at all hours of the day, with countless Halo games and movies. Thanks guy!! I am indebted to Tony D’Ambrogio and Carleton University for the monetary support that was provided during the course of my research. I definitely would not have been able to focus on my research without their contributions. Finally, my mother, my father and my sister have always been a source of encouragement, even when they had no idea what I was talking about. Thank you all. ii Contents 1 Introduction 1 1.1 Context and Motivation . 1 1.1.1 Models . 1 1.1.2 Design by Contract . 2 1.2 Problem . 3 1.3 Objectives . 4 1.4 Contributions . 4 1.4.1 MDA . 4 1.4.2 OCL 2.0 . 5 1.4.3 Design by Contract . 5 1.5 Thesis Structure . 6 2 Background 8 2.1 Design by Contract . 8 iii 2.1.1 Elements of Design by Contract . 8 2.1.2 Benefits of Design by Contract . 13 2.1.3 Issues of Design by Contract . 15 2.1.4 Summary of Design by Contract . 19 2.2 The Object Constraint Language . 19 2.2.1 OCL, UML, and MDA . 20 2.2.2 PIMs and PSMs . 20 2.2.3 Benefits of MDA . 22 2.2.4 The UML and MDA . 23 2.2.5 The OCL and the UML . 23 2.2.6 Summary of the OCL, the UML, and MDA . 32 2.3 Introduction to .NET . 33 2.3.1 What is .NET? . 33 2.3.2 The Common Language Runtime . 34 2.3.3 Framework Class Library . 37 2.3.4 Hands On .NET . 38 2.3.5 Shared Source Common Language Infrastructure . 41 2.3.6 The Mono Project . 42 2.3.7 .NET Summary . 42 2.4 C#............................................. 43 iv 2.4.1 C# Overview . 43 2.4.2 Types . 44 2.4.3 Classes . 46 2.4.4 Properties . 47 2.4.5 Delegates . 48 2.4.6 Events . 50 2.4.7 Indexers . 51 2.4.8 Operators . 52 2.4.9 The new Modifier . 53 2.4.10 Interfaces . 54 2.4.11 Structures . 55 2.4.12 Parameters . 56 2.4.13 Attributes . 58 2.4.14 C# and .NET . 61 2.4.15 Summary . 61 2.5 Existing Tools and Technologies . 61 2.5.1 The Octopus Tool . 62 2.5.2 The Object Constraint Language Environment . 62 2.5.3 Spec# . 63 2.5.4 Jcontract . 64 v 2.5.5 iContract . 64 2.5.6 Eiffel . 65 2.5.7 Alloy . 66 2.5.8 Summary . 68 2.6 Summary . 68 3 Syntax 70 3.1 OCL Blocks . 70 3.2 C# Grammar Changes . 71 3.3 Parsing OCL Expressions . 74 3.4 The OCL Grammar . 75 3.4.1 Variable Expressions . 75 3.4.2 Iterator Variable Lists . 77 3.4.3 Iterators as Methods . 77 3.4.4 Properties . 78 3.4.5 Indexers . 78 3.4.6 Summary . 80 3.5 The Assignment of OCL Expressions . 80 3.5.1 Association Context Declarations . 80 3.5.2 Classifier Context Declarations . 82 3.5.3 Operation Context Declarations . 83 3.6 Summary . 84 vi 4 Semantics 86 4.1 Preconditions and Postconditions . 86 4.2 Class Invariants . 87 4.3 Constraints on Properties . 89 4.4 Constraints on Indexers . 89 4.5 Constraints and Delegates . 89 4.6 Constraints and Events . 91 4.7 Constraints and Inheritance . 92 4.7.1 Class Invariants . 92 4.7.2 Preconditions . 94 4.7.3 Postconditions . 95 4.7.4 Summary of Findler’s Method . 96 4.8 Constraints on Interfaces . 98 4.9 Constraints on Structures . 98 4.10 Constraints on Abstract Classes . ..
Recommended publications
  • Assertions, Pre/Post- Conditions and Invariants

    Assertions, Pre/Post- Conditions and Invariants

    9/14/12 Assertions, pre/post- conditions and invariants Section 2.1 in Walls and Mirrors Section 4.5 Rosen Programming as a contract n Specifying what each method does q Specify it in a comment before method's header n Precondition q What is assumed to be true before the method is executed q Caller obligation n Postcondition q Specifies what will happen if the preconditions are met q Method obligation 1 9/14/12 Class Invariants n A class invariant is a condition that all objects of that class must satisfy while it can be observed by clients n What about Points in Cloud? q boundaries? q center? What is an assertion? n An assertion is a statement that says something about the state of your program n Should be true if there are no mistakes in the program //n == 1 while (n < limit) { n = 2 * n; } // what could you state here? 2 9/14/12 What is an assertion? n An assertion is a statement that says something about the state of your program n Should be true if there are no mistakes in the program //n == 1 while (n < limit) { n = 2 * n; } //n >= limit //more? What is an assertion? n An assertion is a statement that says something about the state of your program n Should be true if there are no mistakes in the program //n == 1 while (n < limit) { n = 2 * n; } //n >= limit //n is the smallest power of 2 >= limit 3 9/14/12 assert Using assert: assert n == 1; while (n < limit) { n = 2 * n; } assert n >= limit; When to use Assertions n We can use assertions to guarantee the behavior.
  • Sound Invariant Checking Using Type Modifiers and Object Capabilities

    Sound Invariant Checking Using Type Modifiers and Object Capabilities

    Sound Invariant Checking Using Type Modifiers and Object Capabilities. Isaac Oscar Gariano Victoria University of Wellington [email protected] Marco Servetto Victoria University of Wellington [email protected] Alex Potanin Victoria University of Wellington [email protected] Abstract In this paper we use pre existing language support for type modifiers and object capabilities to enable a system for sound runtime verification of invariants. Our system guarantees that class invariants hold for all objects involved in execution. Invariants are specified simply as methods whose execution is statically guaranteed to be deterministic and not access any externally mutable state. We automatically call such invariant methods only when objects are created or the state they refer to may have been mutated. Our design restricts the range of expressible invariants but improves upon the usability and performance of our system compared to prior work. In addition, we soundly support mutation, dynamic dispatch, exceptions, and non determinism, while requiring only a modest amount of annotation. We present a case study showing that our system requires a lower annotation burden compared to Spec#, and performs orders of magnitude less runtime invariant checks compared to the widely used ‘visible state semantics’ protocols of D, Eiffel. We also formalise our approach and prove that such pre existing type modifier and object capability support is sufficient to ensure its soundness. 2012 ACM Subject Classification Theory of computation → Invariants, Theory of computation → Program verification, Software and its engineering → Object oriented languages Keywords and phrases type modifiers, object capabilities, runtime verification, class invariants Digital Object Identifier 10.4230/LIPIcs.CVIT.2016.23 1 Introduction Object oriented programming languages provide great flexibility through subtyping and arXiv:1902.10231v1 [cs.PL] 26 Feb 2019 dynamic dispatch: they allow code to be adapted and specialised to behave differently in different contexts.
  • IJIRT | Volume 2 Issue 6 | ISSN: 2349-6002

    IJIRT | Volume 2 Issue 6 | ISSN: 2349-6002

    © November 2015 | IJIRT | Volume 2 Issue 6 | ISSN: 2349-6002 .Net Surbhi Bhardwaj Dronacharya College of Engineering Khentawas, Haryana INTRODUCTION as smartphones. Additionally, .NET Micro .NET Framework (pronounced dot net) is Framework is targeted at severely resource- a software framework developed by Microsoft that constrained devices. runs primarily on Microsoft Windows. It includes a large class library known as Framework Class Library (FCL) and provides language WHAT IS THE .NET FRAMEWORK? interoperability(each language can use code written The .NET Framework is a new and revolutionary in other languages) across several programming platform created by Microsoft for languages. Programs written for .NET Framework developingapplications. execute in a software environment (as contrasted to hardware environment), known as Common It is a platform for application developers. Language Runtime (CLR), an application virtual It is a Framework that supports Multiple machine that provides services such as Language and Cross language integration. security, memory management, and exception handling. FCL and CLR together constitute .NET IT has IDE (Integrated Development Framework. Environment). FCL provides user interface, data access, database Framework is a set of utilities or can say connectivity, cryptography, web building blocks of your application system. application development, numeric algorithms, .NET Framework provides GUI in a GUI and network communications. Programmers manner. produce software by combining their own source code with .NET Framework and other libraries. .NET is a platform independent but with .NET Framework is intended to be used by most new help of Mono Compilation System (MCS). applications created for the Windows platform. MCS is a middle level interface. Microsoft also produces an integrated development .NET Framework provides interoperability environment largely for .NET software called Visual between languages i.e.
  • The Contract Pattern Permission Granted to Copy for Plop ’97 Conference

    The Contract Pattern Permission Granted to Copy for Plop ’97 Conference

    Copyright 1997, Michel de Champlain The Contract Pattern Permission granted to copy for PLoP ’97 Conference. All other rights reserved. Michel de Champlain Department of Computer Science University of Canterbury, Christchurch, New Zealand [email protected] http://www.cosc.canterbury.ac.nz/~michel 12 August 1997 Abstract This paper describes the Contract pattern, an idiom that lets you apply assertions to guarantee pre-conditions and post-conditions of methods and invariants on the state of objects. This pattern can be used to develop reliable classes by making the Design by Contract methodology—introduced by Meyer in the specific context of the Eiffel language—available in Java and possibly other object-oriented languages. Intent Provide an implementation of the Design by contract methodology [Meyer88] for developing reliable classes and create robust objects in Java. This programming pattern lets you apply assertions to guarantee the pre-conditions and post-conditions of methods and invariants on the state of objects. Also Known As Design by contract Motivation Sometimes it’s necessary to restrict a class interface because you don’t want to provide all the possible input combinations for all collaborators. One way to achieve this goal is to make minimal and consistent methods that impose pre-conditions on input parameters. Moreover, you might want to ensure the class behavior by imposing post-conditions before methods return. You might also need to make sure that the class is always in a stable state. Such an approach can result in reliable classes to create robust objects. Consider for example a bounded counter that has both a lower and upper bound.
  • NET Framework

    NET Framework

    Advanced Windows Programming .NET Framework based on: A. Troelsen, Pro C# 2005 and .NET 2.0 Platform, 3rd Ed., 2005, Apress J. Richter, Applied .NET Frameworks Programming, 2002, MS Press D. Watkins et al., Programming in the .NET Environment, 2002, Addison Wesley T. Thai, H. Lam, .NET Framework Essentials, 2001, O’Reilly D. Beyer, C# COM+ Programming, M&T Books, 2001, chapter 1 Krzysztof Mossakowski Faculty of Mathematics and Information Science http://www.mini.pw.edu.pl/~mossakow Advanced Windows Programming .NET Framework - 2 Contents The most important features of .NET Assemblies Metadata Common Type System Common Intermediate Language Common Language Runtime Deploying .NET Runtime Garbage Collection Serialization Krzysztof Mossakowski Faculty of Mathematics and Information Science http://www.mini.pw.edu.pl/~mossakow Advanced Windows Programming .NET Framework - 3 .NET Benefits In comparison with previous Microsoft’s technologies: Consistent programming model – common OO programming model Simplified programming model – no error codes, GUIDs, IUnknown, etc. Run once, run always – no "DLL hell" Simplified deployment – easy to use installation projects Wide platform reach Programming language integration Simplified code reuse Automatic memory management (garbage collection) Type-safe verification Rich debugging support – CLR debugging, language independent Consistent method failure paradigm – exceptions Security – code access security Interoperability – using existing COM components, calling Win32 functions Krzysztof
  • Safely Creating Correct Subclasses Without Superclass Code Clyde Dwain Ruby Iowa State University

    Safely Creating Correct Subclasses Without Superclass Code Clyde Dwain Ruby Iowa State University

    Iowa State University Capstones, Theses and Retrospective Theses and Dissertations Dissertations 2006 Modular subclass verification: safely creating correct subclasses without superclass code Clyde Dwain Ruby Iowa State University Follow this and additional works at: https://lib.dr.iastate.edu/rtd Part of the Computer Sciences Commons Recommended Citation Ruby, Clyde Dwain, "Modular subclass verification: safely creating correct subclasses without superclass code " (2006). Retrospective Theses and Dissertations. 1877. https://lib.dr.iastate.edu/rtd/1877 This Dissertation is brought to you for free and open access by the Iowa State University Capstones, Theses and Dissertations at Iowa State University Digital Repository. It has been accepted for inclusion in Retrospective Theses and Dissertations by an authorized administrator of Iowa State University Digital Repository. For more information, please contact [email protected]. Modular subclass verification: Safely creating correct subclasses without superclass code by Clyde Dwain Ruby A dissertation submitted to the graduate faculty in partial fulfillment of the requirements for the degree of DOCTOR OF PHILOSOPHY Major: Computer Science Program of Study Committee Gary T. Leavens, Major Professor Samik Basu Clifford Bergman Shashi K. Gadia Jonathan D. H. Smith Iowa State University Ames, Iowa 2006 Copyright © Clyde Dwain Ruby, 2006. All rights reserved. UMI Number: 3243833 Copyright 2006 by Ruby, Clyde Dwain All rights reserved. UMI Microform 3243833 Copyright 2007 by ProQuest Information and Learning Company. All rights reserved. This microform edition is protected against unauthorized copying under Title 17, United States Code. ProQuest Information and Learning Company 300 North Zeeb Road P.O. Box 1346 Ann Arbor, MI 48106-1346 ii TABLE OF CONTENTS ACKNOWLEDGEMENTS .
  • 3. Design by Contract

    3. Design by Contract

    3. Design by Contract Oscar Nierstrasz Design by Contract Bertrand Meyer, Touch of Class — Learning to Program Well with Objects and Contracts, Springer, 2009. 2 Bertrand Meyer is a French computer scientist who was a Professor at ETH Zürich (successor of Niklaus Wirth) from 2001-2015. He is best known as the inventor of “Design by Contract”, and as the designer of the Eiffel programming language, which provides built-in for DbC. DbC was first described in a technical report by Meyer in 1986: https://en.wikipedia.org/wiki/Design_by_contract Who’s to blame? The components fit but the system does not work. Who’s to blame? The component developer or the system integrator? 3 DbC makes clear the “contract” between a supplier (an object or “component”) and its client. When something goes wrong, the contract states whose fault it is. This simplifies both design and debugging. Why DbC? > Design by Contract —documents assumptions (what do objects expect?) —simplifies code (no special actions for failure) —aids debugging (identifies who’s to blame) 4 As we shall see, DbC improves your OO design in several ways. First, contracts make explicit the assumptions under which an object (supplier) will work correctly. Second, they simplify your code, since no special action is required when things go wrong — the exception handling framework provides the necessary tools. Third, contracts help in debugging since errors are caught earlier, when contracts are violated, not when your program crashes because of an invalid state, and it is clear where to lay the blame for the violation (i.e., in the object or its client).
  • FORTH-ICS / TR 381 July 2006 'An Informal Proof on the Contradictory

    FORTH-ICS / TR 381 July 2006 'An Informal Proof on the Contradictory

    FORTH-ICS / TR 381 July 2006 ‘An Informal Proof on the Contradictory Role of Finalizers in a Garbage Collection Context’ Anthony Savidis ABSTRACT Garbage collection in OOP languages provides facilities to hook code that is executed upon object finalization. Semantically, the point in time that finalizer code is executed is not determined by the application logic, but by the garbage collection system. This fact renders a potential mismatch, since application-specific code, i.e. the finalizer implementation, normally affecting program state and control flow, is called automatically at a point in time that is indifferent to the application semantics. Although an analogous situation is observed in event-based systems, since event processors are called-back asynchronously by the underlying system, there is a fundamental difference: while event generation is essentially nondeterministic, originated from external event sources, object destruction is a semantic action that is always decided by applications. In summary, the mismatch is that although applications decide if and when destruction occurs, the garbage collector is responsible to commit the relevant code. We prove that this mismatch is due to the contradictory presence of finalizers in a garbage collection context. Page 1 Introduction Preface This technical report has been also motivated by requests from colleagues to report the informal proof for the contradictory role of finalizers in garbage collection, simply relying on informal common software engineering principles. Additionally, the reporting has been also motivated by arguments that came to my attention via personal communication that either the claim cannot be proved (I assume that “cannot prove” arguments are subject to formal proofs, so such arguments are more weak than the claim they attack), or that the claim is trivial requiring essentially no proof (intuitively true, but does not explain why Java, C#, Python, just to name a few languages, still adopt finalizers).
  • A Machine-Checked Proof for a Translation of Event-B Machines to JML

    A Machine-Checked Proof for a Translation of Event-B Machines to JML

    A Machine-Checked Proof for a Translation of Event-B Machines to JML N´estorCata~no1,Camilo Rueda2, and Tim Wahls3 1 EAFIT Unviersity [email protected] 2 Camilo Rueda Pontificia Universidad Javeriana [email protected] 3 Tim Wahls Dickinson College [email protected] Abstract. We present a machine-checked soundness proof of a trans- lation of Event-B to the Java Modeling Language (JML). The transla- tion is based on an operator EB2Jml that maps Event-B events to JML method specifications, and deterministic and non-deterministic assign- ments to JML method post-conditions. This translation has previously been implemented as the EventB2Jml tool. We adopted a taking our own medicine approach in the formalisation of our proof so that Event-B as well as JML are formalised in Event-B and the proof is discharged with the Rodin platform. Hence, for any Event-B substitution (whether an event or an assignment) and for the JML method specification obtained by applying EventB2Jml to the substitution, we prove that the semantics of the JML method specification is simulated by the semantics of the sub- stitution. Therefore, the JML specification obtained as translation from the Event-B substitution is a refinement of the substitution. Our proof includes invariants and the standard Event-B initialising event, but it does not include full machines or Event-B contexts. We assume that the semantics of JML and Event-B operate both on the same initial and final states, and we justify our assumption. Keywords: Event-B, JML, EventB2Jml, Formal Proof, Translation, Rodin 1 Introduction arXiv:1309.2339v1 [cs.SE] 9 Sep 2013 In an earlier work [14], we have proposed a design methodology that combines the use of design-by-contract techniques with JML [36,29,33] and correctness-by- construction techniques with Event-B [1].
  • Verification of Object Oriented Programs Using Class Invariants

    Verification of Object Oriented Programs Using Class Invariants

    Verification of Object Oriented Programs Using Class Invariants Kees Huizing and Ruurd Kuiper and SOOP?? Eindhoven University of Technology, PO Box 513, 5600 MB Eindhoven, The Netherlands, [email protected], [email protected] Abstract A proof system is presented for the verification and derivation of object oriented pro- grams with as main features strong typing, dynamic binding, and inheritance. The proof system is inspired on Meyer’s system of class invariants [12] and remedies its unsound- ness, which is already recognized by Meyer. Dynamic binding is treated in a flexible way: when throughout the class hierarchy overriding methods respect the pre- and post- conditions of the overridden methods, very simple proof rules for method calls suffice; more powerful proof rules are supplied for cases where one cannot or does not want to follow this restriction. The proof system is complete relative to proofs for properties of pointers and the data domain. 1 Introduction Although formal verification is not very common in the discipline of object oriented programming, the importance of formal specification is generally ac- knowledged ([12]). With the increased interest in component based develop- ment, it becomes even more important that components are specified in an un- ambiguous manner, since users or buyers of components often have no other knowledge about a component than its specification and at the same time rely heavily on its correct functioning in their framework. The specification of a class, sometimes called contract, usually contains at least pre- and postcondi- tions for the public mehtods and a class invariant. A class invariant expresses which states of the objects of the class are consis- tent, or “legal”.
  • The Fields and the Class Invariant /** B[0..Size-1] Is a Min-Heap, I.E

    The Fields and the Class Invariant /** B[0..Size-1] Is a Min-Heap, I.E

    Heaps with priorities We previously studied the max-heap, which implements a bag of integers with insertion of a value and extraction (polling) of a maximum value in O(log n) time for a heap of size n. Min-heaps are similar. We now extend the idea to implement a min-heap of a set of distinct values each with a priority. The priority will be a double value. The separation of value from priority is needed in several different situations. Here are two: • Consider finding the shortest route from Ithaca, NY, to Washington, D.C. A heap will contain points along the way, and the priorities will be the shortest distances found thus far from Ithaca to those points. • In a discrete event simulation, pending events can be kept in a heap, with the priority being the time at which an event is to occur. Keeping the set in a min-heap makes it easy to extract the next event to process. We will define all the methods needed, but we won’t show many of the method bodies, since they are fairly easy to write based on the earlier discussion of max- and min-heaps. Class Heap and inner class Item /** A heap of elements of type E. */ We will implement a generic min-heap with priorities. The public class Heap<E> { start of class Heap appears to the right. An object of this class implements a heap of elements of type E. For example, E could private class Item { be a point on a map or an event to be simulated.
  • Programming with Windows Forms

    Programming with Windows Forms

    A P P E N D I X A ■ ■ ■ Programming with Windows Forms Since the release of the .NET platform (circa 2001), the base class libraries have included a particular API named Windows Forms, represented primarily by the System.Windows.Forms.dll assembly. The Windows Forms toolkit provides the types necessary to build desktop graphical user interfaces (GUIs), create custom controls, manage resources (e.g., string tables and icons), and perform other desktop- centric programming tasks. In addition, a separate API named GDI+ (represented by the System.Drawing.dll assembly) provides additional types that allow programmers to generate 2D graphics, interact with networked printers, and manipulate image data. The Windows Forms (and GDI+) APIs remain alive and well within the .NET 4.0 platform, and they will exist within the base class library for quite some time (arguably forever). However, Microsoft has shipped a brand new GUI toolkit called Windows Presentation Foundation (WPF) since the release of .NET 3.0. As you saw in Chapters 27-31, WPF provides a massive amount of horsepower that you can use to build bleeding-edge user interfaces, and it has become the preferred desktop API for today’s .NET graphical user interfaces. The point of this appendix, however, is to provide a tour of the traditional Windows Forms API. One reason it is helpful to understand the original programming model: you can find many existing Windows Forms applications out there that will need to be maintained for some time to come. Also, many desktop GUIs simply might not require the horsepower offered by WPF.