Three Steps to Views: Extending the Object ... - Semantic Scholar

Extending

Three Steps to Views: the Object-Oriented Paradigm John J. Shilling Georgia Institute of Technology IBM

Peter F. Sweeney T. J. Watson Research Center

Abstract At the core of any sophisticated software development and maintenance environment is a large mass of complex data. The data (the central data of the environment) is composed of smaller sets of data that can be related in complicated and often subtle ways. The user or developer of the environment will be more effective if they are able to deal with conceptual slices, or views, of the large, complex structure. This paper presents an architectural building block for object-based software environments based on the views concept. The building block allows the construction of global abstractions that describe unified behavior of large sets of objects. The basis of the architecture relies on extending the objectoriented paradigm in three steps: (1) defining multiple interfaces in object classes; (2) controlling visibility of instance variables; and (3) allowing multiple copies of an instance variable to occur within an object instance. This paper focuses on the technical aspects of the views approach.

Introduction A view is a simplifying abstraction of a complex structure. It is useful because it emphasizes a single aspect of the structure, suppressing information not relevant to the current focus. By understanding the subcomponents of a structure, and how they interact, one may understand the whole. This paper presents views in the context of a particular application: software development and maintenance environments. A complete software development environment must support the growth of a software system 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 notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission. 0 1989 ACM 089791-333-7/89/0010/0353 $1.50

October 1-6, 1989

from its inception, through design and implementation, and into deployment and maintenance. It must support version and configuration control, testing and debugging. It must support traceability. That is, the ability to trace the specification of a feature through design and into implementation, and the ability to determine, given an implementation, from what specification and design elements it is derived. The environment is the center of many activities, each with its specialized software representation and specific methods. At the center of the environment is the software system under development. The software system is not a single homogeneous unit, however, because of the many development activities and the demands of each. It is rather a set of representations that are related in complex and often subtle ways. These representations may be considered slices (or views) of the more complex structure that encompasses the software system as a whole. The environment must manage the complex total structure of a software system but users must be given a set of simpler views. Similarly, the developer of environment tools should be able to concentrate on abstractions that represent individual activities (note that activities overlap). This paper presents an encapsulation and abstraction framework that allows users and tool developers to be presented with simplifying views while still maintaining the consistency of the whole. The work is motivated by the needs of software development environments but it is not limited to that context. The only assumptions made are that the structures of the environment are composed of object instances, the relationships between the object instances are modeled explicitly, and an object instance has a unique identity that is persistent through time. This paper presents extensions to the object-oriented paradigm that allow views to be implemented by (1) defining multiple interfaces in object classes; (2) controlling visibility of instance variables; and (3) allowing

OOPSLA ‘89 Proceedings

353

Class COOP:

Class VOOP:

Instance of Class COOP: Figure 2: Object Class with Multiple Interfaces Class COOP Vl 212 E3 Figure 1: Conventional Object Class and Instance multiple copies of an instance variable to occur within an object instance. We begin by summarizing the conventional object-oriented paradigm as a basis for the extensions that follow. Presentation of the extensions is followed by a description of the use of this approach to views and a discussion of implementation. A summary of related work is then presented. Readers who wish to consider the material in light of the previous work may wish to read the last section first.

Conventional

Object-Oriented

Paradigm

The concepts introduced in this paper are presented as a series of modifications to the conventional objectoriented paradigm. In this section we present a brief description of the relevant elements of the paradigm as a basis for what follows. An object class is an abstract data type combined with a mechanism for reuse. The interface to an object is composed of a set of methods, each of which has a name, a signature, and a binding to a method implementation’. A method may be defined locally in a class or may be inherited’. An object class definition defines a template for the set of instance variables that will be present, within an instance of the class. Instance variables may also be inherited. The entire set of instance variables defined within an object class is visible to each method implementation defined within that class (flat name space for data). Similarly, the set of methods defined in a class form a single interface that is visible to all clients (flat name space for methods). An object class defines a single abstract data type. An instance of the class has a single type and contains a single set, of instance data. It will be useful in this presentation to draw diagrams ‘The binding of methods to method implementations is implicit in the conventional paradigm. We explicitly mention the binding because it is used in our work. 2We use the term inheritance loosely here. The actual mechanism by which methods and instance variables of super classes are visible is not important in this presentation

354

of object classes and object instances. Figure 1 shows a diagram of a conventional object class and object instance. The diagram shows an object class COOP which has interface {A, B, C}. Interface method A is bound to implementation Ml, B to Ma, and C to Ma. Method bindings (denoted by a a) are shown separately from the method declarations and internal method implementations. The diagrams represents the method implementations by Ml, Mz and MS, and the instance variables by VI and ~2. The object instance in the diagram contains its class name and the instance variables ~1 and ~2. The following sections will present modifications to the conventional object-oriented paradigm. The key characteristics that will be altered are that an object class defines a single type with a single interface and a flat name space, and that an object instance contains a single, monolithic set of instance variables.

Step

1: Objects

with

Multiple

Interfaces

The first step in providing support for views is to allow an object class to define multiple distinct interfaces. Each interface defines a set of methods and each method of each interface is independently bound to an implementation. An interface represents an activity in which an object instance of the class will participate, and determines the object’s behavior by the set of methods and implementations that the interface provides. Because interfaces are distinct there may be methods in several interfaces with the same name. The interface methods are independent, may have different signatures and may be bound to distinct implementations. The specifications of interfaces and binding of methods to implementations are treated as separate issues. This provides for greater reuse of method implementations since methods may bind to the same implementation if the method signatures match and they desire the same semantics. A diagram of an object class definition with multiple interfaces is shown in Figure 2. Each interface contains a method A that is bound to implementation Ml. Each contains a method named B but, it is bound to implementation M2 in interface 11 and to implementation M4 in interface 1,. Finally, each interface contains a method

OOPSLA ‘89 Proceedings

October l-6, 1989

Class VOOP:

11

A B C

+ 441 * M2 j h&

Ml M2 A43 M4

~1: 212,213:

v4: v5:

.12(M) II(M), 12(M) Ii(R), Is(M) I1 M

Ml-i= G it& e

M4

A B D

I2

Figure 3: Object Class with Labeled Instance Variables that is not present in the other, although they both bind to a common implementation. It is important to note that multiple interfaces as described here implicitly distinguish method names according to an interface. This is not magic. An instance of the class may be accessed through either interface. To distinguish between interfaces, we simply extend the selection criteria of the conventional objectoriented paradigm to include the interface with the object class when determining which method implementa tion to choose. Just as the same method may behave differently in different objects, the same methods may behave differently in different interfaces of the same object. Hence the display-yourself-as-a-tree interface may have a display method that is different from the display method of the display-yourself-as-a-nested-boxinterface. Although both methods have the same name, they may or may not have the same signature and they certainly would not have the same behavior. Allowing an object to define multiple interfaces is the first step to achieving the support for views because it allows an object to realize different and independent sets of behaviors. The class defines one set of instance variables that is visible to each interface but each interface may use the data differently. We will see later that view classes are specified in terms of interfaces of object classes.

Step 2: Visibility

of Instance

Variables

The second step in providing support for views is to control the visibility of instance variables within an object class. Each instance variable is labeled with the names of the interfaces to which the variable will be visible. Each instance variable may further be identified as modifiable or read-only with respect to an interface3. A diagram illustrating the labeling is presented in Figure 3. The set of instance variables visible to interface 11 is iv2,~3,~4,~5 } and the set of instance variables visible to interface 1s is { wr ,212,‘us, ~4). Variable ~4 is read-only in interface Il. 3The acce.ss permission of an instance variable can generalize into monitors that perform an arbitrary method if the instance variable is accessed. For the purposes of this paper, we do not discuss this issue.

October 1-6, 1989

Labeling the instance variables has several effects. The first and most obvious effect is information hiding. If an instance variable is not labeled by an interface’s name, then the instance variable is not visible to the method implementations of that interface. This makes it possible for an interface to maintain private instance variables that may not be accessed by other interfaces. It also becomes possible for a subset of the set of interfaces to share instance variables. Labeling an instance variable as read-only by an interface allows a form of limited sharing between interfaces. An interface may share information with another interface without worrying that the interface will alter the data (this is not the same as asking through an external method of the interface as that would allow other external agents to access the value as well). A second effect of labeling the instance variables is that several instance variables of the same name may exist as long as no two are visible to the same interface. This has the advantage of convenience in that we do not unnecessarily constrain the implementor. A more important effect is that methods in separate interfaces may share a single implementation but have the implementation use different instance variables. For example, two interfaces may each define a private variable name parent and may share an implementation that uses an instance variable named parent. When the implementation is invoked in an object instance, the instance variable actually used by the implementation will be the one that is visible to the interface that invokes it. An object class may define many interfaces but it is not required that all interfaces be active in an instance of that class. A implementation effect of labeling instance variables is that an object instance needs only to contain instance variables that are visible to interfaces which are active. The set of instance variables visible to an active interface is termed an activation of that interface.

Step 3: Copies

of Instance

Variable

Sets

The final step in supporting views is to allow multiple copies of instance variables to occur within an object instance. Consider the set of instance variables visible to an interface declared in a object class. This extension

OOPSLA ‘89 Proceedings

355

Instance of Class VOOP:

instance of Class VOOP:

Class VOOP Interface 12, Activation Vl,

Class VOOP Interface

Al

v2, 213, 04

Interface I2, Activation Vl, v2, v3, 214

1 Interface

I

Copies of Instance Variables

Consider the object class definition of Figure 3. The class defines two interfaces: 11 and Iz. An instance of the class appears in Figure 4. The object instance contains two activations of interface Is. A new label has been introduced into the diagram. Because an object instance may contain in multiple activations of the same interface, the name of the interface is no longer sufficient to identify the instance variables that are being referenced. An additional piece of information, termed the activation identifier, is needed to distinguish interface activations4. The activation identifier is used along with interface name to present the correct set of instance variables to to method implementations. The activations of an interface in an object instance may overlap. Consider the object instance of Figure 5. The object can also be an instance of the object class defined in Figure 3 but in this case contains in an activation of interface Ii as well as two activations of interface 12. All of the activations share the instance variables “2, us, and ~4. Note that in Figure 4 no instance variables in the activations of interface 12 are shared but in Figure 5 all instance variables except VI are shared in the activations of interface Is. The sharing behavior of instance variables within an object instance that contains multiple activations of the same interface is controlled by specifications within object classes but is at a level of detail beyond the scope of this paper. Allowing multiple copies of instance variable sets is important because it allows an object instance to exhibit context dependent execution of the same general behavior. 4Activation identifiersin which are introduced

356

views are actually later.

view instance

Aa 1

4, Actlvatron

Al

v5

states that an instance of the class may have multiple copies of that set of instance variables. Each copy corresponds to a different activation of the same interface and is thus a different instance of the behavior provided by that interface. It is this characteristic of our approach that provides much of the flexibility.

tifiers

-.

1~. Activation Vl

Interface Figure 4: Multiple

Al

Vl

i

A2

12, Activation

iden-

Figure 5: Multiple

View

Classes

Copies of Instance Variables

and View

Instances

In this section we describe how the object extensions are used to create view classes and view instances. A view class is a global abstraction which uses many object classes to provide a unified global behavior. It can be thought of as defining an abstract class of structures. Conventional examples include the form and behavior of an abstract syntax tree and the form and behavior of a da-taflow diagram. Just as it is necessary to distinguish between an object class and an object instance it is necessary to distinguish between a view class and a view instance. A view instance is simply an instantiation of a view class and should be thought of as a concrete instance of the abstract structure class defined by the view class. A view class is specified as a set of ordered pairs of the form (object class, interface). Each object class listed in the specification of a view class is said to participate in that view class. A single object class may participate in many view classes. This allows view instances to intersect. The object class specifies how view instances interact by its rules for sharing and accessing instances variables. The object classes are expected, through the associated interfaces, to provide a unified abstraction for some structure or activity. It is the view builder’s responsibility to ensure that the view class is coherent. This responsibility for a single view class is essentially the same as that encountered in the conventional paradigm in which developers must ensure the consistency of class definitions that are intended to work together. The views paradigm provides added framework in addition to the conventional paradigm to simplify the manage-

OOPSLA ‘89 Proceedings

October 1-6, 1989

ment and coordination

of related structures.

A view instance is composed of a set object instances that form a concrete realization of the abstract structure defined by a view class. Each view instance is assigned a unique view instance identifier that implicitly includes the identity of its view class. Each object instance must be accessed by the view instance through the interface associated in the view class with the class of the object instance. The view instance identifier is used to label the interface activations in the object instances. Every interface activation visible to the view instance in every object instance that belongs to the view instance will use the view instance identifier as its activation identifier. Thus, in the views paradigm, an activation identifier is equivalent to a view instance identifier. An alternative definition of a view instance is that it is the set of objects within a system that contain activations labeled by a common view instance identifier. Strictly speaking, the view instance includes only the instance variables of the object instances that are visible to it. A view instance is created by registering its view instance identifier with the system support. Object instances become members of a view instance when they are created in the context of the view instance or by explicitly joining the view instance. An existing object instance joins a view instance though a view operation of the system support. The object instance’s object class must participate in the view instance’s view class for this to be possible. The details of how existing instance variables become part of an additional view instance depends on a level of object class definition not presented in this paper. A common occurrence is that there exists a pool of instance variables that is shared by all view instances with each view instance maintaining a small set of “private” instance variables of its own. Each of the extensions to the object oriented paradigm are important in providing the views behavior. Allowing an object class to define multiple interfaces is important because it allows the object class to define distinct sets of behaviors. Visibility and access control of instance variables gives a mechanism that allows views to interact through shared data but also keep private data that they can trust will not be altered by other views. It also provides a basis for deciding how to provide multiple copies of instance variables. Allowing multiple copies of instance variable sets is important because it allows an object instance to participate in multiple view instances of the same view class. There are many ways that an object instance can naturally belong to an instance of more than one view. As an example consider configuration and version control of a software system. The underlying structure class October 1-6, 1989

is the same for each version and corresponds to a view class. A particular version or configuration is an instance of that view class. An element of the system may be a member of many versions. This corresponds to an object instance participating in multiple view instances. By building a mechanism for managing the data of different views into the object-oriented formalism the developer of objects and views is freed from a layer of complexity in constructing an application.

0 b ject

Creation

and Destruction

An object in this approach must be created in the context of a view instance. This is so that the system support can create the object with the correct instance variables and use the correct interface in accessing methods. An object instance becomes a member of the view instance in which it is created. When an object instance is destroyed through a view instance the label for the view instance is removed from all relevant instance variables. Any instance variables which become unlabeled are removed. Any object instance which no longer participates in any view instances is deleted.

Polymorphism

and Object

Identity

One of the features of the approach to views that has been described is the central role of an object’s identity. An object class may participate in many view classes but it has a single object class name by which it may be referenced. More importantly, an object instance may participate in many view instances but it has a single unique object identifier. External agents cannot refer to the internal data organization of an object instance. The only way they can reference an object is through its object identifier with the specification of a view instance identifier. It is the responsibility of the system support to resolve the reference correctly. Method implementations within an object are also not allowed to access the organization of the object’s data. Method implementations simply use references to the data and the language support resolves the references. This behavior makes object instances, in a sense, polymorphic. An object instance has a single identity but may have different sets of behavior. The single identity of object instances is important in this approach because it supports the notion of a model. An object is a model of some entity. Views are ways of manipulating the entity from different perspectives but the identity of the object remains the same. Consider as an example an optimizing compiler that is able to move loop-invariant statements out of loops. The structure class being manipulated is the same before and after

OOPSLA ‘89 Proceedings

357

the transformation: the abstract syntax tree class. The statement that is moved is also the same before and after the transformation. Its ideniily remains the same even as its location in the program structure changes. A user may want to monitor the execution of the optimized program but use the original program as a reference point. This is handled naturally by the views mechanism by creating an abstract-syntax-tree view class. The syntax trees described above will be overlapping view instances of the abstract-syntax-tree view class. Execution can take place in the optimized view instance and display can take place in the unoptimized view instance because the statement that is moved retains its identity when it is moved.

The Use of Views It is not possible in the space provided to present a detailed example of the use of views. We will instead provide two summary examples that give the flavor of the use of views without detailed descriptions of object class definitions and object instances. As a first example consider a library of reusable subroutines. The developers who construct and maintain the library should be able to access and change the implementations of the subroutines. A user of the library should be able to browse the library and should be able to examine subroutine interfaces but should not be allowed to change an interface and should not be allowed to access the implementation. If a user decides to use a library subroutine then the software that references the subroutine will be added to a list of clients of the subroutine. This example maps naturally to the use of views. The developer view class will be defined so that it allows access with modification rights to subroutine implementations. The librarian librarian view class will be defined so that it cannot access the implementations and has read-only rights to a subroutine’s interface. The key object class where the two view classes intersect is the class that defines a subroutine declaration. The part of a subroutine declaration that is a reference to the implementation should not be visible from the library view class interface. The library view class will define an extra instance variable in its view to refer to the list of clients”. This variable will not be visible in the developer view. An illustration of the procedure-declaration object is given in Figure 6 As a second application of views consider rapid prototyping as an approach to requirements acquisition. Based upon feedback of the user’s experience with the prototype, the prototype can be modified to better match the user’s needs. The cycle continues until the 5This could also be defined as B reference to a single client with a new view instance occurring for each client

358

user is satisfied with the prototype and an accurate set of requirements baaed on the operation of the prototype is extracted. There are two separate areas in which views can be applied in this example. The first concerns information loss in the iterative enhancement of the pro totype. Each instance of the prototype is an instance of the prototype view class. For each preliminary prototype it is important to record what parts of the prototype satisfy user needs and what parts do not. This is naturally realized as a user-evaluation view. In the iteration from one prototype to the next those parts of the prototype that are members of the satisfied branch of the user evaluation view should propagate to the next prototype while those parts that are members of the dissatisfied branch should be eliminated. The parts of a prototype that are propagated to the next prototype are of course not copied. Their identities as object instances remain the same. They simply join the view instance of the new prototype. Once the prototyping cycle is complete then several information needs present themselves. A prototype is a good way to extract user requirements but it is not a good medium for recording the requirements. There must be a separate specification of requirements baaed on the prototype and the mapping from prototype features to specification clauses must be traceable. That is, one should be able to find what prototype feature a specification clause is based upon and alternately, find how a prototype feature is reflected in the specification. These needs are handled by three view classes: a prototype view class; a specification view class; and a prototypeto-specification view class. The classes that make up the prototype and specification view classes will also contain declarations for the prototype-to-specification mapping view class. It is easy to see that additional views may be used to trace the requirements through design and implementation. The important point of this example is that a mechanism is provided to prevent information loss. The developers of each view are not hampered by the burden of maintaining complex relationships however because each view maintains a simplified model of the data it manipulates.

Implementation A prototype implementation of the views paradigm (tentatively named CV++) as an extension of the C++ language [Stroustrup87] is currently under construction. The approach of the first prototype is that of a translator. It translates an object class of the views paradigm (an extended object class) into a family of object classes that are structured around instance variable visibility sets. References to instance variables are transformed into method calls on sub-objects. Object instances are organized so that there is a single master object instance

OOPSLA ‘89 Proceedings

October I-6, 1989

Class Procedzlre-Declaration:

Developer (D)

Interface

Method Map

Method Impl’s

proc-body: procname: signature: description: reflist:

Figure 6: Procedure-Declaration that is visible externally and a collection of slave object instances that are managed by the master. A concession that must be made in the prototype implementation is that each method invocation must explicitly state a view instance as part of the parameter list. After we gain experience with the prototype implementation we will do a more direct implementation of the views concept. The efficient implementation of the views extensions hinges on two factors: resolving the mapping of (method name, view instance) to method implementation; and organizing and resolving references to instance data. We believe that the mapping problem can be effectively solved based on our experience with an isomorphic capability in the RPDE environment [Harrison87]. Method resolution based on subdivisions in RPDE is equivalent to method resolution based view instance in the views approach. The problem of organizing the instance data and resolving references can be solved by adding an extra level of indirection into instance variable references. It is then the responsibility of the system support to load the indirection table with the correct pointer values for the view context of a method invocation. In parallel with the prototype language implementation we are beginning detailed design of several software development environment activities based on the paradigm. Our hope is that design and implementation of applications and the development of the language translator can act as cooperating activities in refining language of views.

Related

Work

Modifications to the object-oriented paradigm are not new. The Trellis/Owl language allows two interfaces to be specified for an object type. The private interface of a type exports methods to only its sub-types not to all clients. Hailpern and Ossher [Hailpern88] generalize this notion to allow any number of interfaces with emphasis on using interfaces as a security and capabilities mechanism. One of the first uses of views in a software environment was in the Pecan environment [Reiss84] which proOctober l-6, 1989

D(M) D(M), L(R) D(M), L(R) D(M), L(R) L(R) Object Class

Method Map

Interface

I

Librarian

(L)

vides multiple presentation views of the same underlying data. The Andrew Toolkit from Carnegie-Mellon University also provides multiple presentation views but based on an underlying object-oriented representation. Each view into a data object is accomplished by attaching a view object to the data object. The work by Garlan at Carnegie-Mellon University [Garlan87] and the follow-up work of the Gandalf group on the Janus language [Habermann88] allows tools to be defined independently and later merged. The Gandalf approach does not allow an object instance to participate in multiple view instances of the same class (it participates in exactly one view instance of each class). Garlan’s work also shows up in the MELD [Kaiser 871 language which provides an alternative means of encapsulation and abstraction with the intention of reusing tool specifications. MELD provides a construct called a feature as a unit of modularity larger than a class that bundles object classes together into a set. Each object class in a feature presents an interface and the corresponding instance variables needed by the methods comprising the interface. Features may be merged to provide combined behavior in a new object class. The merge operation does not preserve the distinct abstractions of features. The new class instead becomes a union of their behavior. Parameterized method implementations, subdivisions, roles, and tools of Harrison [Harrison871 provide a way of effectively reusing code and building multiple abstractions on top of the conventional object-oriented paradigm (discussed below). Multiple abstractions are provided by allowing multiple method implementations to be associated with a particular method, multiple methods with a particular role, and associating roles and object classes with a particular tool. This scheme does not currently provide a mechanism to associate instance variables with methods or method implementations and hence does not allow an object instance to have multiple copies of instance variables. The work of the Orion group at MCC on versions of objects [Chow861 and versions of schema [Kim881 bears some relation to this work. The main similarity of the work is that they maintain a notion of object name that

OOPSLA ‘89 Proceedings

359

represents a collection of object instances. In their system an object name represents an entity which may have several versions and may need to be further qualified to be resolved to a unique object instance. A reference to the object actually refers to a table that is used to resolve the reference based on additional information. Orion provides explicit system support for resolving object names to actual object instances. The previous system that provided capabilities most like those presented here is the PIE system from Xerox PARC [GoldsteinN]. It provided the ability to associate multiple perspectives with an object instance. The instance variables of an object are partitioned by perspective and each perspective provides its own interface. Attributes may not be shared between perspectives but they provide the ability to create attached procedures (action routines) to objects which maintain consistency between perspectives of an object. These procedures reside in meta-nodes which contain the procedures along with other metainformation about the object. All values of instance variables in PIE are rela tive to a context. A context is structured as a sequence of layers. References to a variable within a context is resolved by looking up the variable layer by layer, starting with the most recently created. This allows there to be multiple versions of instance variables and seems to allow a value to be shared between contexts. The use of contexts seems to be used to provide the ability to create alternative designs in the system and as a history (or versioning) mechanism. Perspectives are used to impose alternate organizations on design structures and are also explored as a means for providing multiple inheritance baaed polymorphic objects rather than multiple inheritance in classes. All of these approaches provide support of some kind or another for providing multiple abstractions of a class by grouping methods together into interfaces. Harrison’s approach extends the selection criteria of the conventional object-oriented paradigm with subdivisions. The Orion work extends the selection criteria for object instances and the PIE work extends the selection criteria for both methods and instance variables. This paper presents a new selection criteria that extends the conventional object-oriented paradigm to use object class, view class, and view instance in determining the methods and instance variables that are visible.

whole. The context in which we approach views is in the construction of object-based software development and maintenance environments. Such environments must support a wide range of activities using divergent structure representations but must also maintain the natural relationships between separate activities and their structures. The views approach in this context serves two purposes. From the user’s perspective, views allow slices of the software system to be observed and manipulated. From the environment developer’s perspective, views technology facilitates the development of the tools (environment fragments) that the user uses to manipulate slices. The developer is aided because the technology performs view management automatically baaed on declarations provided in the development of the environment. We describe language support for view construction as a sequence of three extensions to the conventional object-oriented paradigm: (1) defining multiple interfaces in object classes; (2) controlling visibility of instance variables; and (3) allowing multiple copies of an instance variable to occur within an object instance. These extensions to the paradigm allow object classes and instances of those classes to be naturally polymorphic, supporting different behaviors through multiple interfaces. They also allow an object instance to encapsulate, under a single identity, the intersection of multiple view instances even if the structures have the same view class. The views approach refines control of instance variables within object instances but at the same time provides the mechanism for creating intersecting global abstractions that cut across many object classes.

References [Chow861

Chow, Hong-Tai, Won Kim, A Unifving Framework for Version Control in a CAD Environment, Proc. Intl. Conference on Very Large Data Bases, August 1986, Kyoto Japan.

[Garlan87]

Garlan, David, Views for Tools in Integrated Environments, Ph.D. Thesis, Carnegie-Mellon University, 1987.

[Goldstein811 Conclusion Views are a way to manage large, complex data structures by presenting simplifying abstractions. They are important because it is easier to understand individual pieces of a complex system and how the pieces are related than it is to understand the system directly as a 360

Goldstein, Ira, Daniel Bobrow, “An Experimental Description-Based Programming Environment: Four Reports,,, Technical Report CSL-81-3, Xerox Palo Alto Research Center, March 1981.

[Habermann88] Habermann, A. N., Charles Krueger, Benjamin

OOPSLA ‘89 Proceedings

October l-6, 1989

Pierce, Barbara Staudt, John Wenn, “Programming with Views,” Technical Report CMU-CS-87-177, CarnegieMellon University, January 1988. [Hailpern88]

Hailpern, Brent, tending Objects Interfaces,‘, work Watson Research

[Harrison871

Harrison, vironment ing Tool November

[Harrison891

Harrison, William H, John Peter F. Sweeney, “Good News: Experience building Development Environment Object-Oriented Paradigm,” ‘89.

[Kaiser 871

Gail Kaiser and David Garlan. “Melding Data Flow and Object-Oriented Programming,” In Ihe Proceedings of OOPSLA ‘87, Object-Oriented Systems, Languages, and Applications,, Orlando, FL, October, 1987, pp. 254267. Proceedings published as SIGPLAN Notices, 22(12), December, 1987.

[Kim881

Kim, Won, Hong-Tai Chow, Versions of Schema for Object-Oriented Databases, Proc. Intl. Conference on Very Large Data Bases, 1988.

[Reiss84]

Reiss, Steven P., “A Graphical Program Development with PECAN Program Development Systems,” Proceedings of the ACM SIGSOFT/SIGPLAN Software Engineering Symposium on Practical Software Development Environments (Pittsburgh), April, 1984, pp. 30-41.

[Stroustrup87]

Stroustrup, Bjarne, The C-/--t Programming Language, Addison-Wesley, Reading Massachusetts, 1987.

[Trellis 861

Craig Schaffert, Topher Cooper, Bruce Bullis, Mike Kilian and Carrie Wilpolt. “An Introduction to Trellis/Owl,” ACM Conference on Object-Oriented Systems, Languages, and Applications,, Portland, OR, September, 1986, pp. 916 Proceedings published as SIGPLA N Notices, 21(11), November, 1986.

October l-6, 1989

Harold Ossher, “Exto Provide Multiple in progress, IBM T.J. Center.

William, “The RPDE3 En- A Framework for IntegratFragments,” Soflware, 4(6), 1987, pp. 46-57. J. Shilling, News, Bad a Software Using the OOPSLA

OOPSLA‘89 Proceedings

361