业务建模和Web环境下的驱动方法(XXXX年4月)

业务建模和Web环境下的驱动方法(XXXX年4月)业务建模和Web环境下的驱动方法一、介绍近年来，管理信息系统的开发已经从基于4GL开发环境的编码实现，逐步转向基于业务基础平台的“快速构建、随需应变”，即采用业务建模平台对业务建模，然后通过模型驱动引擎对所建立的模型进行解释，将其“解释”成相应的业务应用系统，包括业务处理页面、业务流程和处理规则等。

业务的分析和建模通常由系统分析员采用CASE工具来做，其成果用UML表达。

虽然模型驱动的架构（Model-driven Architecture，MDA）仍然是软件行业的一个研究热点，但至今尚没有成熟的CASE平台或工具能够把UML模型自动转变为应用软件，其主要的原因可能在于UML语言对于应用软件的刻画尚难以达到类似程序语言的细致、准确程度。

一种变通的做法，也是目前软件行业流行的做法是：在可视化的模型构建或转换工具的支持下，在系统分析员的指导下，由系统构建人员把UML业务模型转换为可被业务驱动引擎准确理解的业务模型，这种业务模型的元素通常采用XML元数据来描述。

这是一个通过手工或半自动化方式，对UML业务模型进行理解、补充，使之转换为XML元数据模型的过程。

该过程要确保后者能够以XML方式，精确地刻画出完整的业务。

在这个过程中，针对业务的个性化需求，可能需要对XML标签及其相应的驱动方式进行编程式的扩展。

在定义良好的业务元数据定义模式（XML Schema Definition，XSD）的支持下，编程扩展的工作量可以显著减少，从而降低应用软件开发的复杂度。

本文介绍一种采用UML工具对业务进行分析建模，然后使用可视化的业务建模工具把UML模型转变为XML模型，最后采用J2EE技术把XML模型驱动为富客户端（RIA）Web应用的完整过程。

二、业务分析在完成业务调研后，由系统分析员采用面向对象分析（Object-Oriented Analysis，OOA）方法，对所获取的调研资料进行分析，使用CASE工具和UML 语言，建立业务逻辑模型。

这里，我们所采用的CASE工具为Sparx systems公司的Enterprise Architect（简称EA）软件，把业务模型描述为业务用例、系统用例和领域模型等三个主要组成部分。

1、业务用例业务用例的描述包括采用UML表达的业务用例图、业务流程图，以及采用Word或Excel等其他文档表达的业务表单、业务报表和其他业务资料等。

以某省国土资源厅土地利用规划业务分析为例：首先找出该项业务包括申请规划修编、申请规划局部修改和申请年度计划追加三个业务，其业务用例如图1所示。

uc 业务用例省厅土地利用规划管理部门TGBUC04申请土地利用规划修编TGBUC05申请土地利用规划局部修改市县国土所TGBUC006申请省留年度计划指标追加图1 省厅土地利用规划业务用例图其中，申请规划业务局部修改的业务流程如图2所示。

该流程是一个复杂的工作流，其中包含很多环节，在业务分析时，可以将其拆解为不同的业务子流程，并采用UML时序图，对各个业务子流程进行建模，如图3所示。

在业务流程的每一个环节，必须明确办理人、需要使用的表单、需要查看的业务材料、以及需要打印出来的表单等，此处不作示例。

在获得上述所有资料后，可以说对业务流程有了初步的了解，建立了能够反映用户业务处理过程的业务模型。

req 业务审查流程图2 申请规划业务局部修改流程图3 用UML时序图表示的业务流程图2、系统用例在获得业务流程的UML 时序图后，就可以在时序图中引入信息系统对象，分析信息系统对业务流程的影响，找到哪些事情可以由信息系统承担，这些由信息系统承担的事情及其应用场景即是系统用例。

这样，通过对所有业务用例的分析就可以找到所有的系统用例，图4所示的是土地利用规划的公共系统用例图。

uc 子用例土地利用规划提交下一环节打开待办项目列表打开项目打开项目材料附件填写意见公共角色打开拟文图4 系统用例图系统用例是用于描述系统功能性需求的主要方式，因此，除系统用例图外，还要编写每一个系统用例的规约，根据用例规约，以MVC 模式，对系统用例进行鲁棒性分析，以找出支持系统用例的界面类、控制类和实体类，其中的实体类及其关系便组成系统的领域模型，它是进行系统软件类设计和数据库设计的根模型。

3、领域模型如上所述，把系统用例中的实体类，以及系统分析员所了解到的与行业应用相关的名词、术语收集起来，明确其相互之间的关系，就形成系统的领域模型，如图5所示。

class 领域模型业务列表收件箱在办箱已办箱归档箱项目流转信息流转日志流转意见情况登记表并联审查表审核意见表材料袋项目清单申请单位信息批复意见材料图5 系统领域模型三、业务构建为了把UML业务模型转变为应用软件系统，接下来要做的工作就是通过人机交互，使用可视化的业务构建工具，把UML模型构建为XML元数据模型。

1、可视化的业务构建工具业务构建工具提供业务模型所涉及的业务角色、流程、表单、报表、业务材料和业务应用等各种业务元素的构建支持，虽然各种业务元素在表现形式上有很大的差异，但其保存格式都采用XML元数据描述。

为了能够精细地描述出各类业务元素，就必须针对不同的业务元素，定义与其相关的XSD。

图6、图7、图8分别是业务构建工具中工作流构建、表单构建和打印表单构建的操作界面。

图6 业务流程构建工具图7 表单构建工具图8 打印报表构建工具2、XML表达的业务元素上述构建工具构建所获得的业务元素通过XML来描述。

为此，必须针对业务建模要求，定义用于描述各种业务元素细节的XML标签（即XSD）。

图9是表单XSD的结构化显示，其中包括表单所支持的各种控件定义，如文本框、列表框、多选框、单选框、组合面板等，每一种控件都可以定义其坐标位置、长、宽、显示文字和其他属性。

图9 用于表单定义的XSD结构图（部分）符合上述XSD所构建出来的表单XML文件示例如图10所示。

图10 用XML描述的表单（局部）按照此XML定义，相应的表单界面如图11所示。

图11 XML定义的表单界面示例构建工具除了定义业务元素的展现方式外，还必须定义与业务元素绑定的业务数据包，这个业务数据包也被称为业务数据对象（Business Data Object，BDO），它是由许多更基本的逻辑数据表或外部数据源（如FTP文件、Web Service 数据）等组合而成的。

如果事先根据领域模型做了物理数据库设计，那么逻辑数据表可以通过对物理表的过滤和逻辑映射得到。

也可以通过BDO先定义出逻辑数据表，然后把逻辑关系表物化为关系物理表。

这就意味着，在业务模型构建完成时，我们将获得一个业务模型库和一个业务数据库，并且业务模型库确定了业务数据库的物理模式（Schema）。

四、业务驱动根据模型驱动引擎实现方式的不同，对XML业务模型进行驱动时，可以选择桌面或Web运行方式——既可以采用C/C++或C#.net技术，将业务模型驱动为Windows环境下的桌面应用；又可以采用J2EE技术，将业务模型驱动为网络环境下的Web应用。

也就是说，业务模型驱动引擎的技术选择及其运行环境，不受业务模型的约束。

这里介绍采用FLEX+BlazeDS+Spring+Hibernate实现的驱动架构。

让我们回顾一下，当完成业务构建时，后台的关系数据库管理系统中至少会有两个数据库：一个是业务模型库，其中以XML方式存放了组成业务的各个元素的详细定义数据，以及用户信息表；另一个是业务数据库，即符合业务模型要求的数据模式（Schema）。

当部署好Tomcat和业务模型驱动引擎，做好数据库连接配置，设置好默认主页后，用户即可通过浏览器驱动并使用业务应用系统了。

其基本原理是：当用户输入应用系统的URL地址后，Tomcat截获浏览器的请求，找到默认的主页，其中装载有FLEX编写的登录SWF，该SWF在前端浏览器展现出来后，用户即可输入用户名和密码，一旦提交登录请求，FLEX将在浏览器端把输入信息包装为一个远程对象（RemoteObject），该对象通过动作脚本消息格式（ActionScript Message Format，AMF）传递给服务端，服务端通过BlazeDS 将其转化为Java对象。

需要指出的是：服务器端中与业务驱动相关的Java对象被注入到Spring 框架中，以保持对象之间的相互独立性，从而使驱动引擎具有更好的可扩展性和可维护性。

用户验证的Java对象也不例外。

服务器端的Java用户验证对象被启动后，根据其业务逻辑，为了验证输入信息的正确性，必须访问用户信息表。

此时它将在Spring框架内使用与用户信息表之间形成对象-关系映射（O-R Mapping）的Hibernate POJO对象，通过该对象进行用户查询，以查看输入的用户名及其密码是否正确。

最后，将验证结果通过AMF反向传回给FLEX。

图12 驱动端的渲染效果在这个验证过程中，前端FLEX 和服务端的Java 应用是异步的，回传的信息在FLEX 中通过消息响应被相应的处理程序截获。

如果获得的是验证通过信息，FLEX 将把应用系统的界面框架渲染出来，然后再向服务器端发送获取业务基本信息请求。

服务器端收到业务基本信息请求后，调用注入到Spring 的业务信息读取对象，该对象通过Hibernate 到业务模型库读取相关的业务定义信息，再根据业务定义信息，读取业务数据库表中的相关业务实例（即项目）信息，把这些信息回传给FLEX 后，由FLEX 负责渲染。

渲染的效果如图12所示。

此后的业务驱动操作过程都遵循同样的架构模式，如图13所示。

图13 Flex+BlazeDS+Spring+Hibernate 的业务驱动架构五、前景和展望与传统的以代码编写为主的业务应用软件开发模式相比，基于业务基础平台的应用软件开发模式是一种极大的改进，其实质是：将业务流程的信息化转变为业务分析、建模、构建、模型解释和驱动过程。

显然，与传统的编程方法相比，这种模式具有更好的柔性，更能适应业务流程和业务处理需求的变化，更短的开发周期和更低的开发成本。

计世资讯（CCW Research ）认为：业务基础平台正引领国内软件业发生一场变革，一个新的软件平台产业正在悄然而迅速地形成。

业务基础平台是在FLEX Remote AM Tom Bla Spr Hibernat e 业务Java Obje ct AMF Java Bean 业务模型及用户信息库J2EE、.NET软件基础架构平台之上的全新平台。

与其他管理应用软件系统的一个重要区别在于：它本身不是一个可立即交付用户使用的软件产品或半成品，但系统实施人员可以在此平台的支持下，快速构建出最终的应用软件产品，并随需应变。