The Domain Object Model

This section describes the Domain Object Model (DOM) features.

You can generate DOM Java™ code to represent items defined in the Application Data Model (ADM) as Java objects. A data table is thus represented by a Java class, columns are represented by attribute accessors of this class, and foreign keys are represented by references.

References generated from foreign keys are inverted by default, so an API is generated to navigate a reference from both ends. This greatly simplifies the implementation of custom code as it is not necessary to write code to join tables. It also improves the efficiency of data processing.

In addition to the classes generated from the tables, a collector class is generated to act as the façade of the generated object model. The collector class gives access to all objects by class and provides functions to create new objects.

Once the generated Java code is compiled:
  • You can connect the generated classes to a scenario, so that you can access the scenario data using the DOM API without making reference to the table and column names. Consequently, the Java code required to access the scenario data is more concise as it no longer needs to use table and column names nor handle type checking.
  • You can exploit Java error management, type checking, code completion and other Java services.
  • The DOM API also provides you with persistence services so that you can read and write data directly into a scenario. It also provides an API to read and write data to files so that unit tests can be easily implemented. This simplifies the exchange of data.
  • The DOM API provides scenario synchronization so that changes to the scenario are propagated to the model and changes to the model are propagated to the scenario. The propagation of changes is performed using transactions and notifications to simplify the development of custom views and incremental processing.
  • The DOM provides an integration with the undo/redo stack of Decision Optimization Center Studio so that custom views can immediately benefit from this feature.

Generating Java code

An object model implemented in Java can be generated automatically from a schema defined in the IBM® Decision Optimization Center ADM editor. This generation is triggered when the ADM is modified and saved.

For a specific schema, you add a Java project to your workspace, then specify the target Java project on the Object Model tab of the Properties view of your data model schema. Saving the changes to your ADM triggers the generation of the object model Java code.

Object Model tab of the Properties view of a data model schema

You can use the resulting model's API for direct access to the associated data in Java, without needing to know the details of the underlying database schema.

Customizing the generated Java code

While default names are always available based on the contents of the schema, you can customize the generated Java code to produce code that is more in line with the intent of the model. This is described in more detail in the topic Properties for customizing the Java code generated by the Domain Object Model. Another reason to use this customization feature is because, by default, the generated Java class names are derived from the table names you defined in your ADM. If your table names are incompatible with generated class names, you should define the class or attribute names using the object model properties. Otherwise you may obtain errors from the DOM generation. You can also modify these names if you find that the generated name is not appropriate. Any errors reported during the generation errors will be listed in the Problem View.


The generated Java can be customized in two ways: either by changing the properties of the generation in the ADM, or by extending the model directly in Java. The generator will merge generated code with code you define yourself. However, if you add attributes or classes that must be persistent in a scenario, you must declare these in the ADM so that appropriate code will be generated.

Object Model Custom Task example

The Domain Object Model Custom Task example shows how to implement a custom task and custom views by generating and using the DOM.

The Data Model .dbm file includes properties to demonstrate various features:
  • use of the schema properties
  • use of the table properties (see NURSES)
  • use of the column properties (see NURSES.PAY_RATE)

The object model is generated in the Java project, package nurse.dom. You can find the implementation of the custom task and the engine in the package customtask.solve. You can also find the implementation of a table and a Gantt chart custom views in the package customView.

For more information refer to the ObjectModelCustomTask example provided in the examples\Advanced folder of your installation directory.

Synchronized and non-synchronized mode

The object model can be connected to a scenario and provides an automated mapping of the data. You can use the object model for different use cases and you can choose to work in two different modes (non-synchronized and synchronized).

In non-synchronized mode, changes to the scenario are not propagated incrementally to the object model and the object model updates the scenario by replacing the whole content of some output entities. It is very useful to implement some custom tasks (data import and export, custom engines, data checking and so on).

In synchronized mode, scenario changes are propagated to the object model and changes to the object model are propagated to the scenario automatically. Changes are grouped into transactions and at each transaction completion, both the scenario and the memory have the same data. This mode is particularly useful for implementing custom views, and also some custom tasks that require the updating of only some parts of the model.