Fedade was written to populate a Rochade Repository Information Model (RIM) for the POSC Epicentre "meta" data model (ie the model that describes the data model). In this regard, the RIM can be considered a "meta-meta" model.
POSC provides a meta-model description in the express language (as well as providing the Epicentre model itself in express). This model was used to construct the RIM by manual translation and entry into the Rochade repository. The meta-model itself is relatively small, consisting of around seventy entities mostly related to data type description, making the manual approach viable.
The full Epicentre model contains around 1500 entities making a manual approach inappropriate.
Given the existence of an express description of Epicentre, it made sense to build a scanner that would convert the model from express into a form that can be loaded into Rochade.
Model loading with Rochade is normally performed using R&O's procedure language, by generating a long "program" to inject the entries.
We considered several conversion alternatives:
After a brief code review, we found that:
We elected to make use of the fedex parser.
Fedex is implemented in C with an object oriented style. It parses express language input to produce a complex crosslinked data structure in memory. As distributed fedex does nothing more, so given correct express input fedex produces no output.
The fedex parser delivered with the POSC sample implementation is based on an earlier version of the code than that available from NIST. We decided to use the latest code so that we'd be using the most bug-free software available. We would also gain clear understanding of the extensions introduced by POSC and be able to confirm that the express source distributed by POSC was consistent with current standards.
The POSC extensions are, in fact, minimal. They amount to the addition of the "extended data types" used to support values like "quantity" and "location", plus the code necessary to encode the type parameters in the data structures generated by fedex. We were able to merge the POSC changes into the current code with little effort.
Fedade is implemented with calls to the fedex library. The initial program sequence conforms closely to the express tools distributed by NIST and fedex itself. The steps are:
The current implementation is capable of performing three operations:
Rochade provides named items, links (bidirectional connections between named items), and attributes of items, which may be text attributes or value attributes. Text attributes may be arbitrarily long. Value attributes may be associated with constraints. These features allow a fairly complete description of express based schemas. One awkward problem Rochade imposes is that names are limit to 32 characters.
To overcome this, we implemented a simple aliasing mechanism. Initially the aliases were constructed by incrementing a counter for each entity and each attribute in the entity. This established appropriate names for Rochade but made the generated model difficult to navigate because Rochade typically presents only the item name and not its definition. We modified the alias generation to include the generated surrogate prefixed by as much of the Epicentre name as would fit.
Ultimately it may be preferable to adopt the abbreviation strategy used in the relational projection which must also meet a 32 character limit for Oracle.
This feature required a further small extension to one of the fedex data structures. We added an extra element,
char *alias;
to the
Symbol structure defined in symbol.h.
Descriptive text can be included in the Rochade "DESCRIPTION" item from an external source. The current implementation uses text released by POSC and converted from a tab-separated format to an indexed message format (using pre-existing Mobil software). The descriptions are referenced as "NDT.type_name", "ENT.entity_name" and "ATT.entity_name.attribute_name".
The indexed format is needed to make text lookups efficient. Fedade accesses the text items in effectively random order. The conversion from the tab-separated format is done using a perl script so merging text from multiple sources is relatively easy, given name correspondence.
In the current RIM, the full type structure is modeled,
including entities
DAE_BASE_TYPE,
DAE_SIMPLE_TYPE,
DAE_EPICENTRE_DATA_TYPE,
DAE_AGGREGATE_TYPE,
DAE_SET_TYPE
and so on.
This tends to make working with the RIM awkward because a navigation
sequence must be followed to determine the exact type of an item.
It may be better to collapse the whole type model into
a single text attribute associated with
DAE_EXPLICIT_ATTRIBUTE
and
DAE_INVERSE_ATTRIBUTE.
Processing the complete express Epicentre schema generates approximately 8MB of Rochade procedure code in seven files. On an HP9000/735 this takes under 15 seconds. Using a 486DX2-66 Windows PC to load the model to a Rochade server on the HP9000/735 takes about an hour, substantially limited by the PC's performance.
Loading the model like this is an infrequent operation so these performance figures are deemed acceptable. If it becomes necessary to perform the load more frequently, it should be possible to substantially improve the load time by making use of a Pentium based PC or by using the Unix Motif client which is expected to be released shortly.
Processing and generating HTML takes under 2 minutes on the HP. Most of the additional time is spent in creating the large number of files (two per entity) present in the HTML tree. The resulting WWW application is much faster than the previous FrameMaker version (albeit with no descriptive text).