对象分析过程案例实战

原本按原计划是要介绍开源 ajax 框架 buffalo 第 2 局部， 这是 csdn 博客的第 2 篇技术文章。即 js<>java 序列化，这里面涉及不少设计模式的运用和 JA VA SE 知识，代码精简，比较精彩。但是由于个人时间有限，抉择之后，打算先写一篇关于面向对象分析的文章，也算是对自己过去 1 年多在这方面学习的总结。选了比较简单且大家也比较熟悉的案例来分析，案例虽然简单，但是基本的分析方法和推导过程还是一致的主要想讲的原始需求是怎么通过层层分析和推导而形成最后可执行代码的限于自己的个人能力，如果有谬论和错误之处，还望同行多指教和帮助，共同进步。

原始需求描述如下：某公司鉴于业务和员工的快速发展，为了提升整体工作效率，公司准备开发一套员工报账系统，取代原来的人工处置方式，更加方便的服务于员工日常的账务操作。财务部门能够通过账务系统定期向各部门负责人反映账务统计情况，并设置和维护相关额度准则。系统应该具有基于先进技术的操作界面。

这段描述里包含的业务目标大致有二：

1. 为员工提供账务的自动化操持，提高办事效率，方便员工。
2. 方便财务部门管理好账务信息。

这些业务目标一般在项目的招标书里都有相关的描述，也可以由开发方整理得出。之所以这里要把业务目标列出来，因为我所采取的方法里，业务目标是进行需求分析的第一步，接下来的推导过程和业务模型的建立都是根据业务目标开始的

整理出了业务目标后，接下来先不要一头扎进具体的业务流程和业务细节之中去，应该先把涉众找出来，整理出一份涉众分析报告，涉众就是和这个项目相关的人。也不要就去考虑技术实现细节，要用什么先进的技术，界面如何美观，性能如何优越等等，虽然这些确实重要，但是相比起来，忠实的实现涉众的期望，满足涉众的需求才是最为重要，也是一个项目成败的关键。实际的项目中，可以通过需求调研找出相关的涉众，这里我就直接列出本案例的涉众分析报告：

员工：公司的正式录用雇员； 期望：通过网上料理账务业务申请，计算机控制流程。

部门经理：部门负责人，负责审核员工提交的申请；期望：方便审核操作，通过计算机代替原来的手工审核方式。

公司主任：公司负责人，负责 2 次审核员工提交的申请；期望：方便审核操作，通过计算机代替原来的手工审核方式，界面友好易用。

财务主任：公司财务部门负责人，负责发放报账款项； 期望：通过计算机转账的方式替代原来的人为付款方式。

以上的涉众分析报告是很简单的实际稍微复杂些的项目中要下功夫好好整理清楚一份完整的文档才是因为接下来的业务用例获取工作也是此基础上展开的

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

不知道有没跑题，罗嗦了一段，现在回来，分析下本案例中的业务用例获取工作。说到用例，就必需结合边境和业务主角，否则用例的粒度就会出现问题，因为用例是以参与者（业务主角）为核心的由业务主角发起的以达到业务主角完整目标为标准的要获取用例就必需先得出边界，边境有了那么边境外的业务主角就有了那么业务主角对这个边境内的目标就是用例了用 UML 表示如下：