12th European Conference on Object-Oriented Programming
Brussels, Belgium, July 20 - 24, 1998
|
|
12th European Conference on Object-Oriented Programming |
Posters |
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 |
| 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 |
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).
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.
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.
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
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.
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.
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.