ODABA Development Environment (ODE)
ODABA provides several GUI tools in order to run ODABA databases. It is not mandatory to use those tools, but often it is much more comfortable. One may e.g. use the ODL scripting language in order to define the database schema and load it by calling the schema loader ( ODL ), but probably it is much easier to use the ODABA Class Editor instead. You may also define a set of generic .NET control in order to show ODABA data in a GUI application, but it is easier and faster using the ODABA Designer, which support active data link, i.e. you need not to care about filling and updating data in controls.
Before starting any development one has to create a project. Creating a project is supported by a simple command line tool ( CreateProject ), which one may call after installing ODABA.
For different development phases, ODABA provides different tools, which present development object from different perspectives.
- Problem analysis - Terminus
- Conceptual design - Terminus
- Schema development - ClassEditor
- Business rules and common functionality - ClassEditor
- Application design - Designer
- Application rules - Designer , ClassEditor
- Test - TestBrowser, ClassEditor , ObjectCommander
- Documentation - Terminus , Designer , ClassEditor
Often, developers like to skip documenting problem analysis and conceptual design. This is not a good idea, but one might also start directly with the schema development. Often, it turns out to be a good compromise to combine schema development and conceptual design by immediately documenting defined schema resources.
Besides exhaustive documentation features, ODE tools provide notice features, which allow linking notices on any development object. Notices might also be sent to other developers and help to control changes in an application, error report and bug tracking.
During the problem analysis, the problem is described in terms of documentation topics in a topic hierarchy. This is not only a base for communicating with the clients, but also the base for later planning and conceptual design. One way of supporting problem analysis is Terminus. Terminus provides a flexible topic hierarchy and allows linking topics creates ones to development objects later on.
The conceptual design mainly consists in providing a terminology model, which is the conceptual presentation of the database schema and essential functionality. Using terminology model has the advantage that client and developer use a common language, i.e. the expert language, which the client has do define in detail. At the same time this is the starting point and the documentation for the database schema, which has to be developed next.
In order to define the terminology model, Terminus provides the Terminology-Model support, which allows defining all relevant schema resources on a conceptual level.
One may define the database schema definition by scripting an ODL file, but much more comfortable is using the Class Editor. Defining the database schema with the Class Editor helps you by setting context depending defaults. Moreover, several wizards have been provided in order to simplify definition of schema resources.
Drop list and other features prevent the developer from making simple mistakes (as misspelling). Built-in check function help to avoid errors.
After finishing the schema development, one may change to any programming environment for implementing required functionality. In order to use the ODABA support for implementing context classes in order to provide business rules, the Class Editor might be helpful again, since it automatically generates necessary interface functions. Since the Class Editor generates necessary external resources, coding effort is reduced to 50% (concerning C++).
The Class Editor also supports implementation of OSI functions, which is easier then to provide those in external files. Moreover, the supports enhanced function documentation, which allows providing detailed system and application documentation.
A critical decision has to be made concerning the GUI design. ODABA provides a GUI framework supporting ADL (active data link), which automatically controls data to be displayed in fields and lists. With some clicks one may design complex applications, that allow browsing and updating data displayed in lists or trees and subordinated forms.
As long as using the standards the system provides for you, most things run fine. But ODABA design objects contain many properties and it becomes rather complicate, to manage all those properties properly.
When you decide to use the ODABA Designer, you will find the same principles of defining and implementing application rules as for implementing business rules. Thus, application rules might be implemented in the designer, but also in the Class Editor, or one may even use both.
Automated tests are supported by test automation tool TestBrowser . TestBrowser support unit tests as well as component tests. For testing GUI applications, an GUI action log is provided, which allows recording and replaying single and multi-user sessions.
The Class Editor provides room for implementing test functionality for classes in order to provide unit tests. This is code stored together with the functions, which will be generated in specific test functions that allow testing different scenarios. Test code might be provided for each function. In order to control results of tests in the database, one may use the ObjectCommander or the OShell command line tool.
Last but not least documentation should be mentioned. Within an ODABA development documentation is part of each development phase. Documentation is provided in terms of topics, which are linked to development resources or in one or more hierarchies. Documentation topics are composed to office documents, WEB applications or online help. Maintaining documentation topics is done typically using Terminus, but Designer and Class Editor also support updating topics.