Subschema definitions

Sub schema definitions allow defining project hierarchies. Usually, a practical borderline for a project (or schema) is the executable or run-time resource resulting from the schema. ODABA GUI projects are divided in typical sub projects as business rules, common functionality and application rules. The root project usually defines the object model for the application and functionality directly based on object model definitions (mainly OSI expressions).

Thus, the ODABA GUI model is defined by the following project hierarchy:

• ADK - ODABA GUI object model and object functionality

• ADKCtxi - ODABA GUI business rules (database context classes)
• Designer - ODABA GUI application rules (GUI context classes)
• OTools - GUI tools (e.g. Object Commander, Job Timer)
• OToolsBase - Basic functionality for all other projects

This is a typical way for dividing GUI projects, but it is, of course not the only way for dividing projects. In ODABA, the projects had been divided by more conceptual issues:

• OPA - empty root project

• OPS - ODABA schema and basic context classes (business rules)

• FunctionalModel - ODABA implementation support

• OPA - ODABA kernel access system

• OPI - Interface and service classes

• Utilities
• ServerCommands
• odaba

• utils

• OQL - OSI, ODL and OShell functionality

• OPO - external access packages

• OESDF - extended self delimiter file access
• OOIF - Object Interchange Format access
• OBINA - Flat file access

It is a good practice to divide projects from the beginning, but there might be any other kind of dividing projects into sub projects as proposed above.