Topic
Class invariant
About: Class invariant is a research topic. Over the lifetime, 58 publications have been published within this topic receiving 1604 citations.
Papers published on a yearly basis
Papers
Book•
1 Jan 1999
TL;DR: This monograph discusses object orientation as an engineering discipline, the principles of type conformance, and the design criteria governing interacting levels of encapsulation.
Abstract: I INTRODUCTION 1 What does it mean to be object oriented, anyway? Encapsulation Information / implementation hiding State retention Object identity Messages Message structure Message arguments The roles of objects in messages Types of messages Classes Inheritance Polymorphism Genericity 2 Object orientation--who ordered that? Where did object orientation come from? Larry Constantine OJ Dahl and K Nygaard Alan Kay, Adele Goldberg and others Edsger Dijkstra Barbara Liskov David Parnas Jean Ichbiah and others Bjarne Stroustrup Bertrand Meyer 0 Grady Booch, Ivar Jacobson and Jim Rumbaugh Object orientation in a social context The history of the mainstream To the barricades: the object-oriented revolutionaries Forward to the past: the object-oriented reactionaries Enter the evolutionists (stage middle) Object orientation as an engineering discipline What's object orientation good for? Analyzing users' requirements Designing software Constructing software Maintaining software Using software Managing software projects II UML NOTATION 3 The basic notation for classes, attributes and operations The class symbol Notation for attributes Notation for operations Overloaded operations Public, protected and private features Class attributes and operations Abstract classes and features The utility Parameterized classes 4 Class diagrams The generalization construct Single inheritance Multiple inheritance Subclass partitioning Partitioning discriminators The association construct The basic UML notation for associations Associations depicted as classes Higher-order associations Navigability of associations "Whole / part" associations Composition Aggregation 5 Object-interaction diagrams The collaboration diagram Depicting a message Polymorphism in the collaboration diagram Iterated messages Use of self in messages The sequence diagram Asynchronous messages and concurrent execution Depicting an asynchronous message The callback mechanism Asynchronous messages with priority Depicting a broadcast (non-targeted) message 6 State diagrams Basic state diagrams Nested states Concurrent states and synchronization Transient states from message-result arguments Continuously variable attributes 7 Additional design diagrams Depicting system architecture Packages Deployment diagrams for hardware components Deployment diagrams for software components Depicting the human interface The window-layout diagram The window-navigation diagram A brief digression: what's object-oriented about a GUI? III FUNDAMENTAL DESIGN PRINCIPLES 8 Encapsulation and connascence Encapsulation structure Levels of encapsulation Design criteria governing interacting levels of encapsulation Connascence Varieties of connascence Contranascence Connascence and encapsulation boundaries Connascence and maintainability Connascence abuses in object-oriented systems 9 Domains, encumbrance and cohesion Domains of object classes The foundation domain The architectural domain The business domain The application domain The source of classes in each domain Encumbrance Definition of encumbrance The use of encumbrance The Law of Demeter Class cohesion: a class and its features Mixed-instance cohesion Mixed-domain cohesion Mixed-role cohesion 10 State space and behavior State-space and behavior of a class The state-space of a subclass The behavior of a subclass The class invariant as a restriction on a state-space Preconditions and postconditions 11 Principles of robust class hierarchies The principle of type conformance Subclasses as subtypes Conformance: the principles of contravariance and covariance An example of contravariance and covariance A graphic illustration of contravariance and covariance A summary of the requirements for type conformance The principle of closed behavior 12 The perils of inheritance and polymorphism Abuses of inheritance Mistaken aggregates Inverted hierarchy Confusing class and instance Misapplying is a The danger of polymorphism Polymorphism of operations Polymorphism of variables Polymorphism in messages Polymorphism and genericity 13 Organizing features Mix-in classes A business example A graphics example Rings of operations 14 Quality of a class interface State support in a class interface Behavior support in a class interface Operation cohesion in a class interface 15 Development of an object-oriented component Appendices Appendix A Checklist for an object-oriented design walkthrough Appendix B The object-oriented design owner's manual Bibliography Glossary Index 020169946XT04062001
184 citations
Book•
1 Aug 1992TL;DR: Part 1 Design by contract, Bertrand Meyer: scope mothion of contract assertion - contracting for software class invariant and class correctness more on assertions dealing with abnormal situations.
Abstract: Part 1 Design by contract, Bertrand Meyer: scope mothion of contract assertion - contracting for software class invariant and class correctness more on assertions dealing with abnormal situations principles of exception handling a disciplined exception handling mechanism inheritance and dynamic binding a plea for partial functions. Part 2 The new culture of software developments - reflections on the practice of object-oriented design, Bertrand Meyer: the two cultures cohabitation generalization some organization aspects lifecycle - the clester model. Part 3 An object-oriented approach to domain analysis, Sally Shlaer and Stephen Mellor: conceptual entities and associations state models interactions between objects process models experiences with object-oriented analysis. Part 4 Active software objects in a knowledge-based lifecycle support environment, Axel van Lamswerde: overview of the ALMA environment kernel an architecture for generic lifecycle support putting more semantics in SLC models - constraints making SLC objects active by rule attachment. Part 5 On eclectic specification environments, Carlo Ghezzi and Dino Mandrioli: some examples on the eclectic use of models in specification from the methodology to an environment - a few preliminary steps. Part 6 Distributed software design techniques, Mehdi Jazayeri: history and motivation for distributed systems approaches to building distributed software design techniques for reliability and efficiency examples of distributed algorithms summary and conclusions. Part 7 A tour of Hybrid - a language for programming with active objects, Oscar Nierstrasz: objects and threads an overview of Hybrid communication and concurrency in Hybrid implementation observations. Part 8 An object-based architecture for real-time applications, Libero Nigro and Francesco Tisato: objects grouping and controlling objects building a system. Part 9 Eiffel network simulator a development in Eiffel - design and implementation of a network simulator, Cyrille Gindre and Frederique Scola: the application - a communication network simulator design and implementation applying object-oriented concepts qualitative assessment quantitative assessment.
105 citations
7 Jan 2008
TL;DR: A fresh approach to OO verification is advocated that focuses on the distinction and relation between specifications that cater to calls with static dispatching from those for calls with dynamic dispatching, and formulate a novel specification subsumption that can avoid code re-verification, where possible.
Abstract: Conventional specifications for object-oriented (OO) programs must adhere to behavioral subtyping in support of class inheritance and method overriding. However, this requirement inherently weakens the specifications of overridden methods in superclasses, leading to imprecision during program reasoning. To address this, we advocate a fresh approach to OO verification that focuses on the distinction and relation between specifications that cater to calls with static dispatching from those for calls with dynamic dispatching. We formulate a novel specification subsumption that can avoid code re-verification, where possible. Using a predicate mechanism, we propose a flexible scheme for supporting class invariant and lossless casting. Our aim is to lay the foundation for a practical verification system that is precise, concise and modular for sequential OO programs. We exploit the separation logic formalism to achieve this.
69 citations
11 Jan 2004
TL;DR: A generic framework for the automatic and modular inference of sound class invariants for class-based object oriented languages is presented and it is shown how a class invariant can be characterized as the solution of a set of equations extracted from the program source.
Abstract: We present a generic framework for the automatic and modular inference of sound class invariants for class-based object oriented languages. The idea is to derive a sound class invariant as a conservative abstraction of the class semantics. In particular we show how a class invariant can be characterized as the solution of a set of equations extracted from the program source. Once a static analysis for the method bodies is supplied, a solution for the former equation system can be iteratively computed. Thus, the class invariant can be automatically inferred. Moreover, our framework is modular since it allows the derivation of class invariants without any hypothesis on the instantiation context and, in the case of subclassing, without accessing to the parent code.
52 citations
14 Jun 1999
TL;DR: In this paper, the authors present a verification of an invariant property for the Vector class from JAVA's standard library (API) from the point of view of data integrity.
Abstract: This paper presents a verification of an invariant property for the Vector class from JAVA’s standard library (API). The property says (essentially) that the actual size of a vector is less than or equal to its capacity. It is shown that this “safety” or “data integrity” property is maintained by all methods of the Vector class, and that it holds for all objects created by the constructors of the Vector class. The verification of the Vector class invariant is done with the proof tool PVS. It is based on a semantics of JAVA in higher order logic. The latter is incorporated in a special purpose compiler, the LOOP tool, which translates JAVA classes into logical theories. It has been applied to the Vector class for this case study. The actual verification takes into account the object-oriented character of JAVA: (non-final) methods may always be overridden, so that one cannot rely on a particular implementation. Instead, one has to reason from method specifications in such cases. This project demonstrates the feasibility of tool-assisted verification of non-trivial properties for non-trivial JAVA classes.
46 citations
Related Topics (5)
Performance Metrics
| Year | Papers |
|---|---|
| 2021 | 1 |
| 2018 | 1 |
| 2017 | 1 |
| 2016 | 4 |
| 2015 | 1 |
| 2014 | 5 |