scispace - formally typeset
Search or ask a question

Showing papers presented at "Conference on Object-Oriented Programming Systems, Languages, and Applications in 1992"


Proceedings ArticleDOI
01 Dec 1992
TL;DR: WyCASH+ is a portfolio management system which provides basic accounting, record-keeping and reporting, as well as analytical computations to assist the manager of cash portfolios, and employs object technology in order to quickly and effectively address the diversity present in the market.
Abstract: U.S. pension funds, corporations, and banks invest billions of dollars in the " cash " markets. Cash securities are generally considered those with a remaining term to maturity of less than one year, but can include those with maturities as long as five years. Incredibly diverse in nature, cash securities are actually negotiated between issuer and buyer, and new security types are frequently introduced into the market. WyCASH+ is a portfolio management system which provides basic accounting, record-keeping and reporting, as well as analytical computations to assist the manager of cash portfolios. For the development of WyCASH+, Wyatt Software chose to employ object technology in order to quickly and effectively address the diversity present in the market. Objects help in two ways. First, many security types fit nicely into an inheritance hierarchy which is directly supported by our language (Smalltalk) saving us considerable effort in coding. Second, changing market demands often require massive revisions which we have been able to accommodate because of the modularity intrinsic in a totally object-oriented implementation. Our customers value our responsiveness as much as, if not more than, our product's fit to their current needs. We developed the product by incremental growth from a working prototype. Each member of our small engineering team maintains at least general knowledge of all aspects of the roughly four megabytes of source code. This includes some libraries provided by the vendor and others written to our specification by third-party contractors. Mature sections of the program have been revised or rewritten many times providing the consolidation that is key to understanding and continued incremental development. We found that some key implementation ideas were slow to emerge in the course of WyCash's development. Although many of our objects are derived directly from things or concepts that appear in documentation, and others were easily drawn from the collective experience of our programmers, a third, and more tantalizing, category of objects only surfaced through a process we could call Incremental Design Repair. We found these highly leveraged abstractions only because we were willing to reconsider architectural decisions in the light of recent experience. The same flexibility that allowed us to tackle diversity in our problem domain, specifically the flexibility afforded by the universal use of polymorphic messages sends (i.e. pure object-oriented programming), allowed us to include architectural revisions in the production program that would be judged too dangerous for inclusion under any other …

807 citations


Proceedings ArticleDOI
31 Oct 1992
TL;DR: This paper shows one way to document frameworks with patterns, and includes a set of patterns for HotDraw as an example to see how well patterns work to describe a framework.
Abstract: The documentation for a framework must meet several requirements. These requirements can all be met by structuring the documentation as a set of patterns, sometimes called a “pattern language”. Patterns can describe the purpose of a framework, can let application programmers use a framework without having to understand in detail how it works, and can teach many of the design details embodied in the framework. This paper shows how to use patterns to document a framework, and includes a set of patterns for HotDraw as an example. Christopher Alexander, an architect, developed the idea of a “pattern language” to enable people to design their own homes and communities [Alexander et. al.]. A pattern language is a set of patterns, each of which describes how to solve a particular kind of problem. His pattern language starts at a very large scale, explaining how the world should be broken into nations and nations into smaller regions, and goes on to explain how to arrange roads, parking, shopping, places to work, homes, and places of worship. The patterns focus on finer and finer levels of detail, passing though a discussion of how to arrange rooms in a house, and finally describing the type of material to use for walls, how to decorate rooms, and how to provide lighting. Alexander's pattern language is supposed to be a document that non-architects can use to design their own communities and homes. No specialized training is needed to use it. It focuses on common design problems that non-architects will encounter, like how to build bedrooms and row houses, rather than uncommon ones, like how to build concert halls and cathedrals. To be presented at OOPSLA’92. Although Alexander uses the term “pattern language” to describe his document, it is not a formal language like a context-free language, for example. A pattern language is a structured essay, not a mathematical object. Therefore, we will replace that term with the term “patterns”. A framework is a reusable design of a program or a part of a program expressed as a set of classes [Deutsch][Johnson and Foote]. Like all software, it is a mixture of the concrete and the abstract. Since frameworks are reusable designs, not just code, they are more abstract than most software, which makes documenting them difficult. Frameworks are designed by experts in a particular domain and then used by non-experts. The principal audience of framework documentation is someone who wants to use the framework to solve typical problems, not someone building a software cathedral. Patterns seem to be well suited for this audience. This paper shows one way to document frameworks with patterns. It is essentially an experiment to see how well patterns work to describe a framework. The result is a set of patterns that are included in the appendix. The main purpose of a set of patterns is to show how to use a framework, not to show how it works, but patterns can also describe a great deal of the theory of its design. 1. A Format for Patterns One of the important features of Alexander’s pattern language is its structure; each pattern is written in a particular format and patterns are arranged so that each pattern leads into the next. The format that Alexander uses is unlikely to be suitable for software. For example, since he is building physical objects, he requires pictures both for stating the problem that a pattern solves and for stating the solution. Thus, the patterns in this paper have a different format that the one he used. Each pattern describes a problem that occurs over and over again in the problem domain of the framework, and then describes how to solve that problem. Each pattern has the same format. The format used in this paper is to first give a description of the problem in italics. This is followed by a detailed discussion of the different ways to solve the problem, with examples and pointers to other parts of the framework. The pattern ends with a summary of the solution, again in italics, followed by pointers to other patterns that are needed to fill it out and embellish it. The appendix to this paper describes a set of ten patterns for HotDraw, a drawing framework. For example, pattern 4 is Pattern 4: Complex Figures Some figures have a visual presentation with internal structure. For example, they may have attributes that are displayed by other figures. It should be possible to compose them from simpler figures. Complicated figures like PERTEvent can be thought of as being composed of simpler figures. For example, a PERTEvent has a RectangleFigure and several TextFigures for the title, the duration, and the ending date. Complex figures like PERTEvent are subclasses of CompositeFigure. A CompositeFigure is a figure with other figures as components, and it displays itself by displaying its components. It has a bounding box that is independent of the bounding box of its components, and it will display its components only if they are inside of its bounding box. The selection tool and text tool will operation on its components when the left shift key is pressed. Custom tools can operate directly on the components, if you want.

453 citations



Proceedings ArticleDOI
31 Oct 1992
TL;DR: A range of write barrier implementations are examined and their relative performance within a generation scavenging garbage collector for Smalltalk is evaluated.
Abstract: Generational garbage collectors are able to achieve very small pause times by concentrating on the youngest (most recently allocated) objects when collecting, since objects have been observed to die young in many systems. Generational collectors must keep track of all pointers from older to younger generations, by “monitoring” all stores into the heap. This write barrier has been implemented in a number of ways, varying essentially in the granularity of the information observed and stored. Here we examine a range of write barrier implementations and evaluate their relative performance within a generation scavenging garbage collector for Smalltalk.

161 citations


Proceedings ArticleDOI
31 Oct 1992
TL;DR: The hierarchy of interfaces implicit in the Smalltalkcollection class library is computed and analyzed, demonstrating the utility of interfaces and specilications, and suggesting improvements to the collection class library structure.
Abstract: The hierarchy of interfaces implicit in the Smalltalkcollection class library is computed and analyzed. The interface hierarchy is independent of the inheritance hierarchy because methods are frequently deleted by subclasses, and because unrelated classes sometimes implement the same messages. Specifications of the interfaces are developed, revealing subtle relationships among messages and their methods. The specifications help identify several kinds of problems in the library: inherited methods that violate the subclass invariant; methods that have the same name but unrelated behaviors; methods that have the same (or related) behavior but different names. This exercise demonstrates the utility of interfaces and specilications, and suggests improvements to the collection class library structure.

109 citations



Proceedings ArticleDOI
31 Oct 1992
TL;DR: It is argued that emerging 64-bit architectures make it practical to support uniform naming at the virtual addressing level, eliminating a key implementation problem for object sharing systems.
Abstract: Object-oriented models are a popular basis for supporting uniform sharing of data and services in operating systems, distributed programming systems, and database systems. We term systems that use objects for these purposes object sharing systems. Operating systems in common use have nonuniform addressing models, making the uniform object naming required by object sharing systems expensive and difficult to implement. We argue that emerging 64-bit architectures make it practical to support uniform naming at the virtual addressing level, eliminating a key implementation problem for object sharing systems. We describe facilities for object-based sharing of persistent data and services in Opal, an operating system we are developing for paged 64-bit architectures. The distinctive feature of Opal is that object sharing is supported in a runtime library, a,bove a single virtual address space that maps all primary and secondary storage in a local area network. This work was supported in part by the National Science Foundation under Grants No. CCR-8619663 and CCR8907666; by the Washington Technology Center; and by Digital Equipment Corporation through the Systems Research Center, DECwest Engineering, the External Research Program, and the Graduate Engineering Education Program. Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notico is Siven that copving is bv permission of the Association for Computing Machinery. To copy otherwise. or to republish, requires B fee and/or specific permission. o 1992 ACM 0-89791.539.9/92/0010/0397...$1.50

83 citations


Proceedings ArticleDOI
31 Oct 1992

80 citations


Proceedings ArticleDOI
31 Oct 1992
TL;DR: The aim of this paper is to make software engineers aware of problems they may encounter during object-oriented development, and to inspire researchers to initiate new research activities.
Abstract: Recently, a considerable number of object-oriented software development methods have been introduced to produce extensible, reusable, and robust software. We have been involved in the development of a large number of pilot applications to form our own view on object-oriented methods. Although our experiences confirmed the claims about the benefits of object-oriented methods, we identified a number of important obstacles that are not addressed by current methods. This paper summarizes these obstacles and evaluates them with respect to our pilot applications. The aim of this paper is to make software engineers aware of problems they may encounter during object-oriented development, and to inspire researchers to initiate new research activities.

69 citations


Proceedings ArticleDOI
31 Oct 1992
TL;DR: In this paper, a project of building a pilot implementation of a swap valuation system using a comprehensive class library including an application framework is reported, emphasizing the use of so-called design patterns.
Abstract: Providing the financial engineering community with adequate software tools presents several challenges to application developers. Experience shows that reusability-oriented software development as supported by object technology has the potential to meet these challenges. To back the argument, a project of building a pilot implementation of a swap valuation system using a comprehensive class library including an application framework is reported. As a novelty the project emphasized the use of so-called design patterns. The project experience suggests that the use of design patterns significantly eases the application of a large class library and facilitates the reuse of design.

66 citations


Proceedings Article
01 Jan 1992
TL;DR: In this paper, the design and speci cation of extensible class libraries presents a challenge: because extensibility comes from allowing the user to override parts of the implementation, more of the internal structure must be exposed to the user than in a typical procedure library.
Abstract: The design and speci cation of an extensible class library presents a di cult challenge: because extensibility comes from allowing the user to override parts of the implementation, more of the internal structure must be exposed to the user than in a typical procedure library. This raises issues in both how the library is designed and how its speci cation is written. Speci cation of the CLOS Metaobject Protocol required a combination of new and existing techniques to address these issues. We present those techniques, and discuss their relation to the underlying issues.

Proceedings ArticleDOI
31 Oct 1992
TL;DR: Speci cation of the CLOS Metaobject Protocol required a combination of new and existing techniques to address issues, and a discussion of their relation to the underlying issues is discussed.
Abstract: The design and speci cation of an extensible class library presents a di cult challenge: because extensibility comes from allowing the user to override parts of the implementation, more of the internal structure must be exposed to the user than in a typical procedure library. This raises issues in both how the library is designed and how its speci cation is written. Speci cation of the CLOS Metaobject Protocol required a combination of new and existing techniques to address these issues. We present those techniques, and discuss their relation to the underlying issues.



Proceedings ArticleDOI
Pascal André1, Jean-Claude Royer1
31 Oct 1992

Proceedings ArticleDOI
31 Oct 1992
TL;DR: A new taxonomy of prototypebased languages is proposed, enhancing the Treaty of Orlando by now discussing issues associated with the different semantics of the identified prototype-based languages and an implementation of most interesting language alternatives in the form of a Smalltalk-80 platform is described.
Abstract: Prototype-based languages are currently proposed as a substitute to class-based languages for a higher flexibility in manipulating objects. These languages are all based on a similar set of basic principles: object-centered representation, dynamic addition (deletion) of slots, cloning and message delegation. But they all differ in the precise interpretation of these principles and nobody has yet considered the semantic issues raised by their combination. In this paper, we propose a new taxonomy of prototypebased languages, enhancing the Treaty of Orlando by now discussing issues associated with the different semantics of the identified prototype-based languages. From this taxonomy, we extract a constructive proposal for the design of a new prototype-based language. This proposal is the chief result of this paper; it suggests one set of primitives which is regarded as the best to provide a clean, useful and coherent prototype-based computational model. We finally describe an implementation of most interesting language alternatives in the form of a Smalltalk-80 platform. This platform establishes an operational semantics for the basic primitives and – more interesting – validates our previous taxonomy by implementing it as a class hierarchy. Obviously, this platform has been used to relate in the same formalism the semantics of different languages with each others. For instance, the programming models of existing languages, such as Self, ObjectLisp and Actra's examplars, are faithfully derived as subclasses in this hierarchy.

Proceedings ArticleDOI
31 Oct 1992
TL;DR: CACL is a protection scheme for objects that offers a simple and flexible model of protection and has an efficient, software-only implementation and offers a viable mechanism for finegrained protection in an object-oriented database system.
Abstract: CACL is a protection scheme for objects that offers a simple and flexible model of protection and has an efficient, software-only implementation. The model, based on Access Control Lists (ACLs) integrated with the type system, allows owners to control who may invoke which methods on which objects, permits cooperation between mutually suspicious principals, allows ownership of objects to be transferred safely, prevents unwanted propagation of authority between principals, and allows changes to the authorization information to take effect on the next method invocation. The implementation, based on the integration of Capabilities with method dispatch, avoids the overhead of access checking in the majority of invocations, at the cost of space for extra dispatch vectors. CACL offers a viable mechanism for finegrained protection in an object-oriented database system.

Proceedings ArticleDOI
31 Oct 1992

Proceedings ArticleDOI
31 Oct 1992
TL;DR: This paper presents interesting examples in which multiple inheritance known linearization algorithms behave badly, and carefully study the conditions which assure good linearizations.
Abstract: The main topic of this paper is multiple inheritance and conflict resolution methods in Object Oriented Programming. Our aim is to develop sound mechanisms easily understandable to any user. For this purpose, coherent behaviors of conflict resolution methods for multiple inheritance (such as supporting incrementality-monotonicity and stability under link subdivision) are introduced. We present interesting examples in which multiple inheritance known linearization algorithms (such as in CLOS [2] and LOOPS [19]) behave badly. Then we carefully study the conditions (on the inheritance graph) which assure good linearizations. We end with some suggestions for an incremental inheritance algorithm.


Proceedings ArticleDOI
31 Oct 1992
TL;DR: The overall structure of the project and the system model, the usefulness of OMT and its impact on communication, and some of the problems encountered during the development of the system are described.
Abstract: We describe our experience with the object-oriented design methodology OMT [19] applied to a project in an undergraduate software engineering course at Carnegie Mellon University. The project involved 30 students previously unfamiliar with objectoriented modeling. They designed and implemented a system of 125 classes (27,000 lines of C++ and C code) in the relatively short time of 15 weeks. We describe the overall structure of the project and the system model, the usefulness of OMT and its impact on communication, and discuss some of the problems encountered during the development of the system.

Proceedings ArticleDOI
01 Dec 1992
TL;DR: Biologically active material is immobilized by forming a gel precursor containing the biologically active material, a polymerizable material and a viscosity enhancing agent, and gelling the gel precursor by polymerization to form a hydrogel containing the biological active material on the support material.
Abstract: Biologically active material is immobilized by forming a gel precursor containing the biologically active material, a polymerizable material and a viscosity enhancing agent, applying the gel precursor to a support material and gelling the gel precursor by polymerization to form a hydrogel containing the biologically active material on the support material. A least some of the hydrogel is enmeshed with the support material. By use of the viscosity enhancing agent, the gel precursor is provided with preferred rheological properties.

Proceedings ArticleDOI
31 Oct 1992

Proceedings ArticleDOI
31 Oct 1992
TL;DR: It is shown how an OSA user’s use of formalism can be tuned from completely informal to completely formal, as a two-step process involving a temporal, first-order logic language, and a mathematical interpretation.
Abstract: † This work has been partially supported by HewlettPackard through graduate fellowships and equipment grants. Object-oriented Systems Analysis (OSA) [7] meets the needs of both theoreticians and practitioners by providing tunable formalism. In this paper, we show how an OSA user’s use of formalism can be tuned from completely informal to completely formal. We give OSA’s underlying formal definition that makes this possible as a two-step process involving a temporal, first-order logic language, and a mathematical interpretation. We also show how the formal definition provides answers to fundamental, practical questions related to object-oriented software development. Finally, we show how OSA allows varying levels of abstraction and completion so that engineers, tool builders, and researchers can tune the formalism to suit their needs.

Proceedings ArticleDOI
31 Oct 1992


Proceedings ArticleDOI
01 Dec 1992
TL;DR: A silver halide photographic light-sensitive material and a developing process used in connection with that material are disclosed and are capable of providing good letter image quality in a short developing time.
Abstract: A silver halide photographic light-sensitive material and a developing process used in connection with that material are disclosed. The material is comprised of a support having thereon a silver halide emulsion layer containing a silver halide emulsion in which at least 80 mole % of the whole silver halide is composed of silver chloride, the mean grain size thereof is less than 0.4 mu m, and which contains more than 1x10-6 mole of a water-soluble rhodium salt per mole of silver at an optional period before finishing the first ripening in the production step for the silver halide emulsion. The material also contains 1x10-5 to 1x10-2 mole of polyalkylene oxide having a molecular weight of at least 600 or a derivative thereof per mole of silver. The process involves imagewise exposing the material and processing it in a developer containing 0.05 to 0.5 mole/liter of a dihydroxybenzene series developing agent, 0 to 0.05 g/liter of an auxiliary developing agent, at least 0.25 mole/liter of a free sulfite ion, at least 20 mg/liter of 5- or 6-nitroindazole, and an alkali of an amount sufficient for keeping the pH of the developer higher than 10.5. The material and processing are capable of providing good letter image quality in a short developing time.


Proceedings ArticleDOI
01 Dec 1992
TL;DR: New polymers are disclosed which absorb or emit photons in the visible or ultraviolet spectrum which are useful as reagents for the detection of substances in physiological fluids.
Abstract: New polymers are disclosed which absorb or emit photons in the visible or ultraviolet spectrum. The polymers when bound to ligands or receptors are useful as reagents for the detection of substances in physiological fluids. Also disclosed are methods of preparing said polymers and reagents and methods of employing said reagents in immunoassay systems.

Proceedings ArticleDOI
31 Oct 1992
TL;DR: Two timed equivalences based on CCS's bisimulation are derived and derive algebraic laws for reasoning about real-time processes and provide a formal framework for analyzing the behavior and timing of real- time computations.
Abstract: We investigate a formal model for reasoning about real-time object-oriented computations. The model is an extension of CCS with the notion of time, called RtCCS (Real-time Calculus of Communication Systems). It can naturally model real-time concurrent objects as communicating processes and represent the timed properties of objects. We dene two timed equivalences based on CCS's bisimulation and derive algebraic laws for reasoning about real-time processes. The equivalences provide a formal framework for analyzing the behavior and timing of real-time computations. Also, we de ne a sound and complete equational proof system for nite processes. Some examples in RtCCS are shown in order to demonstrate its usefulness. Proceedings of ACM OOPSLA'92