四层架构设计驱动模型在CKM中的实践.doc

四层架构设计驱动模型在CKM中的实践 - Jack.Wang 2009-3-1写在前面：本文纯属个人想法和经验总结，如转载请注明出处，如有雷同纯属巧合 (:1. 一般的架构设计流程所有的软件开发方法都要解决从需求到实践的转换问题，为了提高软件的质量，前辈们提出了需求分析工程和各种建模技术，但是在需求和设计之间还是很难逾越，也就是说缺乏能够反映做决策的中间过程，于是软件架构设计应运而生。对于架构设计人们已经提出了许多方法，分类为：工件驱动的方法；用例驱动的法；模式驱动的方法；领域驱动的方法（这些分类就不介绍了，有兴趣的朋友可以看看相关的书籍 (: ）。一个经典的架构设计过程模型，沿用了RUP中迭代增量的思想，他由分析、描述、选择、构造和组合5个阶段组成，如图：（有兴趣的可以学习一下架构设计的元模型来设计属于自己领域或者产品线的设计过程模型，其实下面的模型也是元模型的实例化）客户 需求规格说明书功能需求 架构需求 分 析 场景和用例模型 子系统 构件 软件体系结构描述 描 述 选 择 构 造 组 合 软件架构风格 通用知识 一个经典的架构设计过程模型 依据需求规格说明书分析出功能需求和架构需求，通过用例和场景的描述，把需求分为关键的，次要的和可选的3类。关键需求决定架构，结合软件架构风格和通用知识选择最关键、影响最大的子系统分析设计并产生构件。组合就是定义构件接口，构件作为一个封闭的功能实体，对外提供交互接口，并通过连接件将构件连接起来形成最终的软件架构描述。5个阶段是不断迭代的过程，在每一次迭代中，都选取并实现一组用例和场景来确认并完善架构。 这个过程模型看似很流畅，但是，架构师在设计时很难把握他的正确性和精准性，而且用它架构的系统是否对后续设计开发形成一种原则上的指导是很难说的。我们知道层次化分析是解决复杂问题的一般性方法，下面的方法将从层次的角度来设计系统的架构模型，他将直接指导开发人员实现系统，是一个架构设计的理想方式。2. 引入四层驱动模型后的架构设计方法软件开发的过程中是存在着多个层次的，而对于每一个层次，驱动其进行的因素也所不同，所以更好的方式是，区分和建立必要的层次，从而形成一种层次化的多因素驱动的软件架构设计模型，我们将整个软件架构的设计划分为四个层次-目标层、信息层、构件层和实现层。同时，软件的整体复杂性也透过这四个不同的抽象层次得到清晰的刻画。 模型中每一层都有一种因素在驱动其建模设计的进行。目标层的驱动因素是所要实现系统的各种相关角色，信息层的驱动因素是目标层中的各种目标，构造层的驱动因素是信息层中的各种信息及其信息活动，实现层的驱动因素是构件层中的类、对象、对象交互等各种面向对象设计的元素，实现层所产生的接口、类及其属性、方法的具体某种语言代码实现框架则对接下来的编码实现阶段提供直接的支持。角色 目标 希望实现 包含多个 目标层 驱动 活动 信息活动 包含多个 后续活动 信息体 包 含 涉及 信息 驱动 构件 系统 领域构件 系统构件 包含多个 采用 采用 设计模式 架构模式 信息层 构件层 驱动 实现构件 实现配置 实用 生成 系统代码框架 实现层 3. CKM（客户知识管理）中的实践3.1 系统概述CRM系统大家可定不陌生，其实CKM = CRM+KM（知识管理），靠近BI商务智能方面的一个应用级系统，这方面在经济管理学中理论是很成熟的，有兴趣的朋友可以看看，客户知识管理是构建客户统一视图，进行客户研究，管理并传播客户知识的开方平台，为运营商实施以客户为中心的信息运营提供支撑。我就不多说了，还是看我的四层模型怎么展开吧。3.2 功能性需求 这里我就不介绍其他的架构视图啦，只是简单描述一下部分功能结构（所谓的树形层次结构，其他的架构视图，比如应用架构，视图架构，场景架构等可以看看我的相关文章）。 客户知识管理系统 标签管理 属性管理 客户列表 黄页管理 营销线索 其他 3.3 非功能性需求质量属性详细要求健壮性易用性清晰性安全性可扩展性可重用性3.4 基于四层模型的架构设计过程3.4.1 目标层次 建立目标模型包括角色识别、角色转换分析、角色继承分析、目标识别和目标分析这几个步骤（建立目标模型的核心任务）（1） 角色识别通过分析CKM项目领域中的活动，得出主要角色类型：业务人员、审核人员、实施人员、系统管理员角色 业务人员 角色 审核人员 角色 系统管理员 角色 实施人员 （2） 角色转换和角色继承业务人员提出标签属性需求后，可以转换为业务审核人员对标签属性在业务层次上审核，同时系统管理员也是从业务人员中抽离出来的，部分实施人员也会有管理员的角色，这些角色之间通过工作流链接起来。那么这些角色之间的管理如下：角色 业务人员 角色 审核人员 角色 系统管理员 角色 实施人员 角色转换 角色继承 角色转换 （3） 目标识别和目标分析目标层次中最关键的步骤就是目标识别和分析啦，由于系统中各种粒度的目标非常多，这里只是列出了角色最高层次的目标，如下图：角色 业务人员 角色 审核人员 角色 系统管理员 角色 实施人员 希望实现 希望实现 希望实现 希望实现 提出有价值的客户知识 目标 严格审核标签属性 目标 确保标签属性实施的有效性 目标 做好系统管理工作 目标 对于细粒度的目标这里就不再说明，本文旨在说明四层建模过程，并希望该思想能被更多的人吸收。3.4.2 信息层次 这部分只以业务人员的角色角度展开分析，信息层次的主要活动包括活动识别、信息活动识别、信息活动建模、信息体识别、信息识别和信息分析几个步骤（建立信息层次的核心模型）。（1） 活动识别业务人员的目标是“提出有价值的客户知识”，因此我们识别出了为何“提出有价值的客户知识”而进行的活动“构建属性或标签”（2） 信息活动识别 “构建属性或标签”活动是一个比较大粒度的活动，他包括了多个操作级别的信息活动（包括信息创建、信息传递、信息处理三种类型），具体如下图：包含 构建属性或标签 活动 创建属性或标签 创建信息 包含 包含 保存草稿 创建信息 提交审核 传递信息 包含 审核属性或标签 处理信息 包含 删除属性或标签 处理信息 （3） 信息活动建模接下来就是对上述分析结果进行信息活动建模，这里只举出创建信息活动的信息建模（其他的模型很简单，读者可以自己加）。创建属性或标签 创建信息 属性标签提出者 信息体 信息 属性标签信息 （4） 信息体识别和信息识别在建模和业务场景的熟悉过程中，我们得出了更多的信息体和信息模型，这里只简单的举一些做例子： 属性标签提出人 信息体 属性标签修改人 信息体 属性标签评论人 信息体 属性标签审核人 信息体 属性标签客户文件 信息体 属性基本信息 信息 标签基本信息 信息 属性标签扩展信息 信息 属性标签文件格式 信息 （5） 信息分析多上面获得信息近一步细化，得到更细的信息，如下图描述的属性的部分基本信息： 属性基本信息 信息 创建人 信息 创建时间 信息 有效时间段 信息 上传文件 信息 属性名称 信息 关键字 信息 可见性 信息 所属分类 信息 3.4.3 构件层次 下面是在前面两个层次分析的基础上进行构件建模，主要包括领域构件生成、系统边界划分、最终用户识别、建立系统构建并应用架构模式、建立更细力度的构件并应用设计模式。（1） 领域构件生成上面提到了五个信息体，这里他们将驱动生成五个领域模型，他们都包括在了系统顶层的领域构件“domain”中,如图：属性标签提出人 领域构件 属性标签修改人 领域构件 属性标签评论人 领域构件 属性标签审核人 领域构件 属性标签客户文件 领域构件 Domain领域构件 （2） 系统边界划分和最终用户识别构件模型中最重要的一步是确定系统边界，同时识别出最终用户。那么在这个案例中业务人员是系统的最终用户，而属性标签的提出人、审核人、修改人只是系统内部提供的管理角色。 （3） 建立系统构建并应用架构模式为了和业务人员进行交互，我们建立了系统必须的构件=UI系统构件，同时所有标签属性等信息需要持久化到外部存储设备中，因此我们引入了=持久化系统构件，最终我们选择了 MVC 架构模式并采用正交方式设计系统功能，前台结合了RIA风格，如图。Domain领域构件 系统 UI构件系统构件 持久化构件系统构件 应用 MVC，正交，RIA架构模式 （4） 建立更细力度的构件并应用设计模式通过层次细化各个构件的分布，完成用户的一次系统交互，如图：系统 UI构件系统构件 Domain领域构件 登录界面系统构件 登录Service领域构件 持久化构件系统构件 登录DAO系统构件 3.4.4 实现层次最后是实现模型阶段，改阶段主要是通过配置，最终实现代码框架，为接下来的实现代码阶段提供直接的支持。这一部分就不做过多的说