Construction of robust class hierarchies

Frick, Arne; Goos, Gerhard; Neumann, Rainer; Zimmermann, Wolf

doi:10.1002/(sici)1097-024x(20000425)30:5<481::aid-spe299>3.3.co;2-j

Cited by 4 publications

(12 citation statements)

References 9 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…is equal(e) : BOOL (5) pre: true (6) post: unchanged ∧ unchanged(e) ∧ res = (src = e.src ∧ dest = e.dest) (7) res := src = e.src ∧ dest = e.dest; (8) end; (9) end;…”

Section: Inheritance Anomaliesmentioning

confidence: 99%

“…See Frick et al [5,7] and Frigo et al [8] The predicates in Theorem 6 are type bounds. Type bounds can be viewed as predicates on the parameters of generic classes.…”

Section: Conformance Hierarchies Of Generic Classesmentioning

confidence: 99%

“…Section 6 introduces our generator-based methods to automatically generate class hierarchies from small specifications. Although the number of abstract classes may grow exponentially [5,7], which makes a manual implementation of the solution impractical † , the good news is that every solution can be generated from the same comparatively small specification [8], and that only those classes that are actually required by the library user must be generated. Therefore, an interactive user-interface should be provided for supporting the library user to identify and generate the required classes makes our approach feasible.…”

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

Construction of robust class hierarchies

Frick

Goos

Neumann

et al. 2000

Softw: Pract. Exper.

Self Cite

View full text Add to dashboard Cite

This article discusses the problem of constructing robust class libraries. Further design criteria include the flexibility of class libraries, the efficiency of the implementations, and their safe extensibility. We show that it is possible to design robust libraries to satisfy any two of the requirements at the same time. Although the solution may require an exponential growth in the number of classes compared to the original design, this apparent class explosion can be controlled by generating only the necessary additional classes automatically. As an application demonstrating both the theoretical problems and the power of our generator approach, the design of a library modelling data structures and algorithms for graphs is considered. Both the discussion and the results in this article generalize to other domains. A. FRICK ET AL.with components a 1 , . . . , a n where a i contains a value of type T i if T i is a basic type, and a reference to an object of type T i otherwise. The state of an object o comprises the values and references of its components, together with the states of the referenced objects. If x : T is an attribute and T is a type with attribute y : T , then x.y denotes the reference or value denoted by the y-attribute of T of the object referenced by x. This notation is extended inductively in the straightforward way. The operation #A creates a new object and returns a reference to it. The equality of objects is based on their reference, i.e. on object identities. However, sometimes structural equality is used. This notion is based on the fact that objects can be viewed as vertices of a directed graph and references as edges (e.g. see Schmidt and Zimmermann [9,10]). Two objects are structurally equal iff their directed graphs are isomorphic.The interface of a method declares the signature with its parameters. m(x 1 : T 1 , . . . , x k : T k ) : T denotes a method m with signature m : T 1 × · · · × T k → T , where parameter x i is a variable of type T i , i = 1, . . . , k. T = VOID iff m is a procedure. Methods may have an implementation in a particular programming language. In our case, we also consider methods without implementations. These methods are called abstract. An abstract class is a class that contains abstract methods. Classes without abstract methods are called implementation classes. In our article, abstract classes are denoted by the keyword abstract.In our examples, we use the language SATHER-K [11] for implementing methods. We just use the usual control structures of while-loops, for-loops, and conditionals with their usual semantics ‡ . The lhs := rhs operator denotes an assignment. It means that if lhs is an object of a basic type, then the value denoted by rhs will be the content of lhs. Otherwise, rhs denotes a reference to an object which is copied to lhs. Within the implementation of a function, res denotes the value/reference to be returned.

show abstract

“…is equal(e) : BOOL (5) pre: true (6) post: unchanged ∧ unchanged(e) ∧ res = (src = e.src ∧ dest = e.dest) (7) res := src = e.src ∧ dest = e.dest; (8) end; (9) end;…”

Section: Inheritance Anomaliesmentioning

confidence: 99%

“…See Frick et al [5,7] and Frigo et al [8] The predicates in Theorem 6 are type bounds. Type bounds can be viewed as predicates on the parameters of generic classes.…”

Section: Conformance Hierarchies Of Generic Classesmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Construction of robust class hierarchies

Frick

Goos

Neumann

et al. 2000

Softw: Pract. Exper.

Self Cite

View full text Add to dashboard Cite

show abstract

“…The question at this point is: How can checks, that determine whether or not a method may be called, be inserted automatically. The answer to this is easy: Non-conforming methods are generally covariant in the sense of [10]. This means that they usually only restrict their applicability by strengthening their precondition.…”

Section: Handling Critical Polymorphic Methods Callsmentioning

confidence: 99%

“…To preserve substitutability [10] and [12] propose a transformation of such structures. A detailed discussion of the transformation containing an optimal algorithm for this task can be found in [21].…”

mentioning

confidence: 99%

Weak subtyping-yet another notion of inheritance

Löwe

Neumann²,

Trapp³

et al.

Proceedings. Technology of Object-Oriented Languages. TOOLS 26 (Cat. No.98EX176)

Self Cite

View full text Add to dashboard Cite

Reuse in polymorphic systems strongly depends on correct use of inheritance. There have been many efforts to check whether or not subtyping is correct. All of these approaches either restrict the use of inheritance, customize the class hierarchies in an application specific way or use proof theoretical techniques. This is often too restrictive or even impossible -at least for practical use. In order to provide both -flexibility and robustness -this paper introduces the concept of weak conformance. This concept allows the specification of specialized classes that may be used in a polymorphic context. The main idea is to check conformance in the context of a concrete application. Furthermore, the paper demonstrates how the proposed concept can easily be integrated into any programming language and introduces an algorithm for checking robustness of an application. This algorithm detects all critical and illegal polymorphic method calls that may violate the robustness. Finally the paper discusses ways of how to handle critical calls, i.e. calls that can be proven correct by the developer but not by the type system. IntroductionThe main goal of software engineering efforts is to build efficient and robust systems at low costs. In order to reach this goal it is required to build flexible and adaptable systems, e.g. using frameworks. The main idea of such systems is to provide several interfaces or ports, respectively, that allow application developers to plug in their own components. In systems such as X-Windows the plugged in components are called using call-back functions. Early approaches used typed function pointers to implement those call-backs in languages such as C. Modern object-oriented systems like OpenStep, Java-Beans, Corba, or COM use abstract interface classes to specify required behavior of plug-in components. This idea is not new -operating systems like Unix or Windows-NT use the concept of standardized interfaces to be able to plug device drivers into the system.Object-oriented languages allow the specification of behavior on an abstract level. This means that frameworks or extendable systems specify the expected behavior for plug-ins using abstract classes. In order to build an application based on that framework, the application developer simply has to build classes that inherit from that interface class to show conformance. This allows to exchange the components plugged into the framework even dynamically and hence build flexible systems. The base technology for dynamic exchangeability in object-oriented systems is polymorphism. The paper considers subtype polymorphism as the basic mechanism for abstraction rather than generic polymorphism. The reason for that is that the extension of existing systems is usually done by building own classes that inherit from classes taken out of libraries. The Principle of Substitutability [34] requires that instances of subclasses may substitute instances of superclasses in any context. Contra-covariance of pre-and postconditions as presented in [4,1] guarantees th...

show abstract

Reflective designs

Hirschfeld

Lämmel

2005

IEE Proc., Softw.

View full text Add to dashboard Cite

The authors render runtime system adaptations by design-level concepts such that running systems can be adapted and examined at a higher level of abstraction. The overall idea is to express design decisions as applications of design operators to be carried out at runtime. Design operators can implement design patterns for use at runtime. Applications of design operators are made explicit as design elements in the running system such that they can be traced, reconfigured, and made undone. This approach enables reflective designs: on one side, design operators employ reflection to perform runtime adaptations; on the other side, design elements provide an additional reflection protocol to examine and configure performed adaptations. The approach helps understanding the development and the maintenance of the class of software systems that cannot tolerate downtime or frequent shutdown-revise-startup cycles. The authors have designed and implemented a class library for programming with reflective designs in Squeak/Smalltalk. The library employs reflection and dynamic aspect-oriented programming. In addition to that, the authors have implemented tool support for versatile navigation in a system that is adapted continuously at runtime.

show abstract

Construction of robust class hierarchies

Cited by 4 publications

References 9 publications

Construction of robust class hierarchies

Construction of robust class hierarchies

Weak subtyping-yet another notion of inheritance

Reflective designs

Contact Info

Product

Resources

About