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

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

业务建模和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所示。

图1 省厅地盘操纵规划业务用例图
此中,申请规划业务局部点窜的业务流程如图2所示。

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

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

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

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

这样,通过对所有业务用例的阐发就可以找到所有的系统用例,图4所示的是地盘操纵规划的公共系统用例图。

图4 系统用例图
系统用例是用于描述系统功能性需求的主要方式,因此,除系统用例图外,还要编写每一个系统用例的规约,按照用例规约,以MVC模式,对系统用例进行鲁棒性阐发,以找出撑持系统用例的界面类、控制类和实体类,此中的实体类及其关系便组成系统的领域模型,它是进行系统软件类设计和数据库设计的根模型。

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

图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〕认为:业务根底平台正引领国内软件业发生一场变化,一个新的软件平台财产正在悄然而迅速地形成。

业务根底平台是在
J2EE、.NET软件根底架构平台之上的全新平台。

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

以业务根底平台为核心,实现业务的快速构模和随需应变,在广泛采用IT 工业尺度的前提下,使用XML暗示的元数据对系统进行描述和集成,集成商务智能〔BI〕、常识打点、地舆信息系统〔GIS〕、计算机辅助设计〔CAD〕、三维等各种IT技术,为用户提供全面解决方案,已成为新一代信息系统开发的主流方法和实施手段。

相关文档
最新文档