Revision 1 as of 2005-03-22 05:43:34
missing edit-log entry for this revision
converted to 1.6 markup
|No differences found!|
This page will conain a nicely formatted, consolidated requirements specification.
The goal of this effort is to create a database mapping tool. There shall be a plugin mechanism to easily integrate implementation for certain problem domains. It is not intended to extend functionality to create UML diagrams, as this is already covered by wide-spread, freely available tools.
The tool shall be published under the Apache Software License. Therefore all components used must be available with a license that is deemed compatible with the Apache Software License by the Apache Foundation. All code directly contributed to the effort (i.e. not in form of a class library) must have the copyright assigned to the Apache Foundation to enable integration into an Apache project.
The following items are the rough requirements for the mapping workbench.
read & edit OJB repository declaration
read (& edit later) database schema
- read existing java source hierarchy
- read existing class file hierarchy (i.e. .jar files)
- map existing java classes/sources to existing database schema
transformation forward and backward between problem domains where possible (e.g. database schema -> java source files, OJB repository -> database)
- functionality must be accessible from a graphical environment as well as from command line
- integration into Java IDE
- Netbeans/Forte/Sun ONE Studio
- Eclipse (?)
- extensive test suite for at least those funcational blocks that are not dependending on a graphical user interface, testing procedures for graphical components where possible and feasable.
4.1 Overall / Plugin Mechanism
The mapping workbench shall be a framework where distinct modules can be included for distinct tasks. The module have the responsibility for drawing the user interface (within the common UI of the mapping workbench). The plugin mechanism consists of the following functions:
- finding a plugin
- loading the plugin
- fetch the name of a plugin (create a namespace?, could be used for command line switches)
- instantiate a plugin
- fetch the currently possible actions for the plugin (The list may depend on the status of the instance)
- where each action is associated a name
- the actions are structured to make it easier to display them in a menu
- each action is assigned a commmand line switch (where possible)
- the plugin may define key bindings
- save the current state of a plugin to a datastream
- instantiate a plugin based on the saved state of an instance
- Export and Import data via copy and paste or drag and drop (data transformation is always in the scope of the receiving instance, it has to decide whether to accept or reject the data)
4.2 Read & Edit OBJ repository declaration
- Read a repository declaration (only from disk, or other sources?)
- Persist a repository declaration (only to disk, or other destinations?)
- Edit all aspects of a repository declaration
- Transform other data to a repository declaration (TBD: list)
4.3 Read & Edit database schema
- Now: Read metadata from RDBMS
- Future: create/edit objects in RDBMS (i.e. tables, fields, relations?)
- by transforming data (e.g. from OJB repository declaration)
- by manual entry
- Future: view data in tables
- Future: edit data in tables
- Future: SQL interface?
4.4 Parse existing java source hierarchy
Parse a tree of java sources, extract all useable information and display it. Can be a source for data to be transformed.
4.5 Generate java sources
Possibly can be integrated with 4.4 later so synchronization can be done. Currently parsing and generating will have to be independent.
4.6 Read class file hierarchy
Similar to 4.4 it shall be possible to parse existing class files and extract all useable information. Can be a source for data to be transformed.
4.7 Map existing database schema and existing java sources/classes
Could be a responsibility of the repository editor (copy'n'pasting database fields to class fields)