动态企业资源计划(dynamic enterprise resource planning，ERP)是当前国内外ERP系统的发展主流方向，它以荷兰Baan公司的动态企业建模(dynamic enterprise modeling，DEM)思想为基础，通过组件复用、框架层次分解等方法，形成一个易扩展、可调整的柔性ERP系统，以缓解动态的企业需求和僵硬的ERP系统之间的矛盾。动态ERP的软件生命周期模型是企业级动态ERP系统开发的前提和基础。优先研究和构造动态ERP系统的SOA生命周期模型，可以确保动态ERP系统的设计机制与面向服务的企业行为模式相一致，是一条更好的实现企业信息化、提高企业核心竞争力的有效途径。

　　目前，系统设计者在开发国内某企业动态ERP系统的过程中，遇到以下问题：①面向服务的敏捷性建模理论与实际系统开发的结合能力仍比较薄弱，难以有效地指导动态ERP系统开发；②企业业务人员、软件设计师和程序员之间缺少一个统一的SOA生命周期模型，难以达到面向服务的设计目标。

　　针对上述问题，本文提出了一个SOA概念三维模型的论断，在此基础上分析了SOA生命周期模型的研究现状，构造了一个SOA生命周期模型，选定动态ERP库存管理领域，给出一个SOA生命周期模型的应用实例，以完善动态ERP系统的设计机制。

 

　1、模型的基础

　　SOA(service oriented architecture)的中文翻译有多种版本，如“面向服务的架构叫”、“面向服务体系结构”和“面向服务体系架构”等，其中“面向服务的架构”在国内外文献中引用较多。目前，软件工程领域仍未对SOA形成一个统一的、业界广泛接受的认识。综合Gartner、W3C等组织的定义，可以知道SOA不是一种具体的实现技术或语言，而是一个抽象的概念和指导方针。与面向过程、面向对象和面向组件等方法相似，软件工程领域内的诸多设计者从自身的角度出发，对其概念可以给出不同的描述，通常表现为以下3个方面：

　　(1)从程序员的角度看，SOA不是一种语言或技术，而是一种业务驱动的IT架构模型，具备松散耦合、高灵活性的架构风格。这种架构具有松散耦合、粗粒度和标准化的接口3个特征。SOA作为一种架构模式，它将应用程序的不同服务单元通过定义良好的接口联系起来，接口是采用中立的方式进行定义，独立于硬件平台、操作系统和编程语言等计算环境，以实现企业级系统集成和信息的高度共享。

　　(2)从软件设计师的角度看，SOA是包含思想、需求建模、设计模型和实现策略等一系列的系统开发方法，为系统设计者提供了创建和使用业务服务的标准，以突出业务敏捷性的优势。

　　(3)从企业业务人员的角度出发，SOA是一种让动态ERP系统设计者摆脱企业信息化建设过程中依赖技术的局限性，要求企业业务人员关注、发现企业中存在的服务，用一种业务流程建模的解决方案来考虑企业的整体规划。

　　SOA作为分布式软件系统构造方法发展的一个新的阶段，其核心概念是服务。鉴于服务的概念在后续的章节被反复引用，为了避免概念认识上的分歧，在这里有必要对服务的概念进行说明：

　　(1)服务粒度的大小。可以分为大粒度、中粒度和小粒度3个服务，分别映射动态ERP系统中子系统、模块和原子操作3个级别。

　　(2)服务视角的不同。从企业业务人员的视角看，服务专指逻辑服务，是一个抽象的概念，即功能概念的另一种表述；从程序员的视角看，服务专指物理服务，是一个软件实体，即可重用的应用程序函数。

　　综上所述，现阶段的SOA是“一个概念，三种表述”，服务有“三种粒度、两种视角”。由于SOA的概念的不统一，容易在动态ERP系统的开发过程中造成交流上的误解和实践上的障碍，更容易引起不同角色分工合作的不一致。因此，应该采取分阶段定义的办法来避免SOA概念的混乱，图1给出了本文总结的SOA概念的三维模型，描述了程序员、软件设计师和企业业务人员在不同阶段对SOA概念的认识，以及服务概念二重性、三种粒度的描述，一定程度上体现了“关注点分离”的设计理念。

 

 

2、模型的分析

　　SOA作为面向对象的程序设计(object-oriented programming programming，OOP)的继承和发展，是当前国内外学者的研究重点。面向服务和面向对象方法的比较，如图2所示，SOA的研究领域在OOP的基础上不断扩展，例如业务流程建模(business Process modeling，BPM)、企业架构(enterprise architecture，EA)和方案架构(scheme architecture，SA)等。随着动态ERP系统在规模、复杂度、功能上的极大扩展和提高，以及在需求和技术上不断变化，使得面向对象、面向组件等众多方法不能很好地满足实际的项目开发的需要。企业业务人员与系统开发人员迫切需要一种崭新的开发方法--SOA。

 

 

尽管面向服务、面向对象、面向过程为系统设计者提供了形态相异的设计理念，但不同行业的企业级项目(如动态ERP系统)开发有一个通用的解决方案——关注点分离例，即把一个粗粒度问题分解成多级的细粒度问题集合，其中每个细粒度问题都是粗粒度问题的一个关注点，与当前系统设计者的技术实力和经验相匹配。这种方案与具体的实现技术、平台无关，是一种软件工程的方法论，可以指导一切软件工程的实践。“关注点分离”的软件工程理论一定程度上引发了系统设计者对SOA生命周期模型的思考。

　　本文在查阅众多国内外SOA文献、书籍的观点和论断后，可以归纳出SOA生命周期模型的研究现状为；

　　(1)Microsoft、IBM等诸多软件供应商及国内外众多学者纷纷推出SOA构建理论及开发平台，但是许多理论一直在不断的完善和更新，国内外学术界对SOA的实施步骤形成标准、统一的认识，还需要一段时间。

　　(2)IBM、Oracle、SAP、Sun、HP等国外著名IT公司较早的专注于SOA软件开发领域，有着一整套步骤鲜明的SOA设计方案，但其实施步骤多是与固定工具、平台相配套。由于这些IT公司对技术的保留，导致涉及技术细节的资料严重匮乏，如何在其平台上实践相应的方法，是一个不可逾越的障碍。

　　(3)国内外少数文献提到“服务生命周期”概念，但没有对SOA具体的实施步骤予以描述，难以有效的指导实践。

　　由此可知，当前实施SOA较为成功的开发单元多是技术实力雄厚的IT公司，偏重和依赖于系统设计者的经验。国内众多技术实力薄弱的中小开发单元在SOA的实践过程中，没有获得足够的理论和技术上的细节支持，SOA与动态ERP的结合是一个值得深入研究的课题。另外，在实际的项目开发过程中，本文所能收集到关于.NET平台和SOA相结合的资料也难以有效的指导实践。因此，需要对SOA生命周期模型的具体内容进行再分析和再设计，以适应动态ERP系统设计者的需要。　3、模型的构造

　　软件生命周期模型螂是软件开发组织用以映射过程要素任务、给出软件生命周期的标准模板框架，动态ERP系统作为一个规模较大、涉及领域多和开发风险大的企业级开发项目，需要对动态ERP系统全生命周期中的活动实施有效的管理和控制，形成一整套行之有效的开发步骤，从而指导企业级的项目开发。系统设计者在经过长期的探索和实践，从敏捷性开发的角度出发，对众多SOA资料进行了归纳和融合，构造了一种企业环境下SOA生命周期模型，并结合实际的系统开发，对这种模型予以积极的实践和调整，使其可操做性更强，视角更为全面，可以有效的帮助动态ERP系统的敏捷性开发。

　　设计理念日益完善的OOP为SOA的推广和应用提供一定的借鉴意义，两者的生存周期过程类似，但在具体细节上有天壤之别。在基于SOA的动态ERP系统开发中，依据软件增量式的开发原则，遵循统一过程方法(rational unified process，RIJP)的软件开发过程，其生命周期依照系统开发的时问节点，由系统目标、系统分析、系统设计、系统实现、系统测试及系统运行6个阶段组成，这6个阶段构成一个闭环，不断循环，迭代的作用于动态ERP系统。

 

 

图3给出了一个崭新的闭环的SOA生命周期模型，其具体步骤如下所示：

　　(1)系统目标阶段。主要确定系统开发的目标。并进行系统开发的可行性论证，为后续开发奠定良好的基础。

　　(2)系统分析阶段。系统分析阶段的目标是通过“关注点分离”理论定义候选的逻辑服务集合。

　　步骤1领域分解。根据企业领域的界定，将动态ERP系统分为生产、销售和库存等十几个领域，每一个领域对应着动态ERP系统的一个子系统。

　　步骤2领域的需求捕获。通过系统功能需求、质量属性需求和访问控制约束需求3个方面捕获动态ERP系统中某一领域的用户需求。

　　步骤3业务建模。对企业业务流程进行恰当的再分析、再设计，通过重组后的业务流程表述企业具体领域的一组活动(模块级)，并给出这组活动的平行结构——功能模块的划分。

　　步骤4服务建模。以用例驱动建模为中心，着重从系统使用者(角色)的视角发现原子操作级的服务，导出领域内候选的逻辑服务集合。

　　步骤5面向服务的基于角色的访问控制模型(scrviceoriented role-basedaccesscontrol，S-RBAC)。Web模式的动态ERP系统作为了一个多用户多角色访问的企业级软件，由一系列松散耦合的Web页面组成，必须考虑大粒度(子系统级)、中粒度(模块级)和小粒度(原子操作级)三级功能(或称为服务)的访问控制，给多级服务赋予职责，以补充服务建模的灵活性。

　　(3)系统设计阶段。系统设计阶段的目标是如何将服务关联到现有的应用逻辑。鉴于服务有逻辑和物理两种软件实体，系统设计阶段的主要任务是实现候选逻辑服务集合向物理服务集合的无缝过渡。

　　步骤1服务分类。将候选的逻辑服务集合分为权限控制、数据访问、基本操作和专属操作4个子集，以方便对候选的逻辑服务的管理和进一步甄别，实现业务领域向技术领域的转换。

　　步骤2服务暴露。根据预定的服务暴露原则，将分类后的候选逻辑服务集合精简为逻辑服务集合。

　　步骤3服务实现。为暴露后的逻辑服务集合中派生出物理的服务接口定义，生成物理服务集合。此外，这里使用七元组对分类后的候选逻辑服务集合ML’、逻辑服务集合ML和物理服务集合MP进行统一的形式化描述，并展现这3种集合之间的隶属关系： (符号兰代表了逻辑服务集合ML和物理服务集合MP结构和内容上的一致性)。

　　Item：：=式中，ID-序号；Service一服务名称；Role一所属角色；Input一输入参数；Output一输出参数；Function一功能描述；Implement—实现思路。

　　(4)系统实现阶段。系统实现阶段的主要依据系统架构模型，结合已开发的物理服务集合，以一种统一、符合标准的规范，实现动态ERP系统的具体功能。同时确保技术领域内物理服务集合的可用性和可维护性，为SOA在其它动态ERP子系统中的推广提供了一定的借鉴意义，解决了SOA理论和实践的脱节问题。

　　(5)系统测试阶段。主要用于测试系统的功能、质量属性及访问控制约束是否达到预定的要求，对其进行查漏补缺。

　　(6)系统运行阶段。确保系统与硬件平台、操作系统的可兼容性。

　　综上所述，通过上述6个的步骤，可以确保面向服务的动态ERP系统的有效开发，并且保证系统开发的层次感和条理性。

　　鉴于SOA生命周期模型涉及的细节过多，图3无法给出全面、细致的表述，本文将结合某企业动态ERP系统的库存管理领域，通过一个具体的应用实例，重点对服务建模中的诸多元素进行深入、细致的描述，以期对图3中构造的SOA生命周期模型形成全面、一致的认识。4、模型的实现策略

　　在服务建模阶段，从服务提供者的视角看，存在一种“系统一提供一服务”的逻辑，从服务使用者的视角看，又存在一种“角色一拥有一服务”的逻辑，后者是前者的补充。综合这两种逻辑，可以形成“角色一服务”的服务建模的思想。下面本文首先通过角色识别库存领域内“模块级”服务的使用者(角色)，利用带泳道的活动图描述“模块级”服务内诸多角色交互的过程，实现“模块级”向“原子操作级”服务关注点的转换，在此基础上，通过用例图以角色的视角发现“原子操作级”服务，以体现“角色一服务”的服务建模思想。

　　4.1库存管理领域的角色识别

　　动态ERP系统的用户并不在意系统内部如何布局、如何实现，而是关心系统提供什么样的功能(服务)，对事件如何进行响应。尤其对于重组后的扁平化结构的企业业务流程，流程中每个任务都归属于特定的角色群。基于上述考虑，服务建模的第一步就是识别出服务的使用者(角色)，抽取服务的职责所属，提供一个基于角色的服务发现视角，这是服务建模的起源。根据“关注点分离”的设计思想，角色识别的关注点放在“模块”级的“角色一服务”的描述上。图4总结了库存管理领域的“角色一模块级服务”所属关系。在业务领域分解的过程中，应用以服务的职责为依据，将业务流程按服务的职责分解。这种职责的主体可以是组织，也可以是个人。

 

 

　通过上述的分析，可以发现库存管理系统的服务使用者(角色)可以分为质检处、采购处、物资处、库房管理员和系统超级用户5大逻辑实体，在对这五种逻辑实体进行细化分析后，派生出许多具体的用户实体，如表1所示。

 

 

 

事件流是用来表示系统的动态特征，刻画结构性元素之间传递的消息、指定工作的流程、交互的序列、事件的顺序、状态的变化等行为特性。它侧重于描述系统应该做什么，而不是系统应该怎么做。活动图是UML中一种特殊的状态图，用于显示了一组活动中所有可能的状态，以及状态间的顺序或分支的事件流。它通过描述系统的工作流程(即系统从一个活动到另一个活动的流程)来补充用例图。活动图专注于系统的动态信息，用于描述用户如何做某事。它强调对象间的控制流程，对系统的服务建模特别重要。带泳道的活动图依然遵循从服务使用者(角色)的视角发现服务的原则，实现系统设计者的关注点由“模块级”服务向“原子操作级”服务的转换。本文通过UML中的带泳道的活动图描述库存管理领域的事件流模型。

　　此外，由于库存领域涉及的因素众多，因篇幅所限，不能一一详细描述。与此同时，库存领域是以表单的流转为核心，众多表单操作之间的有着许多类似之处。因此，这里将选取“领料单审批”这个细节，给出深入、细致的方案，以期对库存领域其它部分开发有一定的推广和借鉴作用。

　　如图5所示，领料审批部分的活动图有3个泳道——科员、处长和系统，物资处科员进入领料审批界面进行增加、删除、修改、查看等制表操作，在提交表单的同时，进行输入数据合法性和输入数据有效性的正确与否。如果满足输入数据混合认证，则传递给物资处处长一个未审批表单的消息。物资处长在收到消息后，进行表单的审批操作。系统对审批操作进行权限确认，进入表单已审批状态。然后系统发送给物资处科员“表单已审批”的消息，物资处科员收到消息后可以将已审批的表单打印出来。

 

 

4.3基于角色的服务发现

　　基于角色的服务发现是服务建模的核心环节，用于从系统使用者(角色)的视角发现与角色相关联的个性化服务，将关注点放在“原子操作级”服务的发现上，形成一种“角色一原子操作级服务”的设计思路。用例图是对系统需求进行建模的重要技术，着重从系统使用者(角色)的角度来描述系统外部的参与者和内部用例之间的关系，用来定义业务处理中的业务规则及任务，以及计算机应用系统怎样支持这些任务。基于上述分析，可以认为用例图能够帮助企业业务人员抽取系统为角色(系统使用者)提供的服务(功能)，实现“角色一原子操作级服务”的发现。

　　如图6所示，库存领域的领料审批部分的系统使用者(角色)有物资处科员和物资处处长两种。从系统使用者的视角出发，物资处科员是一种的普通用户，具有增加、删除、修改、查看和打印表单各种操作的功能。物资处处长的作用是审核物资处科员的制表操作，一定程度上的约束和监督物资处科员。从动态ERP系统的视角出发，动态ERP系统提供给物资处科员(角色)增加、删除、修改、查看和打印表单等服务，提供给物资处处长(角色)审批服务。综上所述，用例驱动建模中的用例图是建立在带泳道的活动图的基础上，确保了“原子操作级”服务的发现。

　　4.4候选的逻辑服务集合

　　综上所述，经过角色识别、事件流描述和服务发现3个步骤，可以确定库存管理领域中领料审批部分的候选逻辑服务集合包括增加、删除、修改、查看、打印和审批6个“原子操作级”服务。

　　由此类推，系统设计者分别选定报验、入库、退货、库存综合、调库、领料审批、出库7个模块依次进行服务建模，可以形成库存管理领域的逻辑候选服务集合。目前的候选逻辑服务集合只是上述7个模块中服务的堆砌，为了方便服务的具体实现，本文将在后续的系统设计阶段对其进行服务分类、服务暴露及服务实现，因篇幅所限，这里不再对其进行详细描述。

　　5、结束语

　　SOA生命周期模礁是面向服务的动态ERP系统开发的前提和基础，优先研究SOA生命周期模型，是约束和规范动态ERP的设计机制的必要保障。为达到这个目的，本文从实际的项目研究出发，针对目前动态ERP系统开发过程中存在的问题，提出了一个易于理解、可操作性强的SOA生命周期模型。该模型逻辑简明，通用性强，对整个动态ERP系统的开发具有一定指导价值，为完善动态ERP系统的设计机制提供支持。