Temporality

Introduction

Temporality is a proposed open source component in the Eclipse Modeling Framework Technology (EMFT) project whose goal is to add automatic version of model instances.

This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process document) and is written to declare its intent and scope. This proposal is written to solicit additional participation and input from the Eclipse community. You are invited to comment on and/or join the component. Please send all feedback to the eclipse.technology.emft newsgroup (please prefix the subject with [temporality]).

Background

Things change. When something changes one of the great benefits of computerized record keeping systems is that they allow us to easily add new records and update past records. There are many real world examples where there is a need to keep track of the state of a piece of information over time; payroll systems, contracts, bank accounts etc.

Many software patterns have been proposed to address questions of the form: “what was the salary of Jean-Claude on Jan 12 1995” and “what did we think Jean-Claude’s salary was on June 22 1995 when we issued him a paycheque”. These patterns are sometimes referred to as Temporal Object or Temporal Attribute. See Martin Fowler’s Patterns for things that change with time article for a discussion about these patterns.

EMF provides a class called ChangeRecorder that is used to record changes done to modeled instances (EObjects). The ChangeRecorder is primarily used to implement the undo/redo mechanism in an instance editor; however the ChangeRecorder does not answer questions about the state of an object at an arbitrary date/time.

We propose modeling a Temporal base class which would be responsible of keeping track of the state of any given modeled object. Suppose you had a model consisting of a Vehicle base class.

• Vehicle
  • brand
  • numberOfDoors

and a Car subclass of Vehicle:

• Car -> Vehicle
  • colour
  • wheels

To add version tracking to the car you simply subclass from Temporal.

• Car -> Vehicle, Temporal

Scope

Functionality initially contributed:

1. Retrieving attributes and references in the past/present/future.
2. Modifying attributes and references in the past/present/future.
3. Versioning of lists; retrieving, adding, removing, clearing in the past/present/future.
4. Propagation of modifications made to attributes and references made in the past.
5. Temporalization of bidirectional associations.
6. Temporality hooked into EMF using an EStore.

Remaining functionality:

1. Validation of model.
2. Improve versioning of lists.
3. Implementation of temporal Map.
4. Bidirectional temporal reference propagation.
5. Bidirectional temporal list propagation.
6. Bi-Temporality.
7. Explore alternative means of hooking into EMF.
8. Find a better way to get at the TemporalDateFactory (currently using spring)

Note that the scope can be further augmented as warranted by community interest.

Description

The functionality initially contributed will consist of an .ecore model containing the Temporal EClass. This model can be loaded using “Load Resource” into an existing model to add temporality to existing modeled classes. The initial version of this component will use an EStore to hook itself into EMF. In future versions we may want to explore different hooks into EMF. This is the less intrusive approach it requires no modification to the genmodel templates. The initial contribution includes supporting .java classes and an EStore implementation to hook in the temporal behaviour. See Delegating EStore Design Document andTemporality Design Document for more details.

We also have testcasses covering most areas of the temporal functionality. The current test coverage is as follows:

1. Test retrieving attributes and references in the past/present/future
2. Test modifying attributes and references in the past/present/future
3. Test list versioning; retrieving, adding, removing, clearing in the past/present/future
4. Test propagation of attribute and reference modification made in the past.
5. Test propagation of attribute and reference modification to future versions
6. Test propagation done on a specific version (not through the continuity).
7. Test temporalization of bidirectional associations.

Remaining functionality:

1. Validation of model. Temporal should not be in bi-directional relationship with non-Temporal types.
2. Improve versioning of lists. A more efficient mechanism is needed. The current implementation simply copies the entire list when a list version is required.
3. Implementation of temporal Map. Maybe we can leverage the work done with EList since the Map is backed by an EList.
4. Bidirectional temporal reference propagation.
5. Bidirectional temporal list propagation.
6. Test mixing different granularities of time.
7. Bi-Temporality. As mentioned in Martin Fowler’s articles there are two types of Temporality: Regular and Bi-Temporality. The current implementation focuses on regular temporality captured in a base class called Temporal. Our approach lends itselft nicely to the addition of a BiTemporal base class to capture the bi-temporality functionality. We think this would be a very interesting addition to the Temporality component.
8. Find a better way to get at the TemporalDateFactory (currently using spring). Maybe there's a way to hook into some EMF registry so that the factory could be configured independently for every modeled class.

Relationship with other Eclipse-based Projects

Temporality builds upon the functionality provided by the EMF project itself. The Temporality design is fairly straightforward and non intrusive. It is mostly implemented using modeled EClasses and does not require any changes to JET templates used by the GenModel code generator. It also does not require any changes to the EMF source code. The Temporality component is pluged into EMF objects in using an EStore. The only code written outside the modeled EClasses is for support classes and a custom EStore processor that intercepts the eGet and eSet method calls.

The Temporality component is fundamentally generic in nature. As such this component can be leverage by any Ecore based project where there is a need to keep track of the state of modeled instances over time.

Organization

Initial committers

• Jean-Claude Cote

Code contributions

• Eric Ladouceur
• Simon McDuff

Interested parties

• Ed Merks, IBM

Interested parties are welcome to add themselves to the list above as interested parties or to suggest changes to this document.

Tentative Plan

• 2007-12: Initial version to EMF team for study and feedback
• 2008-01: First public version for community study