为了提供对模型驱动的软件开发技术的有效支持，UBF台提供了一种领域特定语言（DSL），其中包括了业务领域语言、表单领域语言、流程领域语言以及报表领域语言等。并针对不同的领域语言采用不同的模型化以及组件化的生成方式，例如通过业务领域语言，可以有效地建立实体模型、数据模型以及服务模型，并且根据模型的关键属性与特征生成相应的软件组件。通过多种模型生成的各种相关的软件组件在应用组装语言的支持下实现动态组装，从而快速形成一个完整的应用系统。

其中：

• 版型

是扩展业务实体定义的描述方法，是对业务对象进行分类识别的工具，主要用来对业务模型进行抽象，找出实体间的公共属性；每个版型可附带一个代码片段作为模版，根据业务需要由设计人员动态创建，在实体定义阶段进行引用。通过设置版型，对实体进行标识，从而易于识别，并可基于版型进行分类。比如：帐表类实体等树形实体，可通过建立版型进行识别。

• 特性

可在不同实体间复用的属性集和版型集；可复用的属性集和版型集通过实体转存为特性，在维护实体属性和方法的时候通过引用特性引入已保存的特性。 

• 模式: 

可在不同组件间复用的实体集，以及实体间的关系。

1.1 实体模型

实体模型用于描述业务数据的结构和关系。实体模型族中包括实体组件、实体、属性类型、数据传输对象、动态枚举、异常、实体校验器、事件和关系。其中关系分为继承、组合和关联。

1.1.1 实体组件

实体组件与软件行业通常所说的组件的概念并不相同，实际是用于描述一组具有强依赖关系的实体的边界。在一个实体组件内仅能有一个主要实体及其组合的实体。UBF的持久化引擎使用实体组件的元信息以保证实体组件内主实体与其组合实体的生命周期的一致性。

1.1.2 实体

实体模型用于开发者定义应用的数据模型。实体模型中包括属性和方法。实体分为主实体和非主实体，其中只有主实体才能组合非主实体，而不能被组合。

在实体模型上需要指定实体在数据库上存储时的数据库表的表名。如果该实体继承于其他实体，还需要指定这种继承关系在数据库上的存储方式，目前UBF仅支持单表继承——即基类的数据也将存储在具体的实现类对应得表中。为了优化实体数据的加载和保存效率，开发者还应当在实体上建立一个索引项，并仔细地规划索引项中应当包含的实体的属性和次序。

实体模型上还有用于通用查询服务的标志，如果开发人员设置了该标志，则通用查询服务将可以展现该实体的数据。

如果开发者设计了一个仅用于继承的抽象实体，需要设置抽象类标志。

1.1.2.1 实体的属性

实体属性是关于实体中数据项的描述模型。它的基本信息包括名称、类型、显示名和缺省值。

实体属性模型中有一组关于校验的信息用于持久化引擎对数据的合法性进行校验，如可空标志、只读标志、字符串的长度以及数值类型的值范围等。

实体属性模型中与持久化有关的信息包括业务主键、一旦使用不可修改、国际化、是否敏感日志字段。其中如果声明为业务主键则该属性将成为该实体的唯一约束的一部分，只有当实体对象上所有业务主键属性的值组合没有重复时，该实体对象才能成功地增加。国际化用于指定字符串类型的属性是否支持多语编辑和保存。一旦使用不可修改标志用于类型为其他实体——引用关系，被设置后表明该实体对象所引用的其他实体对象将不能被修改。是否敏感日志字段标志用于指定该属性的改变是否做系统得变更记录。

实体属性还可以被指定为计算列，并能定义计算表达式。计算列不会被存储到数据表中。

关联实体可见和服务可见标志用于指定属性的可见性，只有被设置的属性才能被关联实体访问或作为服务的参数。

而查询属性标志则，表示该属性是否可以被通用查询服务所展示。

实体上可以指定任意数目的可开发者设计的校验器，以保证业务数据的合法性。

1.1.2.2 实体的方法

实体方法是关于实体中行为的描述模型。开发者除了可以指定名称、显示名称和返回值类型等基本属性外，还可以指定可见性——如public、protected等，以及静态、虚方法和重载方法。

实体的方法模型上可以声明任意数量的异常，以表明该方法将可能抛出这些业务异常。

1.1.2.3 实体的版型

开发者可以为实体指定一个或多个版型。

1.1.3 属性类型

属性类型是一种没有独立生命周期的特殊实体。它可以有属性和方法，但没有校验器。属性类型模型没有持久化相关的信息，不能被持久化到独立的表中。它的数据只能被存储到使用它的实体的表中，相当于嵌入在实体中的复合数据。

1.1.4 数据传输对象

数据传输对象是可以远程传输的特殊实体。但不能被持久化到数据库中。在数据传输对象中其属性的类型如果是实体类型，则应当指定是实体的类型本身还是实体Key类型。通常应当指定为实体Key类型。

1.1.5 动态枚举

动态枚举是一种既可以在设计期指定枚举值，也可以在运行时动态增加枚举值的数据类型。

1.1.6 实体校验器、事件和异常

用于定义实体的业务校验器和业务异常信息以及业务处理过程中发出的业务事件。

1.1.7 关系

关系的模型用于定义实体间的关系。这包括继承关系、组合关系和关联关系。组合关系只能用于实体组件内部，而关联关系只能在实体组件间使用。

像数据库的表设计一样，组合和关联关系可以定义为一对多、一对一、多对多关系。

在关联关系中需要定义级联删除规则。当级联删除标志置为True时，表示需要对关联关系的被引用实体在删除时做级联删除检查，否则不做任何控制。如果级联删除规则为NoAction，表示如果要删除的实体被引用，则将不能被删除；如果级联删除规则为SetNull，表示如果实体被引用，则当它引用的实体被删除时，引用方改为空值；如果果级联删除规则为Cascade，表示如果要删除的实体已经被引用，则连同引用者一起删除。当是否启用级联校验置为True时，如果将要删除一个实体的实例时时需要将该关系上引用被删除实体的实体纳入到规则控制范围内，否则不检查改实体的实例是否引用了将要被删除的实体。

在关联关系中也需要定义级联修改检查规则。当修改校验被设置为true时，该关联关系的被引用实体的实例修改时，引用它的实体将被纳入到引用检查范围内，否则不检查该类型的实体实例是否引用了需要修改的实体实例。

1.2 服务模型

服务模型用于描述业务逻辑处理的接口信息。服务模型可以定义服务和业务操作两种接口，在模型上需要定义参数、返回值以及可能抛出的异常。同时还需要指定对数据库事务的支持方式。当一个服务接口可以有多种实现策略时，可以定义多个策略。当然策略的选择逻辑需要开发人员在随后的开发过程中通过编程实现。

服务与业务操作的差异是与软件的部署方式和应用组件的边界相关的。UBF提出了服务组的概念，一个服务组是指一组具有高度耦合性的业务组件，它们在安装部署时具有不可分割的整体性。因此当开发人员准备调用另外一个服务组内的组件提供的功能时，只能通过声明为服务类型的接口调用，而在服务组内组件间的相互调用通常使用业务操作。注意这种划分并不仅仅与是否支持远程调用有关，通常无论服务还是业务操作都支持远程调用。

1.3 界面模型

界面模型用于描述应用的交互界面。它包括表单数据模型、表单模型、参照模型及表单模版。

1.3.1 表单数据模型

表单数据模型（UIModel）用于开发者定义界面的数据模型。它由一个或多个视图（UIView），以及视图间的连接关系（UILink）和动作（Action）组成。

每个视图可以关联一个数据来源——目前我们仅支持实体作为数据来源，视图下包含数据项（UIField）以及这些数据项的分组（Group）和缺省的数据筛选条件。数据项通常绑定到该视图所关联的实体的属性上，当然开发者也可以建立没有任何绑定关系的数据项以用于存储交互逻辑需要的临时性数据。缺省的数据筛选条件是开发者在设计阶段用OQL定义的缺省数据加载条件，可以通过代码动态的修改。

动作用于开发者设计界面的功能行为，通常UBF的设计工具会缺省地预置一些常用行为，如保存、删除、查找等。

1.3.2 表单模型

表单模型（Form）用于开发者定义用户界面，如显示内容、布局、前端控制行为等。在表单模型中UBF提供了30种是用于ERP软件开发领域的控件，其中有数据录入型的控件也有前端行为控制用的关联控件。每个控件都有数据来源的绑定信息，通常都来源于表单数据模型，特殊情况下开发者可以不绑定UIModel，在代码中实现控件内容的管理。

表单模型上由关于Portal整合时使用的表单关联方面的信息。其中Form参数用于定义表单接收的参数，而提供者集合用于定义表单可以提供的参数。

1.3.3 参照模型

参照模型是轻量的表单数据模型和表单模型的复合体。因为大多数参照页面无论是界面风格还是表单数据模型的结构都具有相似性，唯一定义的仅仅是表单数据模型中视图所关联的实体和数据项以及过滤条件，因此UBF提供了这个简化版的模型以方便开发工作。

如果开发者需要定义一些特殊的参照页面，可以使用表单数据模型和表单模型像开发页面一样去开发参照页面。

1.3.4 表单模版

表单模版用于表单模型的重用目的。通常有一些页面大体相似，仅有一些局部的差异，开发者可以为相同的部分设计表单并生成表单模版，然后在开发表单模型时套用该模版。注意模版套用是一种复制动作，因此对模版的任何修改都将不会影响已经套用了该模版的表单。同时在一个表单上只能在模型创建时进行模版套用动作。

1.4 应用组装模型

应用组装模型用于描述应用的整体结构。包括应用领域的多级划分，每个应用下包含的前后台组件、应用的功能菜单结构、应用的页面。

1.4.1 应用模型

用于软件开发者以树状结构规划其开发的软件产品。开发者将其开发的业务组件和界面组件规划到每个应用中。作为支持组件化开发和交付的平台，UBF为软件开发者提供了从应用功能和客户价值角度描述其软件产品的模型。依据该模型所提供的信息，软件开发者可以实现相应的安装和许可证策略，以及组件间接口衔接的策略，为达到按需交付提供有力的支持。

1.4.2 页面模型

页面模型用于定义在Portal上显示的Page的信息。每个页面上可以定义一个或多个表单，页面内的布局支持条带式布局方式，即一个页面内可以有一个或多个条带，每个条带内可以放置多个表单，按次序从上向下自然排布。条带的宽度由开发者指定，不会因内部表单的尺寸而发生伸缩，但高度不能确定，由所有内部表单的高度综合确定。

在页面模型内可以定义表单间的关系，即将一个表单的提供者参数与另一个表单的接收参数间建立绑定关系。这样当提供方表单的数据发生变化时可以引发接收方产生相应得变化。