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

面向对象分析过程案例实战这是我在csdn博客的第2篇技术文章，本来按原计划是要简介开源ajax框架buffalo的第2部分，即js<>java的序列化，这里面波及不少设计模式的运用和JAVASE知识，代码精简，比较精彩。不过由于个人时间有限，在抉择之后，打算先写一篇有关面向对象分析的文章，也算是对自己过去1年多在这方面学习的总结。我选了比较简朴且大家也比较熟悉的案例来分析，案例虽然简朴，不过基本的分析措施和推导过程还是一致的，我重要想讲的是原始需求是怎么通过层层分析和推导而形成最终可执行代码的，限于自己的个人能力，假如有谬论和错误之处，还望同行多指教和协助，共同进步。原始需求描述如下：某企业鉴于业务和员工的迅速发展，为了提高整体工作效率，企业准备开发一套员工报账系统，取代本来的人工处理方式，愈加以便的服务于员工平常的账务操作。财务部门可以通过账务系统定期向各部门负责人反应账务记录状况，并设置和维护有关额度准则。系统应当具有基于先进技术的操作界面。这段描述里包括的业务目的大体有二：1.

为员工提供账务的自动化办理，提高办事效率，以便员工。2.

以便财务部门管理好账务信息。这些业务目的一般在项目的招标书里均有有关的描述，也可以由开发方整顿得出。之因此这里要把业务目的列出来，是由于我所采用的措施里，业务目的是进行需求分析的第一步，接下来的推导过程和业务模型的建立都是根据业务目的开始的。整理出了业务目的后，接下来先不要一头扎进详细的业务流程和业务细节之中去，应当先把涉众找出来，整顿出一份涉众分析汇报，涉众就是和这个项目有关的人。也不要就去考虑技术实现细节，要用什么先进的技术，界面怎样美观，性能怎样优越等等，虽然这些确实重要，不过相比起来，忠实的实现涉众的期望，满足涉众的需求才是最为重要，也是一种项目成败的关键。在实际的项目中，我们可以通过需求调研找出有关的涉众，这里我就直接列出本案例的涉众分析汇报：员工：企业的正式录取雇员；期望：通过网上办理账务业务申请，计算机控制流程。部门经理：部门负责人，负责审核员工提交的申请；期望：以便审核操作，通过计算机替代本来的手工审核方式。企业主任：企业负责人，负责2次审核员工提交的申请；期望：以便审核操作，通过计算机替代本来的手工审核方式，界面友好易用。财务主任：企业财务部门负责人，负责发放报账款项；期望：通过计算机转账的方式替代本来的人为付款方式。以上的涉众分析汇报是很简朴的了，在实际稍微复杂些的项目中要下功夫好好整顿清晰一份完整的文档才是，由于接下来的业务用例获取工作也是在此基础上展开的。这里先罗嗦下业务用例和平时开发中的我们开发人员从项目经理或者需求人员手中拿到的需求文档中的用例什么区别。按我个人理解来说后者是系统用例，两者的关键区别在于抽象层次和用例粒度的不一样，系统用例是以人与计算机的每次交互为单位的，而业务用例则是在较高的层次上用于确立业务需求范围和描述系统功能性需求的。也就是说我们在描述业务用例的时候，可以不用去考虑详细和计算机有关的实现环节和细节，从而减少我们人脑需要考虑的复杂度，专注于确立业务需求范围，抽象就是面向对象的优势所在，不用像过程化思维那样通盘考虑，由于人脑能接受的信息量是有限的。系统用例一般是从业务用例中推导出来的，本文之后会有有关这方面的推导过程。不懂得有没跑题，罗嗦了一段，目前回来，分析下本案例中的业务用例获取工作。说到用例，就必须结合边界和业务主角，否则用例的粒度就会出现问题，由于用例是以参与者（业务主角）为关键的，是由业务主角发起的以到达业务主角完整目的为原则的。要获取用例就必须先得出边界，边界有了，那么边界外的业务主角就有了，那么业务主角对这个边界内的目的就是用例了。用UML表达如下：我们先来看看一种小例子，没有引入边界的概念对获取用例有什么影响，例如我去食堂就餐，要先领取餐具，然后点菜，打菜的阿姨帮忙盛菜，接着我刷卡付款，去盛饭和汤，之后是找座位，最终才开始就餐。那么领取餐具，点菜，刷卡付款之类的算是一种用例吗？说算也算，说不算也不算。由于这要根据边界来确定的，我们都懂得用例是以主角发起的以完毕主角的完整目的为原则的。这里的主角就是我本人，要确定我的目的就必须先确定边界，例如以整个食堂为边界，那么我去食堂的目的就是就餐，就餐才是我的完整目的，而其他诸如领取餐具，点菜，刷卡付款之类的都不是我去食堂的目的，这些只是我完毕就餐的环节而已，但假如把边界粒度减少到食堂的内部，那么这个时候领取餐具，刷卡付款之类的也是一种用例了，虽然都是用例，不过和就餐这个用例的粒度是不一样的，由于他们边界所在的抽象层次不一样。因此要描述用例就必须先划分出边界来，主角站在边界外对这个边界提出目的，一种目的就是一个用例，否则在描述系统的时候就会出现如我去食堂的目的是刷卡付款这样的笑话来，当然了，除非我去食堂的目的真的只是为了付款。回到本文的案例中来，开始进行获取业务用例的分析，刚刚说了，要获取用例必须先确定好边界，那么怎么确定边界呢？这个时候我们前面划分业务目的的作用就体现出来了，我们可以以每个业务目的为一种边界，由于所有业务目的汇集起来就表达到达了系统建设目的，而针对每个业务目的定义的边界，明确了哪些涉众与这一业务目的有关，他们作为业务主角站在这一边界外提出他们的期望，这些期望作为用例都是为实现这一业务目的服务的，获取业务用例的方向就明确了（不符合这一业务目的的期望则不被采纳）。如上图，边界和业务主角都已经有了，接着就是找出用例了，我以员工账务服务边界为例，根据涉众分析汇报和客户访谈（这个在实际项目中需要好好历练的，我觉得要有技巧引导客户，还要有较强的总结概括能力吧）得出的。假定我从与客户访谈的成果中得出员工对这个系统的期望和目的有通过计算机申请报销业务，申请借款业务，这两个期望都是与员工账务服务这个特定的业务目的有关的，因此可以作为业务用例被纳入到员工账务服务边界之中。假如假设员工也可以参与管理账务信息，那么得出的员工对系统的期望就不止这两个，不过度析的时候要注意与员工账务服务这一业务目的有关的期望只有申请报销业务和申请借款业务两个，其他的期望是与管理账务信息这个业务目的有关，应当被划分到管理账务信息边界中去。有的人也许会问了，貌似部门经理也有对员工账务服务边界有奉献啊，不是有参与审核吗，为啥部门经理审核账单就不能算一种业务用例呢？之因此会出现这个疑惑和误区还是由于没有分清晰边界导致的。由于对于员工账务服务边界来说，处在该边界的之外的业务主角只有员工，而部门经理，企业主任，财务主任都是在这个边界之内的，他们的工作都只是完毕业务主角提出的业务用例的一种环节，在这里他们作为业务工人无权提出业务用例，他们的职责可以在绘制用例场景活动图的时候通过泳道体现出来。接下来是建立业务模型阶段，建立业务模型的目的是为了通过UML这种对象语言将现实世界描述出来，是我们为了理解客户的业务并和客户到达业务上的理解而建立的模型（我们的系统将要面对的问题领域就是这个样子），它不需要考虑计算机环境，相对于系统模型来说，他没有加入计算机元素，是对现实业务的一种直观的理解。我们平时开发时接触的《软件需求规格阐明书》来源于系统模型，他描述的是软件系统要实现的功能范围，和计算机环境亲密有关，软件需求只是整个需求过程的一部分，可以从业务需求中推导出来的。业务模型重要包括业务用例，业务用例实现场景，业务规则，业务用例规约等等，限于个人掌握程度及个人精力所限，本案例中我重要讲述业务用例和业务用例场景图，业务用例场景重要是描述业务用例的执行过程，一般通过活动图中的泳道来绘制，这里以“申请报销”用例来阐明：

（报销申请的业务用例场景活动图）其他用例的场景图也是依样画葫芦了，再搭配上业务用例规约的文字描述（用例前置条件，后置条件，流程等等），这个报销申请用例的描述也就基本形成了，所有的业务用例如此之后形成业务模型，然后以业务模型为基础，撰写顾客业务需求阐明书。接下来要做的就是引入计算机，减少用例粒度，进入系统模型的建立过程。同样这里也是包括系统用例和系统用例场景，系统用例可以从业务用例场景中推导出来，业务用例场景一般描述为某某做什么，某某做什么，这个某某做什么就是一种备选的系统用例，然后从备选用例中确定系统用例，分析过程如下：员工申请报销，这是一种填写报账单的过程，是通过计算机完毕的，可以直接映射成一种系统用例；部门经理审核报账单，这是通过计算机来操作决定与否通过审核，可以直接映射成一种系统用例；部门经理阐明（填写）拒绝原因，通过度析，这个备选用例其实是审核报账单的成果之一，也就是说审核报账单中包括了阐明拒绝原因这个行为，因此取消部门经理阐明（填写）拒绝原因的独立用例资格，将它作为部门经理审核报账单的包括用例。企业主任审核报账单，企业主任阐明（填写）拒绝原因同上。财务主任发放还款，这个备选用例与否能成为系统用例要看状况的，假如财务主任是人为的发放现金或者人为的去银行汇款转账，那么没有通过计算机（意思是该系统）进行操作，就不能算是一种系统用例；而假如财务主任是通过系统提供的转账功能汇款的话，那么就是一种系统用例。回忆涉众分析汇报后我们确定这可以成为一种系统用例。

接下来我们绘制系统用例场景，看看他们是怎样通过人机交互，通过计算机来实现的，以员工申请报销为例子，通过泳道绘制用例场景图：

其他系统用例的场景图绘制也是依样画葫芦了，这里就省略了。所有系统用例和系统用例场景图绘制出来后，再配合对应的用例规则，用例规约（前置条件，后置条件，流程等），那么完整的系统用例模型就出来了，以此为基础便可以撰写系统需求文档，即软件需求规格阐明书。到此为止，用例已经所有找出来了，接着就是要进入用例实现阶段了，由于用例只是描述了系统应当做什么，是对系统提出的设想，用例实现的目的就是实现需求，把设想变为现实，由于我们采用的是面向对象的措施，因此用例实现的过程就是用对象之间的交互来实现需求的过程。不少人到这一步，包括我自己，也许直接进入类设计，数据库表构造设计了，不过常常说不清晰类是怎样推导出来的，为何是设计2个类，为何不是3个类？美其名曰：经验，哈哈，无非就是拍脑袋拍出来的咯，尤其是在业务复杂的大型项目中，这种拍脑袋出来的设计估计要通过反复修改才能满足需求。目前我发现，本来从系统需求到设计之间可以通过度析模型作为过渡，通过度析模型推导出设计模型，推导出设计类。分型模型就是采用分析类（边界类，控制类，实体类）来实现用例场景的一种对象模型，这个抽象层次上需求已经通过对象之间的交互实现出来了，而又不必去关注详细的技术细节，如采用什么语言，什么框架之类的，也许安心的为需求到设计之间的跨越做一种桥梁。绘制分析类图一般需求根据用例场景来推导，先一步步的分析场景中的活动：创立新申请报账单：这是一条由外面发出的命令，需要用边界对象接受它；展现录入新报账单界面：这是一种控制逻辑，需要有控制对象处理；输入报账单信息：这是一种人工活动，由边界接受，报账单是一种实体对象；提交申请：这是一条外界发出的指令，由边界对象接受；验证信息：这是业务规则，通过控制对象来处理；保留申请单：这是一段处理逻辑，由控制对象处理，同步，报账单作为实体对象封装了要处理的数据；发送邮件告知：这是一段处理逻辑，需要由控制对象处理；显示成果：这个是处理成果，用控制对象处理，并反应到边界对象。根据上面的分析，接下来我绘制出员工报销申请用例实现的分析类时序图：

在绘制该时序图的过程中我们得到了关键对象以及这些对象的措施，接下来把这些对象及其措施绘制在一种图里，定义出他们的关系，就得出了分析类静态图：

（这个图其实有点小问题，就是这个矩形元素代表的是设计类而不是分析类，分析类的形状应当是绘制时序图那时候的圆形，也没有void这个语言层次的东西，我用的建模工具是EA，不懂得的是工具不支持在分析类中绘制措施，还是我自己没找到。反正rose中是可以的）用分析类对象实现用例场景的过程就是类的推导过程，目前我们已经得到初试的类及其措施，虽然看上去还很粗糙，但已经脱离了需求视角，进入系统设计的视角了。这些分析类就是我们进行系统设计的基础了，分析类结合采用的详细框架（例如SSH），架构等，就可以推导出设计类，产生设计模型了。推导设计类的过程由于要结合详细框架，也许要实现某某接口，继承某个抽象类等原因，这里就不说了，等过段时间我再新写一篇文章来说吧。由于我工作中的项目采用SSH框架，因此我曾经疑惑觉得怎么没有看到Action类啊，Service类呢，pojo呢，DAO呢，没看到啊！后来才恍然醒悟，哦，本来所处的抽象层次不一样，分析模型的抽象层次比设计模型高，不波及到详细的框架，架构，语言等实现方式，因此在这个抽象层次上，可以不去考虑实现细节，屏蔽掉无关的信息，而专注于通过度析类的3种对象之间的交互来实现需求，为需求到设计之间搭建桥梁，设计模型就是在分析模型的基础上结合详细框架，架构，语言等实现方式实例化分析模型的过程。完整而全面的分析模型就可以作为系统概要设计文档了。其实我个人觉得，从业务模型到设计模型（中间也许尚有概念模型），到分析模型，再到设计模型，这种建模的过程就是一种减少抽象层次和边界粒度的过程，类似于我们要描述一种东西，例如汽车，我们可以这样说：站在汽车这个抽象层次上，我们看到的是车身，轮胎等边界；减少抽象层次到车身上，我们面对的有方向盘，发动机，座位等边界；站在发动机这个抽象层次上，我们看到的是引擎，活塞等边界。。。。。。。。这个抽象层次可以一直延伸下去，采用这种自顶向下的措施把一个事物描述清晰。抽象层次的好处是无论站在哪个层次上都只需要面对有限的复杂度和构造，从而协助我们理解清晰这个层次上的对象是怎样工作的。边界和抽象层次是相伴的，不一样的抽象层次面对的边界粒度就不一样。编