12th European Conference on Object-Oriented Programming
Brussels, Belgium, July 20 - 24, 1998


Poster sessions are an alternative forum for viewing results of object-oriented work, with the opportunity for one-on-one interaction with presenters. Poster themes cover the breadth of object-oriented technology - from theory to experiences in applications. They provide an easy and informal means for presenting ongoing research to the ECOOP '98 audience. This may be especially useful for new ideas that have not yet been developed to the point of a regular paper.

Posters will be on display during the entire conference. A special poster session is scheduled on Tuesday evening at the Belgian Beer Degustation.

Patrick Steyaert
ECOOP'98 Poster Chair
Programming Technology Lab
Computer Science Department
Vrije Universiteit Brussel
Pleinlaan 2 B-1050 Brussels, Belgium
Tel: +32 (0)2 629 34 92
Fax: +32 (0)2 629 35 25
E-mail: prsteyae@vub.ac.be

Posters at a Glance

P1 The AspectIX ORB Architecture
P2 Formalization of Component Object Model (COM) - The COMEL Language
P3 Oberon-D = Object-Oriented System + Object-Oriented Database
P4 OctoGuide - a graphical aid for navigating among Octopus/UML artifacts
P5 Design of a spatio-temporal information system for marine coastal environments using Object Technology
P6 An Exchange Model for Reengineering Tools
P7 The Extended Module System of LOOM: Inheritability need not compromise abstraction
P8 Run-Time Reusability in Object-Oriented Schematic Capture
P9 Replication as an Aspect

P1: The AspectIX ORB Architecture



The CORBA architecture defines the semantics of the interaction of distributed objects. These semantics are fixed and not extendable. CORBA services can extend the basic functionality of an ORB, but they are based on those fixed semantics.

AspectIX is an open and more flexible architecture than CORBA, but an AspectIX implementation can also host CORBA-compliant applications. AspectIX adopts a fragmented object model, which means that each client owns a local part of the distributed object and that these local parts (called fragments) can interact with each other. A local fragment can be intelligent and carry a part of the distributed object's functionality, or it can act as a dumb stub as in the CORBA-compliant AspectIX profile.

A client can configure several nonfunctional aspects of the interaction semantics using a generic configuration interface to each distributed object. A local fragment implementation may be transparently replaced by another one if it cannot fulfill the requirements of a new configuration.

The poster presents the basic architecture and will give examples how to use the configuration interface for problems in wide-area systems (replication, consistency), mobile agents (mobility), and process control systems (real-time constraints, fault tolerance).

P2: Formalization of Component Object Model (COM) - The COMEL Language


  • Rosziati Ibrahim, Queensland University of Technology, Australia (ibrahim@fit.qut.edu.au)
  • Clemens Szyperski, Queensland University of Technology, Australia (c.szyperski@qut.edu.au)
  • Abstract

    Microsoft's OLE (Object Linking and Embedding) provides an application integration framework for Microsoft Windows. OLE rests on the Component Object Model (COM), which specifies a programming language independent binary standard for object invocations, plus a number of interfaces for foundational services.

    COM is all about interoperability of independently deployed components and is used to develop component-based software. COM is language independent. The component software can be developed by independent vendors. Extensions to component software can also be developed and integrated by the client. Currently, COM offers a set of informal rules in order to form a standard binary level of building interoperable software. However, COM does not have a formal specification.

    We propose an approach to formalize COM. A model language is introduced in order to formalize COM. Since COM itself is language independent, the language introduced here just takes an examplary role. This example language for COM is called COMEL (Component Object Model Extended Language, pronounced cho-mell). We formalized some of the important COM's rules. The approach we use is by introducing the abstract syntax of COMEL language that addresses COM's informal rules like object composition, interface lookup, creating new instance of object and method passing. Then the type system, the operational semantics and the subject reduction theorem of COMEL language are formed. Work is now still progressing on the operational semantics of COMEL and the soundness proof for the COMEL type system.



    P3: Oberon-D = Object-Oriented System + Object-Oriented Database



    Object-orientation was invented twice: once by the programming languages people and once by the database people. The two camps are usually separated, in spite of the many commonalities in their goals and approaches.

    The project Oberon-D aims at unifying the two worlds. It demonstrates the seamless integration of database functionality into an object-oriented development environment, in which, the survival of objects is for free. Persistence, for example, is obtained by a persistent heap on the disk. Persistent objects are on this heap, while transient objects are in the transient memory. Transient and persistent objects can access each other mutually. Accessing a persistent object leads to loading the object into the transient heap. If it is not accessed from transient objects any more, it will be written back to the persistent heap. A transient object becomes persistent as soon as it can be reached from a persistent root. If not defined otherwise, all objects directly or indirectly referenced by a persistent root are automatically persistent as well. Persistent objects which are not referenced by other persistent objects are reclaimed by a Stop & Copy garbage collector. This algorithm uses two heaps (files) and copies all accessible objects from the full heap fromHeap to the empty heap toHeap.

    The idea of this work is to offer the impression of an indefinitely large dynamic store on which all objects live. The programmer does not have to distinguish between 'internal' and 'external' objects. All objects can be referenced and sent messages as if they were in main memory. The underlying language does not have to be extended.

    Other database features, such as schema evolution or recovery are embedded in this persistent environment. Schema evolution, for example, is done during the persistent garbage collection run. In this phase it is checked, if the type definition of any object has been modified since the last garbage collection run. If this is the case the object is read from the fromHeap by using the old type definition and is written to the toHeap by using the new type definition.

    Furthermore, an Oberon binding for ODL/OQL is implemented as part of this work. ODL is a specification language for defining interfaces to object types that conform to the Object Model of the Object Database Management Group. OQL is an object query language supporting this model.

    A proof-of-concept implementation, named Oberon-D, has been done in the Oberon system, which offers powerful mechanisms for extending software in an object-oriented way. However, any other object-oriented operating system, which offers garbage collection and exception handling, could be used instead of Oberon.

    The work includes some novel aspects, e.g., the implementation of user-defined mappers, the integration of garbage collection and schema evolution and the translation of OQL code into Oberon code.



    P4: OctoGuide - a graphical aid for navigating among Octopus/UML artifacts



    Novice users of object-oriented methods might encounter difficulties in locating the artifacts (diagrams, text tables, etc.) defined by the respective method and placing them into context. Our work experience is similar. CASE tools can be helpful in this area but they can be difficult to learn and expensive, too.

    During the development of Octopus/UML, a new, enhanced version of the Octopus method, we kept the above issues in mind and also the needs of teaching.This led to OctoGuide, an aid that is

    OctoGuide has as its root Microsoft PowerPoint - the application used in Octopus education previously - but utilizes OLE (Object Linking and Embedding) and hyperlink technology. In its present form OctoGuide helps to become familiar with the artifact set of Octopus/UML visually and discover relationships. It can be used to gain hands-on experience with Octopus/UML by elaborating on small-scale case studies.

    In the future it may be used in the classroom, as well, to introduce case studies in a more flexible way and also to give guidance in solving exercises.With little effort one can have the same case studies, exercises, solutions converted to HTML and made readily available via browsers.

    P5: Design of a spatio-temporal information system for marine coastal environments using Object Technology



    This project addresses the development of a MARine COASTal Information system (MARCOAST) as a tool for the sustainable management of coastal resources. Such a system is necessary in order to monitor the rapid changes in the coastal environment in response to natural and anthropogenic influences. The MARCOAST will be designed using an Object Oriented Analysis and Design (OOAD) methodology and a prototype system implemented in an Object Oriented language, in order to ensure that the system is flexible and easily extensible.

    The MARCOAST is to be implemented as a 3-tier distributed client-server architecture. The three tiers are designed using object technology, design patterns and Unified Modelling Language. The work presented here is an attempt to take the object concepts out of the textbooks and actually use them in designing and developing an application software, and thus harness the vast potential of the object technology and apply it to the real world.

    The work presented is sponsored by the Norwegian Research Council.

    P6: An Exchange Model for Reengineering Tools



    Tools support is recognised as a key issue in the reengineering of large scale object-oriented systems. However, due to the heterogeneity in today’s object-oriented programming languages, it is hard to reuse reengineering tools across legacy systems. This paper proposes a language independent exchange model, so that tools may perform their tasks independent of the underlying programming language. Beside supporting reusability between tools, we expect that this exchange model will enhance the interoperability between tools for metrics, visualization, reorganisation and other reengineering activities.

    P7: The Extended Module System of LOOM: Inheritability need not compromise abstraction



    A well-designed module system can provide a very useful means of code organization and abstraction in an object-oriented language. Modules offer namespace management and separate compilation, greatly simplifying the development of larger software projects. It has been argued that classes provide for these needs in object-oriented languages, but we hold that it is useful to be able to group related classes together with a static module constuct offering its own namespace control and abstraction barriers. A module system for the language LOOM was first designed and implemented by Petersen. It provided separation of interface from implementation, partial revelations of exported object types, and strong abstraction barriers against unexpected access to unexported methods, but did not allow easy extension of classes packaged in modules. Here we describe LOOM and its module system, and outline modifications intended to increase flexibility in designing modular programs. The main addition is that of a construct to "open" a module rather than "import" it, allowing sufficient access to permit inheritance.

    P8: Run-Time Reusability in Object-Oriented Schematic Capture



    A graphical user interface can be used to assist in the design and simulation of electronic circuits. This kind of software provides an intuitive tool that allows a circuit designer to place and connect together the symbolic representations of electronic components. The resulting circuit schematic may then be captured and converted to a suitable source code form for input into simulation software. This poster describes the essential features of an object-oriented schematic capture system for VHDL-AMS (VHSIC Hardware Design Language - Analogue and Mixed Signal). This recent extension to VHDL for modelling mixed mode (analogue and digital) circuits presents a number of opportunities and challenges to a schematic capture interface that must shield the circuit designer from the complexity of VHDL-AMS syntax while allowing the full power of the language to be used.

    Traditional simulation languages allow new components to be described as aggregations of smaller components. This structural approach to component creation can lead to complex circuit representations that simulate slowly and/or inaccurately. An important aspect of VHDL-AMS is that it allows new component representations to be described at a behavioural level, so their electrical characteristics can be described directly in the language rather than indirectly through aggregation. The schematic capture interface uses an object-oriented design based on a reflective architecture that enables the user to create new component types and integrate them into circuit schematics at run time.

    An equally important feature of VHDL-AMS is that its syntax can be very complex when connecting digital and analogue components together. The same digital component needs different models for different contexts. For example, a gate with only digital input signals requires a different code model than the same type of gate with both analogue and digital signals. For the circuit designer, this means that the correct model must be selected from several possible alternatives, even though there is in fact only one type of component being simulated. The schematic capture interface resolves this problem by giving digital component objects the ability to interrogate their external connections to find out whether they are joined to terminal nodes (analogue objects) or signal nodes (digital objects). From this information, each component is able to invoke the appropriate model automatically from its code generating methods.

    P9: Replication as an Aspect


    ECOOP'98 Home Page | Conference at a Glance | organization
    Technical Programme | Tutorials | Workshops | Panels | Exhibits | Demonstrations | Posters
    Social Programme | Partner's Programme | Accommodation | Useful to Know | Registration

    Last modified on July 17, 1998. Maintained by the ECOOP'98 information team.