Software Requirements

Broadly speaking, we use the VPDMf in two ways. 

  1. To build systems.

  2. To access and encapsulate data.

1. Building systems with forward- and reverse- engineering.

The first domain of usage may be summarized within Figure 1, a use case diagram from the unified modeling language,. or 'UML'. This is really a series of forward- & reverse-engineering  use cases where the system may be used to build systems from models or models from systems. 

Figure 1: Use cases from the reverse- and forward engineering sections of the database.

This set of principles can be summed up in the following descriptions of use cases.

  1. The system can be used to extract the schema from a database instance to generate a 'Data Model Design Document' (such as a UML model file) which acts as schema description.

  2. This Data Model Design Document may manipulated and altered.

  3. This Data Model Design Document may be used by the system to automatically generate a new database instance.

  4. The 'View-Design-Document' is a simple description of how different views are constructed from the DB-Design-Document. This may be used in conjunction with the DB-Design-Document to generate 'Encapsulated-Schema' (such as a DTD or XMLSchema document). When combined with information from the instance of the database itself, an Encapsulated-Schema may be generated (such as an XML document).

  5. The  'View Graph Design-Document' is a simple description of how the data organized according to the Data Model Design Document and View-Design-Document should appear within a user interface consisting of a Create/Read/Update/Delete interface for individual views and a method for navigating between views.

Input systems (reverse-engineering) 

We intend to automate the process of constructing data models from the following examples of real-world systems. These are the possible input data  structures.

  • Rational Rose UML models (completed)

    This is an important step since Rose can itself reverse-engineer the organizational structure of a large number of different applications including object-oriented applications and systems (using CORBA, Java, Visual C++ projects, ANSI C++, 'simple' C++, COM or Visual Basic) and databases (Oracle, SQLServer, DB2, Objectivity). Thus we can build VPDM-enabled systems from any system that Rose can reverse-engineer.

  • XMI models

  • RDFS schema

    For interaction with the Protege Knowledge Base system.

  • XMLSchema/DTD files

  • Level 2 ODBC-enabled systems

    Databases export their schema under the level 2 ODBC  'catalog' functions (see Microsoft's documentation on SQLColumns, SQLForeignKeys, SQLPrimaryKeys, and SQLTables). We intend to use this to be able to reverse-engineer any ODBC and JDBC database.

  • MS-Access 97 'documenter files' (tested in previous version, now deprecated)

Figure 2: An example of the design of a reverse engineering paradigm in the VPDMf.

Output systems (forward-engineering) 

The VPDM framework is intended to generate systems from schema. The fact that different systems generated from the same schema has the same design simplifies development work enormously.

We want to be able to automatically generate database schema in one step. The systems we intend to be able to use his for are.

  • Informix *** (this is a priority)

  • Oracle

  • MySQL 

  • PostgreSQL

  • Objectivity

Additionally we will be able to generate user interfaces and data encapsulation methods that themselves use the VPDMf directly. We discuss these issues in the next section. 

The following diagram illustrates the process of generating a database system within a linked user interface from a single model file with descriptions of views and interface parameters. The Base Data Model file is parsed and manipulated by VPDMf to generate an installation script for the database (which then may be executed from within the VPDMf). The VPDMf representation forms the basis for the definition of views (which may be used as XML documents), which then forms the basis for the necessary files underlying a simple user interface. 

Figure 3: An example of the design of a forward engineering paradigm in the VPDMf.

2. Data access methods.

Figure 4: Use case diagram for VPDMf-enabled user interface.  

A preliminary user interface was built and tested using ASP pages. We present this as an illustration (which we will return to throughout this documentation). 

<=== Click the image for a full screen-shot.

Figure 3: A sample screenshot from an early implementation of a VPDMf-enabled system.

This image shows a navigation tree in  the left hand pane (as a represention of the vGraph) and the data attributes comprising a specific view (in this case, showing the text atoms or 'fragments' that  form a document in the NeuroScholar system).

We break this down into two categories:

  1. Simple view Create-Read-Update-Delete interface

  2. View Navigator

Data encapsulation methods

We would like to be able to package the within a view in an encapsulated form. This is essential for the to share data with other systems (see next section).

We anticipate using a number of different methods to accomplish this.

  1. XML

  2. RDF and RDF-Schema

  3. NetCDF

  4. PDL (???)

Data mediation and translation

If we can pass data between systems using the VPDM framework, then we would also like to be able to use the same framework to mesh one system's data model onto another. 

We anticipate using the XSL paradigm to accomplish this mapping. 


Having described the domain space that this application is used for we then enter the details of how the system is actually put together. This is described in the next section >>>