lihuixuaaa 2013-03-04
转自
http://blog.sina.com.cn/s/blog_493a84550100g140.html
在这里我们首先关注业务架构和应用架构,业务架构驱动应用架构,以体现流程驱动IT,这也是前面SOA咨询方法论的重点思想。SOA方法论的一个突出的贡献就是解决了业务架构和应用架构如何通过系统的方法进行集成的问题。可以参考我前面的关于SOA咨询方法论的描述。
对于业务架构,初看架构这个词容易理解为静态的事物,但是广义的业务架构一定是静态和动态分析的集成和融合,在分析过程中相互影响又相互促进。动态的信息即我们说的普通的价值链分析的思路,从企业端到端的高端流程到各个业务领域二级,三级等流程的分析。形成高端流程->子流程->活动->活动单元->任务->事件的主线;而对于静态信息则包括组织,人员,岗位,角色,业务对象和表单,规程,模板等各种信息。静态信息的重点是业务领域和业务对象,即形成业务领域->业务主题域->业务模块->业务单元->业务组件的静态数据逐层分解。静态信息+动态信息+交互点和接口分析后形成完整的业务架构。可以看到流程再细粒度分解后的活动单元的组合可能形成业务组件和业务模块,同时业务模块本身又存在更细粒度的流程和活动分解,业务组件本身又是多个流程的组成部分,因此静态和动态相互融合,形成交互,所以必须分析交互和接口。
按SOA方法论的思路,企业系统的构建应该是流程驱动IT,以业务架构为基本导入进行的,通过业务流程分析和业务主题域分析形成相关的信息子系统和信息组件模块,通过业务对象分析形成IT应用架构中的核心概念模块和数据库模型。注意,端到端的流程首先进行分解,分解后的子流程或活动单元变成了具体的业务组件,而流程本身需要的则是这些业务组件提供的服务,在业务组件变成系统组件并将分析出来的接口暴露成服务后,通过BPEL流程编排工具进行流程编排是自然而然的事情,因为服务本身就是通过流程交互分析发现出来的。真正体现了流程驱动IT的思路。
业务架构到应用架构的集成需要平滑过渡,在这里可以看到IBM等大型厂商已经在支持从业务建模平滑过渡到系统建模的CASE工具。从最早的MDA模型驱动架构来看,过渡强调了静态模型本身而弱化了业务流程,而最近新的SOA的建模工具则更好的结合了原来MDA有点并融入了更多的流程建模的思路。而这两年我们看到也有很多比较独立的业务架构平台,期望将IT系统的快速开发和建设前移到业务建模阶段,这些业务架构平台的共性都包括了业务对象建模,流程建模,业务规则建模和界面建模。业务对象建模转换为具体的数据库设计和业务实体;流程建模转化为BPM流程管理,包括系统自动流程化处理和人工工作流引擎;业务规则建模则转换为具体的业务逻辑和事件处理。而对于业务规则建模和流程建模在SOA中则全部集成到了BPEL流程设计中全部完成。
在企业业务建模和流程建模中常用到ARIS(集成信息系统架构),ARIS不是一个工具,而是一个概念。它是一种描述业务流程的体系结构,也是一系列包含有各种元模型的建模方法。ARIS概念的核心通过以一系列事件和任务链图的形式表达业务流程,这跟最近配合SOA谈的另外一个概念EDA(事件驱动架构)很吻合。在ARIS中涉及到四大核心视图,如下:
这四个视图和我们前面谈的业务架构中的静态模型和动态模型的思路是一致的。但是个人感觉ARIS仍然停留在传统的业务架构平台进行业务建模的层面,仅仅是方法论和思路上将,无法很好的体现从业务到IT,业务和IT集成后融合的平滑过程。在这点上SOA整体方法论,包括SOA结合EDA后将更加具有优势。这也是我所关心的基于ARIS业务架构和流程集成思路,可能仍然无法解决虽然流程集成了,但是IT系统仍然无法很好集成的问题。
什么时候用例模型独立存在?本文将通过图书馆管理系统这个简单而典型的实例来进行一次UML业务建模实例实践之旅。通过识别的参与者,对需求进一步分析,将UML业务建模实例进行分解,获得每个参与者的使用用例。