面向对象分析过程案例实战

1、 HYPERLINK /FcBayernMunchen/archive/2010/08/15/58136 /FcBayernMunchen/archive/2010/08/15/58136 67.aspx这是我在csdn博客的第2篇技术文章，本来按原计划是要介绍开源 ajax框架buffalo的第2部分，即jsjava的序列化，这里面涉及不 少设计模式的运用和JAVA SE知识，代码精简，比较精彩。但是由于个 人时间有限，在抉择之后，打算先写一篇关于面向对象分析的文章，也 算是对自己过去1年多在这方面学习的总结。我选了比较简单且大家 也比较熟悉的案例来分析，案例虽然简单，但是基本的分析方法和推

2、导 过程还是一致的，我主要想讲的是原始需求是怎么通过层层分析和推 导而形成最后可执行代码的，限于自己的个人能力，如果有谬论和错误 之处，还望同行多指教和帮助，共同进步。原 始需求描述如下：某公司鉴于业务和员工的快速发展，为了提升 整体工作效率，公司准备开发一套员工报账系统，取代原来的人工处理 方式，更加方便的服务于员工日常的账务操作。财务部门能够通过账 务系统定期向各部门负责人反映账务统计情况，并设置和维护相关额度 准则。系统应该具有基于先进技术的操作界面。这段描述里包含的业务目标大致有二：为员工提供账务的自动化办理，提高办事效率，方便员工。方便财务部门管理好账务信息。这些业务目标一般在项目的

3、招标书里都有相关的描述，也可以由开发 方整理得出。之所以这里要把业务目标列出来，是因为我所采取的方法 里，业务目标是进行需求分析的第一步，接下来的推导过程和业务模型 的建立都是根据业务目标开始的。整 理出了业务目标后，接下来先不要一头扎进具体的业务流程和业 务细节之中去，应该先把涉众找出来，整理出一份涉众分析报告，涉众 就是和这个项目相关的人。也不要就去考虑技术实现细节，要用什么 先进的技术，界面如何美观，性能如何优越等等，虽然这些确实重要， 但是相比起来，忠实的实现涉众的期望，满足涉众的需 求才是最为重 要，也是一个项目成败的关键。在实际的项目中，我们可以通过需求调 研找出相关的涉众，这里我

4、就直接列出本案例的涉众分析报告：员工：公司的正式录用雇员；期望：通过网上办理账务业务申请，计 算机控制流程。部门经理：部门负责人，负责审核员工提交的申请；期望：方便审核 操作，通过计算机代替原来的手工审核方式。公司主任：公司负责人，负责2次审核员工提交的申请；期望：方便 审核操作，通过计算机代替原来的手工审核方式，界面友好易 用。财务主任：公司财务部门负责人，负责发放报账款项；期望：通过计算机转账的方式替代原来的人为付款方式。以上的涉众分析报告是很简单的了，在实际稍微复杂些的项目中要下 功夫好好整理清楚一份完整的文档才是，因为接下来的业务用例获取工 作也是在此基础上展开的。这 里先罗嗦下业务用

5、例和平时开发中的我们开发人员从项目经理或 者需求人员手中拿到的需求文档中的用例什么区别。按我个人理解来说 后者是系统用例，两者的关键区别在于抽象层次和用例粒度的不同， 系统用例是以人与计算机的每次交互为单位的，而业务用例则是在较高 的层次上用于确立业务需求范围和描述系统功能性需求的。也就是说 我们在描述业务用例的时候，可以不用去考虑具体和计算机相关的实现 步骤和细节，从而降低我们人脑需要考虑的复杂度，专注于确立业务需 求范围，抽象就是面向对象的优势所在，不用像过程化思维那样通盘 考虑，因为人脑能接受的信息量是有限的。系统用例一般是从业务用例 中推导出来的，本文之后会有关于这方面的推导过程。不知

6、道有没跑题，罗嗦了一段，现在回来，分析下本案例中的业务 用例获取工作。说到用例，就必须结合边界和业务主角，否则用例的粒 度就会出现问题，因为用例是 以参与者（业务主角）为核心的，是由 业务主角发起的以达到业务主角完整目标为标准的。要获取用例就必须 先得出边界，边界有了，那么边界外的业务主角就有了，那么业务主角对这个边界内的目标就是用例了。用UML表示如下:我们先来看看一个小例子，没有引入边界的概念对获取用例有什么影 响，比如我去食堂就餐，要先领取餐具，然后点菜，打菜的阿姨帮忙盛 菜，接着我刷卡付款，去盛饭和汤，之后是找座位，最后才开始就餐。 那么领取餐具，点菜，刷卡付款之类的算是一个用例吗？说

7、算也算， 说不算也不算。因为这要根据边界来确定的，我们都知道用例是以主角 发起的以完成主角的完整目标为标准的。这里的主角就是我本人，要确 定我的目标 就必须先确定边界，比如以整个食堂为边界，那么我去食 堂的目的就是就餐，就餐才是我的完整目标，而其他诸如领取餐具，点 菜，刷卡付款之类的都不是我去食堂的目的，这些只是我完成就餐的 步骤而已，但如果把边界粒度降低到食堂的内部，那么这个时候领取餐 具，刷卡付款之类的也是一个用例了，虽然都是用例，但是和 就餐这 个用例的粒度是不同的，因为他们边界所在的抽象层次不同。所以要描 述用例就必须先划分出边界来，主角站在边界外对这个边界提出目标， 一个目标就是一个

8、用例，否则在描述系统的时候就会出现如我去食堂 的目的是刷卡付款这样的笑话来，当然了，除非我去食堂的目的真的只 是为了付款。回到本文的案例中来，开始进行获取业务用例的分析，刚才说了，要 获取用例必须先确定好边界，那么怎么确定边界呢？这 个时候我们 前面划分业务目标的作用就体现出来了，我们可以以每个业务目标为一 个边界，因为所有业务目标汇集起来就表示达到了系统建设目标，而针 对每个业务目标定义的边界，明确了哪些涉众与这一业务目标有关， 他们作为业务主角站在这一边界外提出他们的期望，这些期望作为用例 都是为实现这一业务目标服务的，获 取业务用例的方向就明确了（不 符合这一业务目标的期望则不被采纳）。

9、如 上图，边界和业务主角都已经有了，接着就是找出用例了，我以员 工账务服务边界为例，根据涉众分析报告和客户访谈（这个在实际项目 中需要好好历练的，我觉得 要有技巧引导客户，还要有较强的总结概 括能力吧）得出的。假定我从与客户访谈的结果中得出员工对这个系统 的期望和目标有通过计算机申请报销业务，申请借款业务，这两个期 望都是与员工账务服务这个特定的业务目标有关的，所以可以作为业务 用例被纳入到员工账务服务边界之中。如果假设员工也可以参与管理账 务信 息，那么得出的员工对系统的期望就不止这两个，但是分析的时 候要注意与员工账务服务这一业务目标相关的期望只有申请报销业务 和申请借款业务两个，其他的期

10、 望是与管理账务信息这个业务目标有 关，应当被划分到管理账务信息边界中去。有 的人可能会问了，貌似部门经理也有对员工账务服务边界有贡献 啊，不是有参与审核吗，为啥部门经理审核账单就不能算一个业务用例 呢？之所以会出现这个疑惑和 误区还是因为没有分清楚边界造成的。 因为对于员工账务服务边界来说，处于该边界的之外的业务主角只有员 工，而部门经理，公司主任，财务主任都是在这个边界 之内的，他们 的工作都只是完成业务主角提出的业务用例的一个步骤，在这里他们作 为业务工人无权提出业务用例，他们的职责可以在绘制用例场景活动图 的时候通 过泳道体现出来。接下来是建立业务模型阶段，建立业务模型的目的是为了通过

11、UML这 种对象语言将现实世界描述出来，是我们为了理解客户的业务并和客户 达成业务上的理解而建立的模型（我们的系统将要面对的问题领域就是 这个样子），它不需要考虑计算机环境，相对于系统模型来说，他没有 加入计算机元素，是对现实业务的一种直观的理解。我们平时开发时接 触的软件需求规格说明书来源于系统模 型，他描述的是软件系统 要实现的功能范围，和计算机环境密切相关，软件需求只是整个需求过 程的一部分，可以从业务需求中推导出来的。业务模型主要包括业务用例，业务用例实现场景，业务规则，业务用 例规约等等，限于个人掌握程度及个人精力所限，本案例中我主要讲述 业务用例和业务用例场景图，业务用例场景主要是

12、描述业务用例的执行 过程，一般通过活动图中的泳道来绘制，这里以“申请报销”用例来说 明：（报销申请的业务用例场景活动图）其他用例的场景图也是依样画葫芦了，再搭配上业务用例规约的文字 描述（用例前置条件，后置条件，流程等等），这个报销申请用例的描 述也就基本形成了，所有的业务用例如此之后形成业务模型，然后以业 务模型为基础，撰写用户业务需求说明书。接 下来要做的就是引入计算机，降低用例粒度，进入系统模型的建 立过程。同样这里也是包括系统用例和系统用例场景，系统用例可以从 业务用例场景中推导出来，业 务用例场景一般描述为某某做什么，某 某做什么，这个某某做什么就是一个备选的系统用例，然后从备选用例

13、 中确定系统用例，分析过程如下：员工申请报销，这是一个填写报账单的过程，是通过计算机完成的， 可以直接映射成一个系统用例；部门经理审核报账单，这是通过计算机来操作决定是否通过审核，可 以直接映射成一个系统用例；部门经理说明（填写）拒绝原因，经过分析，这个备选用例其实是审 核报账单的结果之一，也就是说审核报账单中包含了说明拒绝原因这个 行为，所以取消部门经理说明（填写）拒绝原因的独立用例资格，将它 作为部门经理审核报账单的包含用例。公司主任审核报账单，公司主任说明（填写）拒绝原因同上。财务主任发放还款，这个备选用例是否能成为系统用例要看情况的， 如果财务主任是人为的发放现金或者人为的去银行汇款转

14、账，那么没有 通过计算机（意思是该系 统）进行操作，就不能算是一个系统用例； 而如果财务主任是通过系统提供的转账功能汇款的话，那么就是一个系 统用例。回顾涉众分析报告后我们确定这可以成为一个系统用例。2次审核报账单发放逐款员口瓣申请的系统用例2次审核报账单发放逐款员口瓣申请的系统用例公司主任接下来我们绘制系统用例场景，看看他们是如何通过人机交互，通过计算机来实现的，以员工申请报销为例子，通过泳道绘制用例场景图：其他系统用例的场景图绘制也是依样画葫芦了，这里就省略了。所有 系统用例和系统用例场景图绘制出来后，再配合相应的用例规则，用例 规约（前置条件，后置条件，流程等），那么完整的系统用例模型就

15、出 来了，以此为基础便可以撰写系统需求文档，即软件需求规格说明书。到此为止，用例已经全部找出来了，接着就是要进入用例实现阶段了， 因为用例只是描述了系统应该做什么，是对系统提出的设想，用例实现 的目的就是实现需求，把设想变为现实，由于我们采用的是面向对象的 方法，所以用例实现的过程就是用对象之间的交互来实现需求的过程。不少人到这一步，包括我自己，可能直接进入类设计，数据库表结构 设计了，但是经常说不清楚类是如何推导出来的，为什么是设计2个类， 为什么不是3个类？美其名曰：经验，哈哈，无非就是拍脑袋拍出 来的咯，尤其是在业务复杂的大型项目中，这种拍脑袋出来的设计估计 要经过反复修改才能满足需求。

16、现在我发现，原来从系统需求到设计 之间可以通过分析模型作为过渡，通过分析模型推导出设计模型，推导 出设计类。分型模型就是采用分析类（边界类，控制类，实体类）来实 现用例场景的一种对象模型，这个抽象层次上需求已经通过对象之间 的交互实现出来了，而又不必去关注具体的技术细节，如采用什么语言， 什么框架之类的，可能安心 的为需求到设计之间的跨越做一个桥梁。 绘制分析类图一般需求根据用例场景来推导，先一步步的分析场景中的 活动：创建新申请报账单：这是一条由外面发出的命令，需要用边界对象接 受它；展现录入新报账单界面：这是一个控制逻辑，需要有控制对象处理；输入报账单信息：这是一个人工活动，由边界接受，报

17、账单是一个实 体对象；提交申请：这是一条外界发出的指令，由边界对象接受；验证信息：这是业务规则，通过控制对象来处理；保存申请单：这是一段处理逻辑，由控制对象处理，同时，报账单作为实体对象封装了要处理的数据；发送邮件通知：这是一段处理逻辑，需要由控制对象处理；显示结果：这个是处理结果，用控制对象处理，并反映到边界对象。根据上面的分析，接下来我绘制出员工报销申请用例实现的分析类时 序图：在绘制该时序图的过程中我们得到了关键对象以及这些对象的方法，接 下来把这些对象及其方法绘制在一个图里，定义出他们的关系，就得出 了分析类静态图：（这个图其实有点小问题，就是这个矩形元素代表的是设计类而不是 分析类，

18、分析类的形状应该是绘制时序图那时候的圆形，也没有void 这个语言层次的东西，我用的建模工具是EA，不知道的是工具不支 持在分析类中绘制方法，还是我自己没找到。反正rose中是可以的）用分析类对象实现用例场景的过程就是类的推导过程，现在我们已经 得到初试的类及其方法，虽然看上去还很粗糙，但已经脱离了需求视角， 进入系统设计的视角了。这些分析类就是我们进行系统设计的基础了，分析类结合采用的具体 框架（比如SSH），架构等，就可以推导出设计类，产生设计模型了。推导设计类的过程由于要结合具体框架，可能要实现某某接口，继承 某个抽象类等原因，这里就不说了，等过段时间我再新写一篇文章来说 吧。由于我工作

19、中的项目采用SSH框架，所以我曾经疑惑觉得怎么没 有看到Action类啊，Service类呢，pojo呢，DAO呢，没看到啊！后 来才恍然醒悟，哦，原来所处的抽象层次不同，分析模型的抽象层次比 设计模型高，不涉及到具体的框架，架构，语言等实现方式，所以在这 个抽象层次上，可以不去考虑实现细节，屏蔽掉无关的信息，而专注于 通过分析类的3种对象之间的交互来实现需求，为需求到设计之间搭建 桥梁，设计模型就是在分析模型的基础上结合具体框架，架构，语言等 实现方式实例化分析模型的过程。完整而全面的分析模型就可以作为系 统概要设计文档了。其实我个人觉得，从业务模型到设计模型（中间可能还有概念模型）， 到分析模型，再到设计模型，这种建模的过程就是一个降低抽象层次和 边界粒度的过程，类似于 我们要描述一个东西，比如汽车，我们可以 这样说：站在汽车这个抽象层次上，我们看到的是车身，轮胎等边界； 降低抽象层次到车身上，我们面对的有方向盘，发动机，座位等边界； 站在发动机这个抽象层次上，我们看到的是引擎，活塞等边界。这个抽象层次可以一直延伸下去，采用这种自顶向下的方法把一个事 物描述清楚。抽象层次的好处是无论站在哪个层次上都只需要面对有限 的复杂度和结构，从而帮助我们理解清楚这个层次上的对象是如何工作 的。边界和抽象层 次是相伴的，不同的抽象层次面对的边界粒度