Xomega Technology

Xomega is an XML-based object modeling technology that enables extensible generation of various system artifacts using the standard XSLT transformation technology. It provides a powerful framework for capturing the most essential elements of the model in an easy and flexible way so that it can be further refined and enhanced to support different generators. This Xomega unique approach helps building clean and well organized models that are easier to maintain, which results in more robust and consistent system designs. This is important when, following the best practices of Model Driven Development, the models are put at the core of the development process and serve as a source for generating and possibly regenerating other system artifacts from it. In addition to increasing developers productivity, improving the product quality and reducing development costs and time-to-market, Model Driven Development can make your system more portable and thus future-proof your investment.

Being defined in a plain text format, XML-based models lend themselves to a better collaboration and change control management as opposed to the models defined in a graphical form, since text files are much easier to compare, merge and resolve conflicts. Nevertheless, they can still be transformed into any other format that can be displayed graphically, such as XMI for UML diagrams.

Basic Structure of Xomega Models

Xomega models allow declaring various entities such as objects, types, field-sets, structures and enumerations that help you describe your business objects and relationships between them and define a service layer for the business objects. All related entities are logically organized into modules to help you manage your model more effectively.

Most model elements have an associated child element (<doc>) for a short description and detailed documentation, which helps you keep all the relevant information together and also allows generating more formal documentation from the model in your preferred format.

All the essential elements have a dedicated node (<config>) for additional configuration to be used by different generators. Such nodes serve as extension points where you can supply your own configuration for your custom generators.

Xomega Objects

At the core of the model is the definition of a business object, which consists of the object name followed by a list of fields that can be declared as a mix of individual fields and references to reusable field-sets that are declared separately in the model. Each field has a name and a type that should reference one of the types defined in the model.

One of the fields is typically marked as a key with a specifier whether this is a serial auto generated key, a user supplied key or a reference to another object's key. Unless it's a reference to another key, the key field should use a dedicated type that no other object uses for its key type. This way whenever any other field is using this type or any type derived from it, it will be automatically considered as referencing this object and a foreign key will be generated unless specifically overridden by the field configuration. Composite keys are defined in a similar way where a field-set reference on the object is marked as a key.

In addition to the list of fields an object may consist of a number of sub-objects whose definitions are nested inside the definition of their parent object. A sub-object (also referred to as a child object) cannot exist without its parent object and should be deleted whenever the parent object is deleted. Unless the child object's key is serial and hence unique, the parent's key is automatically included into the child's key. There is also an implicit foreign key relationship between the child and the parent objects with cascading object deletion.

Xomega Types

Xomega allows defining logical type hierarchies right in the model. The declared types are then used in other model elements, such as object fields. Any type may extend another type and inherit its properties and additional configuration, such as a mapping to a corresponding physical type, e.g. SQL type, which can be overridden in the derived type. If certain configuration is not specified in the derived type, the one from the base type will typically be used.

Generally, a type hierarchy is built on top of a set of base framework types, which defines most of the mappings to the physical types. Xomega comes with a set of predefined base types that you can extend and customize for your needs. The derived types will then typically specialize the base types according to the business domain structure.
Using the same Xomega types in the model helps to ensure consistency between different system's elements both vertically and horizontally. For example, if you define a user name to be of a certain length then all generated database columns that contain a user name will have consistent lengths and appropriate validations to restrict the length could be added to the corresponding editing UI controls or business layer fields. By the same token, any Boolean field can be consistently represented by the same SQL type (e.g. bit) or a UI control (e.g. checkbox).

Xomega Field-sets

Field-sets define a named group of fields in the model that can be used for one or multiple object definitions. On one hand, field-sets provide a mechanism for declaring composite object keys, which can be referenced by other objects thus establishing a foreign key relationship.

On the other hand, they enable support for reusability where the same set of fields is used by many objects. This comes in handy in aspect-oriented designs. If, for instance, most or all of your objects are supposed to have a modification stamp, which can include a timestamp and the user of object's creation and the last update, then you will be able to declare a field-set with these four fields and then just reference it in every object.

In the spirit of extensibility, you can override any field in the referenced field-set by adding a child field element to the reference and then setting the properties you want to override on that field.

Xomega Operations

Each business object may support a number of operations, which form a service layer for the business objects. The structure of the service layer may be totally different from the structure of the underlying business objects, however typically there are a lot of similarities between the two.

A business object operation consists of a definition of its input and output structures, operation description and a set of additional extensible configuration parameters such as WCF operation attributes, etc.

You can define the structure of operation’s input and output either inline by listing the parameters and nested structures explicitly or by referencing existing reusable structures that are defined in the model or both as a combination of the two approaches.

This clearly implies that you can define any named structure in the model and use it for specifying business object operations or as part of other more complex structures.

Parameters that have a matching field in the object definition do not need a type as it can be derived from the field’s type. Also, any parameter or structure can have a list attribute set to true indicating that it represents an array of values or structures.

One of the key features of defining structures in the Xomega object model is the ability to indicate which presentation data object the structure should be a part of. The idea behind that is that in the multi-tiered applications where the presentation layer communicates with the business layer through a service layer, the structure of the service layer is much more suitable for generation of the presentation data model than the structure of the business layer itself. However, since a presentation object that serves as a data model for a single UI form may use several service operations to read its data or to make updates, it may need to be combined from the structures of those operations. In other words, this feature allows you to easily define presentation data objects built from the parts of existing model structures and operations.

Xomega Enumerations

In business object modeling certain fields may sometimes assume only a limited set of predefined values, which typically have a short code and a longer description. These static lists of possible values and each of their individual values may have very important business meanings, such as different statuses of an order. Unfortunately, this information is oftentimes not included into the formal business object models and developers just keep it in special database lookup tables and maintain SQL scripts to populate those at best, or have these values hard coded all over the program at worst.

Xomega provides an easy and flexible way of defining these static lists as named enumerations, which can also be associated with any logical type. Each item in the enumeration has a standard unique descriptive name and a short value that gets actually stored in the database. In addition, you can specify any number of additional properties for each enumeration that enumeration items may also have.

Once you have defined the enumerations in your business object model, you will be able to generate an SQL script that populates the database lookup tables or build a simple XML file that the program may be using for the lookups instead. You can also generate static constants that you can use in the code to work with individual values.