（信息与通信工程专业论文）基于dsc的业务流程开发平台的研究与实现.pdf

摘要 摘要 模型驱动架构( m o d e ld r i v e n a r c h i t e c t u r e , m d a ) 是一个以模型为中心的软件 开发框架，它支持模型的可视化、存储、交换及转换等。m d a 将抽象层次提高到 模型的高度，使开发者关注的焦点转移到业务逻辑的建模上。在m d a 中，模型是 开发过程的产品，可以方便地保持模型和代码的同步。m d a 是一种旨在使业务逻 辑和应用逻辑、实现技术相分离的软件开发思维模式，将最为繁琐的编码工作最 小化，提高了开发效率和系统的可维护性，适应了需求的不断变化。 现有的m d a 工具通常只支持m d a 开发过程的一个片段，并不支持m d a 的 整个开发过程，也没有提供一个可视化的集成环境整合m d a 的各个开发环节，使 得开发人员进行m d a 系统开发时，需要熟悉多种工具并努力使它们相互之间能够 协作。为了解决这些问题，本文提出一种新的用于搭建业务流程的解决方案，旨 在整合m d a 开发的各个环节，提供一个可视化的搭建业务流程的集成环境。该项 目是基于e c l i p s e 平台，使用j a v a 作为编程语言，并且使用了一些功能强大的开源 框架作为支撑，如图形编辑框架。项目采用动态系统图( d y n a m i cs y s t e mc h a r t , d s c ) 作为建模语言，克服了当前建模语言无法精确描述业务模型的缺点。 在本项目的开发平台d s b 上，应用系统开发者可以使用d s c 创建业务模型， 可以根据模型自动生成j a v a 代码，可以自动生成测试用例对协议进行测试，可以 使用图形调试器对设计的图形进行跟踪调试，最终可以方便地运行整个应用系统。 本文分析传统软件开发模型所面对的困难，引入新的软件开发模型m d a 和新 的建模语言d s c ；介绍m d a 、b p m 、g e f 等相关的技术理论；介绍d s c 的基本 理论，并深入地分析d s c 对各种流程模式的实现方法；阐述项目的开发思想，包 括需求分析、总体架构设计，并详细地分析项目中几个重要模块的设计实现；最 后给出一个使用d s b 设计实现的业务系统。 关键字： 模型驱动架构，动态系统图形，e c l i p s e 插件，业务流程 a b s t r a c t m o d e ld r v e na r c h i t e c t u r e ( m d a ) i sam o d e l - c e n t r i cs o f h v a r ed e v e l o p m e n t f r a m e w o r k i ts u p p o r t sf o rs o f t w a r ed e s i g n , m o d e lv i s u a l i z a t i o n , s t o r a g e ，e x c h a n g ea n d c o n v e r s i o n i nt h ee n v i r o n m e n to fm d a d e v e l o p e r sf o c u so nt h eb u s i n e s sl o g i ci n s t e a d o ft h et a r g e tp l a t f o r m t h e r ea l et w ot y p e so fm o d e li nm d a ，p l a t f o r m i n d e p e n d e n t m o d e l ( p n v da n dp l a t f o r m - d e p e n d e n tm o d e l ( p s m ) w i t hah i l g hl e v e lo fa b s t r a c t i o n l e v e l ，p i md o e sn o ti n c l u d ea n yi n f o r m a t i o na b o u ti m p l e m e n t a t i o nt e c h n i q u e p s ma l e a s s o c i a t e dw i t has p e c i f i cp l a t f o r m m d at o o l sa v a i l a b l ej u s ts u p p o r to n eo ft h ef r a g m e n t si nd e v e l o p m e n tp r o c e s s ，n o t t h ew h o l ep r o c e s s ，a n dc a nn o to f f e ri n t e g r a t e dv i s u a l i z a t i o ne n v i r o n m e n t a n di tm a k e s i tm o r ed i f f i c u l tt oe x p l o i t i no r d e rt os o l v et h ep r o b l e m s ，t h ep a p e rp r e s e n t san e w s o l u t i o nt oe s t a b l i s ht h eb u s s i n e s sf l o w t i l i ss o l u t i o ni st oi n t e g r a t et h ed i f f e r e n ta s p e c t s o fm d aa n dp r o v i d ea ni n t e g r a t e dv i s u a l i z a t i o ne n v i r o n m e n t 1 h ep r o j e c ti sb a s e do n t h e e c l i p s ep l a t f o r m 、析t l lj a v a , a n dt a k e sa n u m b e ro fp o w e r f u lo p e ns o o r c ef r a m e w o r k s a ss u p p o r t , s u c ha sg r a p h i c se d i t o rf r a m e w o r k d y n a m i cs y s t e mc h a r t ( d s c ) i su s e da s t h em o d e l i n gl a n g u a g e i tc 锄d e s c r i b eo fb u s i n e s sm o d e l sa c c u r a t e l y o nt h ed e v e l o p m e n tp l a t f o r md s b ，t h ea p p l i c a t i o ns y s t e md e v e l o p e r s nb u i l da l lk i n d so f b u s i n e s sm o d e lw i t hd s c j a v ac o d ea n dt e s tc a s 爱；e a ub eg e n e r a t e da u t o m a t i c a l l ya n dd e b u gt h e c h a r t s 谢t ht h eg r a p h i c a ld e b u g g e r f i n a l l y , t h ee n t i r ea p p l i c a t i o ns y s t 0 1 no a nb ef u n n e dc o n v e n i e n t l y f i r s t l y , t h ep a p e ra n a l y z e st h ed i f f i c u l t i e sa m o n gt h et r a d i t i o n a ls o f t w a r ed e v e l o p m e n t a n d t h e ni n t r o d u c e sab e wm o d e l i n gl a n g u a g ed s ca n dm d at h e o r e t i c a lk n o w l e d g e a f t e rn l 叽t h e p a p e r 芦e s e n mt h et h e o r yo ft h ep r o j e c t s u b s e q u e n t l y , e x p l o r e st h ee x p l o i t a t i o ni d e a sd e e p l y i n c l u d i n gd e m a n da n a l y s i s ，c o l l e c t i v i t yf l a m ed e s i g n ，a n dt h e na n a l y z e st h ed e s i g na n di m p l e m e n to f s o m ei m p o r t a n tm o d u l e s f i n a l l y , a l la p p l i c a t i o ns y s t e md e s i g ne x a m p l ei sp r e s e n t e d k e y w o r d s ：m o d e ld r i v e na r c h i t e c t u r e ，d y n a m i cs y s t e mc h a r t ，e c l i p s ep l u g i n , b u s s i n e s sp r o c e s s i i 独创性声明 本人声明所呈交的学位论文是本人在导师指导下进行的研究工作 及取得的研究成果。据我所知，除了文中特别加以标注和致谢的地方 外，论文中不包含其他人已经发表或撰写过的研究成果，也不包含为 获得电子科技大学或其它教育机构的学位或证书而使用过的材料。与 我一同工作的同志对本研究所做的任何贡献均已在论文中作了明确的 说明并表示谢意。 签名： 关于论文使用授权的说明 本学位论文作者完全了解电子科技大学有关保留、使用学位论文 的规定，有权保留并向国家有关部门或机构送交论文的复印件和磁盘， 允许论文被查阅和借阅。本人授权电子科技大学可以将学位论文的全 部或部分内容编入有关数据库进行检索，可以采用影印、缩印或扫描 等复制手段保存、汇编学位论文。 ( 保密的学位论文在解密后应遵守此规定) 签名：导师签名 日期：p 第一章绪论 第一章绪论 软件规模越来越大，复杂程度越来越高，软件质量和性能问题也越来越突出。 目前的软件开发技术能够部分地解决这些问题，但还不能彻底解决，而且又随之 带来各种其他的问题：疲于应付不断变更的需求，设计的文档迅速地失效、维护 困难，项目二期开发生产力无法提升：每当一种新的技术产生的时候，开发者必 须做许多重复的工作；异构平台互操作困难等【i 】。 1 1 传统软件开发存在的问题 ( 1 ) 开发效率问题 传统的软件开发过程通常是由底层的设计和编码驱动的。无论采用何种开发 途径，文档和相关的设计图表都是在前三个阶段中产生。随着编码的进行，这些 文档和图表很快就失去了价值，和代码之间的关联也逐渐减少。不管是写设计文 档和图表还是维护系统，都不能直接产出代码，而且代价很高，开发效率低下【l 】。 ( 2 ) 需求变更问题 由于社会信息化的快速发展，企业的管理和业务常常发生变化，客户会经常 变更需求；或者由于项目开发周期长，在开发过程中有新的需求产生。如何处理 不断变更的需求成为困扰软件开发人员的一道难题【l 】。 ( 3 ) 轻便性问题 许多公司由于技术或需求的因素必须跟从新技术，从中可以获得一些切实的 好处，但必须快速跟进，而且前期投资也都失去了价值。同时，新技术本身也在 变化，会不断推出新的版本，并不能确保完全向后兼容。现存的一些系统要么提 供接口与新技术开发的系统连接，要么转向新技术。所开发的系统如果和某种技 术紧密绑定，则该系统注定在跟随技术发展的道路上是步履沉重的【1 1 。 ( 4 ) 互操作性问题 软件系统很少能够孤立存在，大都需要和其它系统进行通信。系统往往要使 用多种技术来实现，包含大量的组件，这些技术之间、组件之间都存在互操作的 问题1 2 1 。 电子科技大学硕士学位论文 ( 5 ) 文档问题 在传统的软件开发中，文档质量普遍不高，且难与代码保持同步。但是对于 一个复杂的系统，在抽象层次上描述系统的文档是很重要的。如何保持文档和代 码的同步，又不增加很多工作量，也是一个困扰开发者的问题【1 】【2 】。 1 2 新的软件开发模式m d a 的提出 为了解决传统软件开发过程中的诸多问题，对象管理组织o m g 于2 0 0 1 年7 月提出了模型驱动体系结构( m o d e l d r i v e na r c h i t e c t u r e , m d a ) 。 在m d a 中，软件开发过程是由对软件系统的建模行为驱动的。m d a 的关键 之处在于将模型作为软件开发的核心，严格区分了系统的功能规约与实现细节。 它把建模语言当作编程语言而不仅仅是设计语言。它能够创建出机器可读和高度 抽象的业务模型，这些模型独立于具体的实现技术，以标准化的方式存储，然后 根据不同的目标平台，生成相应平台的实现模型。这样就很好地分离了传统的业 务模型和平台相关的实现模型，摆脱了对技术平台的依赖【i 】。 m d a 将软件系统的模型抽象成三种模型：与具体实现技术相分离的平台无 关模型( p l a t f o r m i n d e p e n d e n tm o d e l ，v i m ) 、与某种特定实现技术相关的平台相关 模型( p l a t f o r m s p e c i f i cm o d e l ，p s 旧和代码模型，同时又能通过转换规则将三者统 一起来，从而实现由模型直接转换为可执行代码的过程【i 】。 在m d a 软件开发过程中，m d a 将抽象层次提高到模型的高度，使开发人 员将工作重心从编码转移到业务逻辑的建模上，将更多的时间和精力投入在需求 的分析和设计上，而不会过早地投入到具体的实现中。m d a 在提高软件的可移 植性、互操作性及可重用性方面都带来了好处，使软件的工厂化生产成为可能。 1 3 新的建模语言d s c 的出现 在一个优良应用系统的部署中，建模是核心过程之一。然而，目前的主要问 题是模型在许多组织中仅仅是一项书面活动，这就产生了模型和应用系统之间的 同步问题。应用系统被更新而模型没有随之更新，模型仅仅作为文档是没有用的。 如何在建模和开发问的鸿沟问搭建桥梁，使建模构成整体不可缺少的一部分，就 成了一个非常关键的问题，而该问题的解决与一个好的建模语言是分不开的。 2 第一章绪论 目前，现有的很多建模语言提供了说明p i m 中功能的结构化部分的方法。但 对动态部分，它们依然依赖普通的编程语言来填补模型中的空缺，无法完整地支 持m d a 过程。适合m d a 的建模语言应该提供【l 】： 足够强的表现力，可以完整地说明系统。这既包含系统的静态方面也包含 系统的动态方面。应当不需要让开发者再回到普通编程语言中去工作。 一种通用的、不是特定于某种应用的语言。 把常用的低层次构造的模式抽象成单独的高层次的构造。 适合n 层应用程序开发，包含三层、二层和单层应用程序。实际层数应当 对模型没有影响，而应该是由变换工具的设置选项来调整。 适合开发分布式应用程序。 模型及其实现之间没有缝隙。 支持管理大型模型。 d s c 简单易学，可以简单地描述常见的商业流程，定义需求，消除业务和技 术的“鸿沟”；在技术应用上可以同时描述主动行为和被动行为，可以方便地描述多 方的交流；通用性强，可应用的层面也比较广泛，可以完整支持m d a 过程。使用 d s c 来开发m d a 平台是一个恰当的选择。 1 4 本文的主要工作 本文研究基于d s c 的业务流程工具d s b 的开发，提出了一个搭建业务流程的 新的解决方案。 作为一个新的m d a 开发环境，d s b 采用d s c ( d y n a m i cs y s t e mc h a r t ) 作为建 模语言，并采用插件式的体系架构，用g e f 作为图形编辑框架，和e c l i p s e 平台很 好地结合，提高了系统的可扩展性和兼容性，从而提供一个良好的开发环境。 在d s b 开发环境中，用户可以使用d s c 图形搭建各种业务流程，可以对设计 的模型自动生成j a v a 代码及测试框架，还可以方便地在图形对业务逻辑进行跟踪 调试和监控。 本文围绕着以下几个方面进行了研究，主要研究工作和预期目标如下： ( 1 ) 分析基于m d a 的软件开发过程、组成结构及现有的实现框架e m f ，并介 绍分析b p m 相关的理论知识，为下面的研究提供了理论基础。 ( 2 ) 深入探讨新的建模语言d s c 的基本语义及设计理念，将其与现有的建模 语言进行比较，并深入地分析d s c 的流程控制模式的实现方法。 电子科技大学硕士学位论文 ( 3 ) 详细论述实现的开发平台d s b 的系统结构、开发思想及重要模块的具体 实现。 ( 4 ) 介绍基于d s c 的软件设计过程，再通过一个网上订票系统展现m d a 的开 发过程，同时也验证了建模语言d s c 的诸多优势。 其中第三点是本文主要阐述的内容，本人承担的科研工作是d s b 中图形编辑 器和代码自动生成这两个模块的设计实现。 1 5 本文组织结构 第一章，绪论。分析传统软件开发过程中存在的问题，m d a 软件开发的优势， 同时也阐明了课题研究的目的和意义，简单地介绍了新的建模语言。 第二章，相关的技术理论。介绍了m d a 相关的技术理论，包括m d a 软件开 发过程、m d a 的组成结构及o m g 的四个建模层次，阐述了m d a 现有的实现框 架e m f 的相关内容；介绍了b p m 相关的技术理论，包括b p m 的介绍和b p m 生 命周期；对g e f 框架及工作原理进行详细的分析。 第三章，动态系统语言d s c 的理论与模式分析。详细地介绍了d s c 的理论知 识，包括d s c 的图元模型、d s c 与其他建模语言的比对、d s c 给开发流程带来的 变化；深入地分析各种流程控制模式在d s c 中的实现方法，充分验证了d s c 解决 问题的能力。 第四章，业务流程开发平台d s b 的系统结构及重要模块的设计与实现。首先 讨论了d s b 的系统结构，然后详细地探讨d s b 中几个重要模块的设计实现，包括 图形编辑器，基于d s c 模型的图形调试器，自动测试及代码自动生成这四个模块。 第五章，d s b 工具在业务流程中的应用。首先，用图形的形式清晰地描述了 基于d s b 的软件设计流程，然后，基于d s b 开发平台设计了一个网上订票系统， 展示基于d s b 的应用软件的开发过程。 第六章，总结与展望。对本文的工作进行总结，并提出一些还需要继续完善 的地方。 4 第二章相关的技术理论 2 1m d a 技术理论 第二章相关的技术理论 m d a 是由对象管理组织( o b j e c tm a n a g e m e n tg r o u p ，o m g ) 定义的一个软件 开发框架，支持软件设计和模型的可视化、存储和交换。m d a 可以创建高度抽象、 定义精确的模型，这些模型与具体的实现技术无关，可以用标准化的方式来存储， 可以被机器所理解。m d a 关注的是对系统的建模，而不是编码【6 】。 2 1 1m d a 软件开发过程 m d a 是与特定的平台和软件供应商无关的软件开发方法，可以用在整个软件 开发过程中。与传统的软件开发相比，m d a 软件开发方法改变了需求分析之后的 各个阶段( 设计、编码、测试、维护等) 活动生成的结果，例如在设计阶段不再 只是文档和图表，而是p i m 和p s m 。 厂广厂 m d a 开发过程，以平台无关的模型p i m 作为驱动 图2 - im d a 软件开发过程 相对于传统的软件开发，m d a 的软件开发有着相同的开发阶段，主要的区别 在于各个阶段的设计工件不同。前者的设计工件是文档图和图标，可以被人所理 解；后者的设计工件是精确的模型，能够被计算机所理解【1 1 。 m d a 软件开发过程是由模型驱动的，其核心就在于模型。m d a 将模型分为 三种，代表着对系统规约不同层次的抽象，它们分别是【6 】【7 】： 平台独立模型( p l a t f o r mi n d e p e n d e n tm o d e l ，p i m ) 平台独立模型是具有高度抽象层次、独立于任何实现技术的模型。p i m 是对 系统高层次的抽象，是对需求的建模，其中不包含与实现技术相关的信息。由于 p i m 和具体的实现技术无关，可以跨平台进行交流，因而m d a 能够独立于具体的 编程语言、特定的中间件平台等。 电子科技大学硕士学位论文 平台相关模型( p l a t f o r ms p e c i f i cm o d e l ，p s m ) 平台相关模型，是与特定平台的实现技术密切相关的模型。p s m 是为某种特 定的实现技术量身定做的，在p s m 中使用实现技术中可用的构造元素来描述系统， 例如e j bp s m 是用f j b 结构表达的系统模型。一个p i m 可以根据不同的变化规则 被变换成一个或多个p s m ，为每个特定的技术平台生成一个单独的p s m 。 代码( c o d e ) m d a 软件开发的最后一步是把每个p s m 变换成代码。由于p s m 同特定技术 密切相关，所以从p s m 到代码的变换是比较直接的。 在传统的开发过程中，这些变换( 从模型到模型的变换、从模型到代码) 都 是手工完成的，而在m d a 开发中，从p i m 到p s m 和从p s m 到代码的变换都可 以用工具自动完成。 一般来说，m d a 软件开发步骤大致如下【2 】： 使用平台无关的建模语言建立高度抽象的业务模型p i m 。此时关注的是业 务功能，这取决于具体的业务需求和业务模型。初步建立p i m 后，还要及时响应 业务需求的变化，逐步精化和细化p i m ，使其能更好地符合客户的需求； 使用变换工具将p i m 转变为一个或者多个p s m ，对每个特定的技术平台 都生成独立的p s m 。要根据业务需求选择目标构架和变换定义。 对p s m 进行不断的精化； 根据p s m 模型生成应用程序的代码和测试框架。 2 1 2m d a 组成结构及o m g 的四个建模层次 m d a 的结构可以分为三个依次包容的圈层，从里向外分别是核心技术层、中 间件技术层、公共服务层【3 】。 核心技术层包括u m l 、元对象设施( m e t a - o b j c c tf a d l i t y , m o f ) 、公共仓库元 模型( c o m m o nw a r e h o u s em e t a r n o d d c w m ) ，这些核心技术直接面对系统构架。 中间件技术层包括c o r b a ，n e t ，x m i x m l 等。通过合适的映射工具，可 以从系统体系结构模型直接生成中间层代码。 公共服务层包括o m g 从众多业务运行系统中提取的公共服务，如目录服务 等。这些服务可以方便地集成到最终的应用系统中，如空间信息服务等【4 】。 为了理解在m d a 框架中扮演不同角色的o m g 各标准之间的关系，就必须知 道这些标准定义在哪个建模层次。o m g 对其标准使用了四层架构，分别称为m 0 、 6 第二章相关的技术理论 m 1 、m 2 和m 3 1 4 t 6 s 。 m 0 层：实例 运行的系统位于m 0 层，这是实例所存在的层次。通常客户实例会很多，并且 每个实例都有自己的数据。这些实例可能会以多种形式出现，如数据库中的数据。 m 1 层：系统的模型 m 1 层包含模型，如软件系统的u m l 模型。在m 1 层的模型中，可以定义类、 属性等。m 0 层的元素都是m 1 层的元素的实例。如m 1 层有类元素c u s t o m e r ， m o 层中的名字为m a r y 和d a v i d 的客户都是c u s t o m e r 的实例。 m 2 层：模型的模型( 元模型层) m 2 层的元素规定了m 1 层的元素，每个m 2 层的元素都是对m 1 层元素的归 类。位于m 2 层的模型称为元模型。当创建元模型时，就是在定义一种语言，模型 就是用这种语言来表述的，如u m l 、c w m 、d s c 都是这样的语言。 m 3 层：m 2 的模型( 元元层) 同样，m 2 层的每个元素都是m 3 层元素的实例，m 3 层的每个元素都是m 2 层元素的归类。在o m g 内，m o f 是标准m 3 语言，所有的建模语言( 如u m l 、 c w m 、d s c 等) 都是m o f 的实例。 m o f 是u m l 、x m i 等一系列标准的核心，它不仅仅规范了定义元模型的元 元模型，还规范了如何进行元数据的管理【9 1 。 2 1 3m d a 现有实现框架e m f e m f ( e c l i p s em o d e l i n gf r a m e w o r k ) 是基于e c l i p s e 的模型框架。它是e c l i p s e m d a 的一个重要组成部分，是e c l i p s e 中许多项目的基础。e m f 可以将模型转换 成高效的、正确的、易于定制的j a v a 代码。e m f 是从作为m o f 规范在e c l i p s e 的 一个实现开始的，随后通过大量的运用在工具的实现，e m f 成为一个有效的m o f a p i 的一个核心子集的j a v a 实现【1 4 】。 e m f 是一个模型架构和代码生成工具，可以用来构建以结构化数据为基础的 工具或应用。它主要关注的领域是：生成模型时支持定制、通知、参照完整性以 及其他基本特性；生成可定制的模型编辑器；默认的序列化。e m f 可以将模型变 成代码，还可以生成e c l i p s e 插件，以及图形化的可定制编辑器。当模型被更新时， 可以很方便地使代码和模型保持同步。 7 电子科技大学硕士学位论文 e c l i p s e 的e m f 项目包含了两个非常有用的工具，用来生成源代码：j e t ( j a v a e m i t t e rt e m p l a t e s ) 和j m e r g e ( j a v am e r g e ) 。j e t 是一个通用的模板引擎。通过j e t ， 可以使用类j s p 的语法来简化模版的编写，模板描述了想要生成的代码。作为模 板引擎的j e t 可以从模板生成出s q l 、x m l 、j a v a 源代码和其它格式的输出，它 被包含在o r g e c l i p s e e m f e o d e g e n 插件中，是e m f 运行时的一部分。j m e r g e 可以 通过代码中特定注释的方式来识别是否需要覆盖目标代码，生成出来的代码可以 由开发人员反复修改和生成，而不会丢失内容，这样可以使代码生成更加灵活， 可定制性更好【l 5 1 。 2 2b p m 技术理论 2 2 1b p m 介绍 b p m ( b u s i n e s sp r o c e s sm a n a g e m e n t ，业务流程管理) ，是指发现、设计、部 署、执行、维护、优化和分析各种相互关联的流程的一种能力。b p m 的出现是为 了解决企业流程实时改变所带来的敏捷性、实时效果评估、资源整合与优化等问 题。通过b p m ，可以对业务流程进行自动化，并通过流程的分析及监控功能，对 业务进行整合及计量。 b p m 的使用是从流程的建模开始。这个阶段要把当前的流程和未来的流程详 细地列出来，并确定各个流程的性能指标。b p m 中的流程编辑器是一个图形化的 开发工具，它能够把流程模型和有关的活动流、应用和业务规则整合到一起，生 成一个可执行的流程。流程模型经过流程编辑器优化后自动生成应用系统的一个 框架，再经过修改和补充，成为一个完整的流程方案。这个方案和其他一些b p m 软件包运行时所需要的组件一起被加载给b p m 的流程引擎。该流程引擎负责整个 流程的路由、任务的追踪、业务规则的执行以及与外部系统的集成。如果一个流 程的实例完成了某活动，流程引擎就会生成一个事件来标记这个实例，这些事件 由b p m 软件包中的性能管理组件负责收集。性能管理据此计算出一些参数来衡量 业务效率。 2 2 2b p m 生命周期 从整体上将b p m 生命周期划分为业务流程的发掘、设计、执行、管理维护及 最优化这五个阶段。 8 第二章相关的技术理论 业务流程发掘：对企业现行流程的工作情况进行深入透彻地了解和分析， 是后续所有工作的出发点。 业务流程设计：该阶段是根据前期的工作对流程进行定位和设计，分为建 模、分析、模拟和流程重构四个步骤。这四个步骤是一个反复的循环，其目的是 力求得到更准确、更有价值的业务流程。 业务流程执行：该阶段分为部署、自动操作和人机交互三个步骤。 业务流程管理维护：当流程上线后，随之而来的就是管理维护的问题。该 阶段分为运行、维护和监测三个工作，它们是并行进行的，相互之间不存在递进 或者循环的关系。 2 3g e f g e f ( g r a p h i c a le d i t o r f r a m e w o r k ) 即图形编辑框架，提供了图形编辑的解决 方案。g e f 可以用来开发几乎任何和图形界面相关的应用程序，如u m l 类图编辑 器。g e f 的主要功能可以归纳为几个方面：以d r a w 2 d 中的f i g u r e 图形化展现模 型；支持鼠标、键盘及w o r k b e n c h 间的交互操作；提供支持以上功能的通用组件1 3 2 1 。 其中，d m w 2 d 是一套基于s w t 的图形系统，提供了丰富的图形绘制功能， 为构建m v c 框架中的视图部分提供了支持。但是d m w 2 d 只提供了显示模型的视 图类，并没有提供与编辑相关的功能。 图2 2 显示了g e f 的整体结构。图中椭圆阴影部分包括了g e f 的主要组成部 分，其中包含模型与视图之间的交互控制，用户与界面交互产生事件的处理以及 对模型的修改和对视图的更新控制。 9 电子科技大学硕士学位论文 图2 - 2g e f 框架整体结构图 g e f 提供了标准的m v c ( m o d e l v i e w c o n t r 0 1 ) 结构，即模型、视图和控制 器。控制器是g e f 的核心组成部分，也是完成主要控制功能的部分。视图是依赖 于d r a w 2 d 实现的轻量级图形界面。模型是g e f 应用的编辑对象。 模型( m o d e l ) 包含应用的核心数据、逻辑关系，并提供了访问数据的操作。 g e f 中的模型只与控制器打交道，而不知道任何与视图有关的东西。为了让控制 器知道模型的变化，需要把控制器作为事件监听者注册在模型中，当模型发生变 化时，就触发相应的事件给控制器，后者负责通知各个视图进行更新。 视图( v i e w ) 除了模型的显示功能以外，还要提供编辑、回显( f e e d b a c k ) 、 工具提示( t o o l t i p ) 等功能。g e f 中，视图通常利用d r a w 2 d 图形作为表现方式。 控制器( c o n t r o l l e r ) 连接模型和视图，负责根据用户请求更改模型，或者在 捕获到模型的状态改变时，更新相关视图。g e f 中，控制器是由一组e d i t p a r t 对象 组成的，每一个模型对象都对应一个e d i t p a r t 对象。应用程序中需要一个 e d i t p a r t f a c t o r y 对象负责根据给定模型对象创建对应的e d i t p a r t 对象【2 9 1 。 g e f 的命令请求及响应流程如下【3 3 】： 捕获用户的操作，并将操作转换成相应的请求。 控制器接收请求，并将请求交由相应的编辑策略管理器处理。 编辑策略管理器根据请求的类型新建相应的命令处理请求。 执行命令，命令负责对模型的修改。 模型属性修改后，触发事件。 监听器监听到事件后处理相应的操作，并通知视图进行修改。 视图更新显示界面，使之与模型同步。 l o 第二章相关的技术理论 2 4 本章小结 本章介绍了项目涉及到的主要的技术理论： m d a 技术理论 m d a 是由o m g 定义的一个软件开发框架。本章介绍了m d a 的软件开发过 程及其组成结构，并讨论了m d a 现有的一个实现框架e m f 。 b p m 技术理论 b p m 是整合企业各种业务环节的全面管理模式。本章中简单地介绍了b p m 及 其生命周期。 g e f g e f 是一个功能强大的可视化模型编辑框架，允许开发者以图形化的方式展 示和编辑模型，提升用户体验。 电子科技大学硕士学位论文 第三章动态系统语言d s c 的理论与模式分析 现在的软件规模越来越大，功能越来越复杂，软件开发变得愈加复杂和难以 把握。将复杂问题分为多个问题逐一解决是最有效的解决方法之一。软件模型就 是对复杂问题进行分解，从而更好地解决问题。建模已经成为软件开发过程中重 要的一个环节，不仅仅是开发人员的工作，而是需要业务人员和开发人员的共同 参与。这就要求建模语言必须是简单易用的，这样才能消除业务人员和开发人员 之间的技术鸿沟，使他们都能够准确地理解业务流程模型；建模语言还必须是精 确地、足够完备的，这样才能清晰地描述各种复杂的业务流程。 目前，基于m d a 的开发工具主要使用u m l 作为建模语言，而开发业务流程 的软件平台则更多使用b p m n ( b u s i n e s sp r o c e s sm o d e l i n gn o t a t i o n ) 作为建模语言。 然而由于这两种建模语言的各种缺陷，建模语言逐渐成为软件开发的瓶颈。 d s c ( d y n a m i cs y s t e mc h a r t ) 是一种新的图形建模语言，可以用图形的方式来 描述一个动态系统的复杂、动态的行为。d s c 是动态系统软件公司的d a ns h i a 设 计开发的，其设计原则是让它对用户简单易用而又足够完备。它提供了简单易用 而又足够完备的图元，可以大幅度地提高建模的效率和质量。 动态系统( d y n a m i cs y s t 锄，d s ) ，是d s c 中最基本的概念，用来描述一个实体 或物体的行为。动态系统的图形表示称为d s c ( d y n a m i es y s t e mc h a r t ) 。d s c 的开 发工具称为d s b ( d y n a m i cs y s t e mb u i l d e r ) 。 3 1d s c 中的图元模型 d s c 一共有1 3 个基本概念，其中8 个是必须具备的概念，另外5 个只是作为 辅助用的。这些辅助性的概念及图形对行为本身的描述并不会有额外的作用或改 变，只是让动态系统图能更容易被理解和使用。 下面我们首先介绍动态系统图中8 个必备的概念及其对应的图形，然后再介 绍5 个辅助性的概念及其所对应的图形【1 6 】【1 7 】。 ( 1 ) 简单动态系统( s i m p l ed y n a m i cs y s t e m , s i m p l e d s ) 1 2 第三章动态系统语言d s c 的理论与模式分析 图3 - 1 简单自主系统 简单动态系统可以简称为简单系统。一个复杂系统可以被分解为多个子系统， 而一个简单系统已经足够简单，不需要再继续分解。 ( 2 ) 组合动态图形( c o m p o s i t ed y n a m i cs y s t e m ，c o m p o s i t e d s ) 及序列与子系统 图3 - 2 组合自主系统及其序列 组合动态图形，简称组合系统。如果一个系统是复杂的，则用一个组合系统 来描述它。现实的世界有空间和时间两种维度，一个组合系统可以沿着这两个维 度来分解。沿着空间维度，一个c o m p o s i t e d s 可以被分解成多个并行的序列 ( s e q u e n c e ) ，而沿着时间维度，每个序列又可以被分解为多个顺序的子系统。在一 个组合系统里，被迁移箭头连接在一起的子系统属于同一个序列。图3 2 是一个组 合系统“d s 一) ( 以及其所包含的两个序列。第一个序列包含“子系统l ”及“子系统 2 ”，第二个序列包含“子系统3 ”及“子系统4 ”。在两个顺序子系统之间则用一个迁 移箭头来表示在时间上的迁移。 一个组合系统中的每一个子系统可以是简单的，也可以是复杂的。一个复杂 的组合子系统又可以同样地分解成多个子系统。这个分解过程可以继续下去直到 所有的子系统都不能再被分解。 ( 3 ) 顺序子系统 图3 - 3 顺序子系统 组合系统中的每个序列可以包含多个顺序子系统，一个顺序子系统可以有多 个后续的顺序子系统，根据不同的迁移条件流向不同的执行路径。 一个序列在执行时，是从它的起点开始。一个序列可以有多个起点( b e g i n 电子科技大学硕士学位论文 p o i n t ，用空心方块u 表示) 。一个序列也可以有多个终点( e n dp o i n t ，用实心方 块表示) 。当一个序列执行到任何一个终点时，整个序列也随之结束。 ( 4 ) 组合系统内的结束点 一个组合系统通常在所有的序列都结束后才结束，而有些组合系统可能会提 前结束。一个组合系统可以有多个结束点( e x i tp o i n t ，用实心三角型表示) 来描述 它各种可能提前结束的条件。每当组合系统中的一个序列结束后，所有的结束点 的结束条件都会被检测一遍。如果任何一个结束条件符合，则此组合系统即可在 该结束点结束。当组合系统结束时，即使有的子系统仍然在执行中或尚未开始执 行，这些子系统也会被迫结束。 ( 5 ) 生成箭头与动态子系统 图3 4 动态子系统 生成箭头用来指向一个动态生成的并行子系统。当一个组合系统开始执行时， 一般的并行子系统都会立刻开始执行。但是，有些并行的行为是在一个子系统开 始执行( 但尚未结束) 时，才开始并行地执行。由于这种并行的行为，并不一定 会发生，因此称其为动态子系统。一般来说，任何一个( 顺序的或并行的) 系统都可 以动态地生成多个动态子系统。只是这些动态子系统必须被包含在一个正在执行 的组合系统内，否则，动态子系统是无法生成的。 ( 6 ) 并行子系统的影子 图3 - 5 并行子系统 某些并行子系统在执行时可能会有多个实体同时存在，这种并行子系统可以 通过影子来表示。一般来说，任何一个并行子系统都可以有多个实体同时存在。 图3 5 中带有影子的并行子系统旁边的数值3 表示：当组合系统开始执行时，此并 行子系统会有3 个实体同时开始执行。由于一个动态子系统会有多少个实体同时 开始执行是事前不可预知的，因此并不需要事先指定这个数值。 1 4 第三章动态系统语言d s c 的理论与模式分析 ( 7 ) 交流箭头及交流协议 隔祥坚牺群垡橱i 系统l 卜一叫系统2f 竺竺纠系统3l 图3 _ 6 系统间的交流 在现实的世界里，多数的系统都不是能完全独立存在的。它们之间往往有某 种互动的关系。这种互动的关系，可以是多种多样的，比如产品，服务，货币， 文档，及信息等的交流。在动态系统图里，这些交流用一个交流箭头来表示，而 交流的规则，则用一个交流协议来描述。系统之间的这些交流可以是单向的，也 可以是双向的。单向的交流是用一个单向的虚线箭头来表示，双向的交流则用一 个双向的虚线箭头来表示。 交流协议是一种特殊的动态系统。如同一个动态系统，交流协议可以是简单 的，也可以是复杂的。简单的交流协议只有一个信息的交流，它可用一个简单系 统来描述。复杂的交流协议则有多个信息的交流，它可用一个组合系统来描述， 而其中每一个子系统可以是简单的交流协议，也可以是复杂的交流协议。交流协 议的图形表示同前面所述的动态系统图形是完全一致的。与其它动态系统的不同 点是，一个简单的交流协议的内容是描述一个信息。 ( 8 )自主系统及其外部活动与内部活动 简单自主系统 外部活动 内部活动 图3 7 外部活动与内部活动 一个系统通常无法直接控制其他系统的行为，而是通过多种形式的交换，如 信号、消息等，来与其他系统进行交流，以达到影响彼此行为的目的。一个系统 对外部事件做出的反应行为被称为反应式行为。自主系统( p r o a c f i v es y s t e m ，p s ) 就 是用来描述这种反应式行为。自主系统也是一种特殊的动态系统，可以是简单的， 也可以是复杂的。复杂的自主系统是用一个组合系统来描述，而每一个子系统可 以是简单的或复杂的自主系统。 外部活动( e x t e r n a la c t i o n ，e a ) 是用来描述自主系统等待的外部事件。外部 活动也是一种特殊的动态系统。外部活动可以是简单的，也可以是复杂的。 内部活动是用来描述在自主系统等待的外部事件到来后，系统内部进行的反 电子科技大学硕士学位论文 应式的动作。内部活动也是一种特殊的动态系统，分为简单的和复杂的两种。简 单的内部活动只有一个动作，用一个简单系统描述即可。复杂的内部活动有多个 动作，用一个组合系统来描述，而每一个子系统又可以是简单的或复杂的。 外部活动和内部活动通常与一个简单自主系统相关联，描述当该简单自主系 统接收到从外部来的事件时，系统内部做出的反应活动。如果外部活动或内部活 动尚未定义，则用“? ? ”表示。 ( 9 ) 顺序块 顺序块是对一些顺序子系统的图形做一些简化。 图3 8 顺序块 顺序子系统可以简