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

面向对象分析过程案例实战
2010/08/15/5813667.aspx
这是我在csdn博客的第2篇技术文章，本来按原计划是要介绍开源ajax框架buffalo的第2部分，即js<>java的序列化，这里面涉及不少设计模式的运用和JAVASE知识，代码精简，比较精彩。但是由于个人时间有限，在抉择之后，打算先写一篇关于面向对象分析的文章，也算是对自己过去1年多在这方面学习的总结。我选了比较简单且大家也比较熟悉的案例来分析，案例虽然简单，但是基本的分析方法和推导过程还是一致的，我主要想讲的是原始需求是怎么通过层层分析和推导而形成最后可执行代码的，限于自己的个人能力，如果有谬论和错误之处，还望同行多指教和帮助，共同进步。
原始需求描述如下：某公司鉴于业务和员工的快速发展，为了提升整体工作效率，公司准备开发一套员工报账系统，取代原来的人工处理方式，更加方便的服务于员工日常的账务操作。财务部门能够通过账务系统定期向各部门负责人反映账务统计情况，并设置和维护相关额度准则。系统应该具有基于先进技术的操作界面。
这段描述里包含的业务目标大致有二：
1.为员工提供账务的自动化办理，提高办事效率，方便员工。
2.方便财务部门管理好账务信息。
这些业务目标一般在项目的招标书里都有相关的描述，也可以由开发方整理得出。之所以这里要把业务目标列出来，是因为我所采取的方法里，业务目标是进行需求分析的第一步，接下来的推导过程和业务模型的建立都是根据业务目标开始的。
整理出了业务目标后，接下来先不要一头扎进具体的业务流程和业务细节之中去，应该先把涉众找出来，整理出一份涉众分析报告，涉众就是和这个项目相关的人。也不要就去考虑技术实现细节，要用什么先进的技术，界面如何美观，性能如何优越等等，虽然这些确实重要，但是相比起来，忠实的实现涉众的期望，满足涉众的需求才是最为重要，也是一个项目成败的关键。在实际的项目中，我们可以通过需求调研找出相关的涉众，这里我就直接列出本案例的涉众分析报告：
员工：公司的正式录用雇员；期望：通过网上办理账务业务申请，计算机控制流程。
部门经理：部门负责人，负责审核员工提交的申请；期望：方便审核操作，通过计算机代替原来的手工审核方式。
公司主任：公司负责人，负责2次审核员工提交的申请；期望：方便审核操作，通过计算机代替原来的手工审核方式，界面友好易用。
财务主任：公司财务部门负责人，负责发放报账款项；期望：通过计算机转账的方式替代原来的人为付款方式。
以上的涉众分析报告是很简单的了，在实际稍微复杂些的项目中要下功夫好好整理清楚一份完整的文档才是，因为接下来的业务用例获取工作也是在此基础上展开的。
这里先罗嗦下业务用例和平时开发中的我们开发人员从项目经理或者需求人员手中拿到的需求文档中的用例什么区别。按我个人理解来说后者是系统用例，两者的关键区别在于抽象层次和用例粒度的不同，系统用例是以人与计算机的每次交互为单位的，而业务用例则是在较高的层次上用于确立业务需求范围和描述系统功能性需求的。也就是说我们在描述业务用例的时候，可以不用去考虑具体和计算机相关的实现步骤和细节，从而降低我们人脑需要考虑的复杂度，专注于确立业务需求范围，抽象就是面向对象的优势所在，不用像过程化思维那样通盘考虑，因为人脑能接受的信息量是有限的。系统用例一般是从业务用例中推导出来的，本文之后会有关于这方面的推导过程。
不知道有没跑题，罗嗦了一段，现在回来，分析下本案例中的业务用例获取工作。说到用例，就必须结合边界和业务主角，否则用例的粒度就会出现问题，因为用例是以参与者（业务主角）为核心的，是由业务主角发起的以达到业务主角完整目标为标准的。要获取用例就必须先得出边界，边界有了，那么边界外的业务主角就有了，那么业务主角对这个边界内的目标就是用例了。用UML表示如下：

我们先来看看一个小例子，没有引入边界的概念对获取用例有什么影响，比如我去食堂就餐，要先领取餐具，然后点菜，打菜的阿姨帮忙盛菜，接着我刷卡付款，去盛饭和汤，之后是找座位，最后才开始就餐。那么领取餐具，点菜，刷卡付款之类的算是一个用例吗？说算也算，说不算也不算。因为这要根据边界来确定的，我们都知道用例是以主角发起的以完成主角的完整目标为标准的。这里的主角就是我本人，要确定我的目标就必须先确定边界，比如以整个食堂为边界，那么我去食堂的目的就是就餐，就餐才是我的完整目标，而其他诸如领取餐具，点菜，刷卡付款之类的都不是我去食堂的目的，这些只是我完成就餐的步骤而已，但如果把边界粒度降低到食堂的内部，那么这个时候领取餐具，刷卡付款之类的也是一个用例了，虽然都是用例，但是和就餐这个用例的粒度是不同的，因为他们边界所在的抽象层次不同。所以要描述用例就必须先划分出边界来，主角站在边界外对这个边界提出目标，一个目标就是一个用例，否则