Univers@lis Model Repository Tool

Main Page Documentation  Overview  Model Interfaces Reflective Interface Tailored Interface Generation rules  Textual Notations XMI and XMI+ JMI, PMI, CTF  Repository Facility Structure Repository Session Program Sample  Tools Universalis Viewer Import/Export Facility Conversion Tools  Publications Samples  Metamodels MOF UML 1.3  Models Notation Guide A Bank Model  Model Instances Bank instances Projects (restricted access)  Groupe Méta  Pilote

Universalis Repository Facility Structure One of the goals of the repository is to achieve object persistence for all model components. A main design decision in Universalis is that registration for a model component is done explicitly. This makes it possible to use of human-readable object identifiers. The logical name space for identifiers is a hierarchical one that behaves as an ordinary file system name space. A drawback of having explicit registration could be that a user would have to find a name for each fine-grained model element (such as a constraint, an attribute, a tagged value). To avoid this, Universalis manages a double-layered hierarchical name space. The first level is provided by the context level (similar to the directory structure in a file system). The second one comes from the distinction between root-objects and sub-objects. Root-objects are those that are explicitely registered. Sub-objects, in the other hand, are not registered explicitely. They become registered at the moment they are added as a child of a registered parent object. Object identifiers (OIDs) for root-objects are made of a contextual part (directory part) and a local identifier part (basename part). A sub-object is attainable as any other object by using its unique OID. This OID is computed automatically on the basis of its root-object, and on the path required to reach it (a list of 'roleName-localIdentifier' items). Repository Session The repository interface is defined to encapsulate all interactions with the repository. This made the repository storage design independent of any implementation choices. The current repository implementation was done on top of the file system (Unix or MS-Windows). Other storage strategies can of course be achieved (that could use relational or OO data bases for instances). The current implementation uses the CTF format as the storage format (a file contains a root object and all of its sub-objects). This design leads to significant time-consume optimizations for loading and storing objects. The Repository Session API in Java The Repository Session API in Python Program Sample This short example shows what declarations are needed for importing the repository interfaces and how to use the tailored interfaces for inspecting a model. See the Java version See the Python version

Last modification July 29 1999
mariano.belaunde@rd.francetelecom.fr