Title

Refactoring E-Cell 3 Model-related Frontend Modules

Author

Moriyoshi Koizumi <mozo@sfc.keio.ac.jp>

Date

October 10, 2007

Status

Proposed

Abstract

Separate development efforts of the E-Cell 3 core framework (pyecell) and bundled E-Cell 3 empowered applications (session monitor and model editor) resulted in a number of reinvented wheels, which eventually made up the code base almost unmaintainable. In an attempt to refactor the whole source code, I extracted the fundamental part of the modelling API to create an unified interface that can be used from various portions of these applications that include EML serialization or MVC backends, etc.

Description

Introduction

E-Cell 3 MM is entirely written in Python. This is because the primary purpose for creation of the framework is to reduce maintenance costs and we need to keep it in mind. A significantly large model is not much favored by this decision, mainly due to Python's inefficiency in memory consumption, but it should work for 99% of cases.

The module will be placed as part of pyecell package.

The module consists of three parts; an object metadata repository (formally DMInfo in the model editor), modelling objects and an object graph container (formally handled by ModelStore.) The metadata repository loads the registered dynamic modules (DMs) and stores the information such as the type of each class, the names and attributes of properties that belong to it. Modelling objects are supposed to form a model graph whose nodes are represented by DMObject instances, and edges are described by Relationship instances. Modelling objects are free from the naming system (FullIDs and FullPNs) and it is instead handled by the object graph container, which holds associations between identifiers and entities.

Design

Aside from above, a simple event delivery system is implemented in DMObject on the basis of GoF's Observer pattern. Although this is primarily used to maintain coherency either between multiple graph objects or between a graph object and an Entity object in a simulation instance, this allows the user (of the module) to keep consistent the states of the model and view designed after MVC pattern without modifying the bevavior of the framework by extending its classes.

Life of a modelling object is terminated either explicitly by dispose() method or implicitly by the destructor. The former method is useful when you want to keep the reference to the object as it does not discard the object itself.

Some containers like ModelStore make use of weak references to cope with circular references that are almost inevitable in an application that handles graph-like structures.

Rationale

The former implementation don't take advantage of object-oriented nature of the language; many of entity objects are represented as native list objects, every of which consists of a regular, semantic set of attributes in a particular order. Modelling objects are introduced mainly for the replacements of those.

The idea of event system came out of unification of tiny actions scattered all over the code that are triggered on the same event of an entity.

APIs of the metadata repository is redesigned in great part so that it can fit to various purposes.

Proposed Implementation

See the UML class diagram.