通过真实项目来分析-面向对象分析过程
面向对象分析设计过程中的核心的项目中类分析，一般来说获得分析类有三种途径：1、脑力风暴；2、词性分析法；3、CRC分析法（候选类、职责、协作分析法）。 下面我就从这三个方面来谈一谈如何进行系统的面向对象分析。
1、脑力风暴： 所谓脑力风暴是指我们看到需求或模型后，感觉到系统中应该存在哪些分析类。事实上，这个方法就是利用了我们的感觉与经验；
2、词性分析法： 所谓词性分析法，是指我们根据需求描述或模型中的词汇进行分析，在分析过程中，按词性进行类、属性、方法的划分。 比如《面向对象分析过程案例实战》这篇博文中提到的申请报销这个需求，它的描述可以是这样： 内部员工向部门经理提出报销申请，部门经理进行审批，如批准则报销单再经公司经理进行审核，否则申请作废；公司经理可以审核通过，也可以作废此申请，一旦审核通过，内部员工就可以通过财务主任进行报销。 那么，在这个需求中，我们可以获得以下的名词：内部员工、报销申请单、部门经理、公司经理、财务主任；动词有：申请、审批、审核、作废、报销。 对于这么词汇，我们可以把名词作为类或属性，把动词作为方法。当然，这些内容会进一步得到确认，看这些内容对我们的目标系统是否有用，是否是分析类或类方法；
3、CRC分析法（候选类、职责、协作分析法）： CRC分析法也是一个简单易行的分析方法。我们通过对那些可能的类进行职责与协作的分析，进一步确认系统中的分析类及其属性、方法。CRC分析法要求我们对每一个候选类做一个卡片，在卡片上对这个类进行描述，在描述的下面写上这个类的职责，在背面写出与这个类有协作关系的其它类及协作关系。当然，在进行CRC分析时，会有一些具体的措施使我们获得的分析类更完整，让分析类的分布更合理。
这三种方法还不足以让我们获得比较合适的分析类。在分析过程中，我们还会对照面向对象的原则进行抽象。 另外自底而上的分析方法，不过这不是仅有的方法，可能还要根据实际项目，采用自顶向下，或两者结合，或从中间向顶向底的分析方法。
下面就通过一个很典型的项目来分析：
项目的原型如下：某公司鉴于业务和员工的快速发展，为了提升整体工作效率，公司准备开发一套员工报账系统，取代原来的人工处理方式，更加方便的服务于员工日常的账务操作。财务部门能够通过账务系统定期向各部门负责人反映账务统计情况，并设置和维护相关额度准则。系统应该具有基于先进技术的操作界面。
这段描述里包含的业务目标大致有二：
1.为员工提供账务的自动化办理，提高办事效率，方便员工。
2. 方便财务部门管理好账务信息。
这些业务目标一般在项目的招标书里都有相关的描述，也可以由开发方整理得出。之所以这里要把业务目标列出来，是因为我所采取的方法里，业务目标是进行需求分析的第一步，接下来的推导过程和业务模型的建立都是根据业务目标开始的。
整理出了业务目标后，接下来先不要一头扎进具体的业务流程和业务细节之中去，应该先把涉众找出来，整理出一份涉众分析报告，涉众就是和这个项目相关的人。也不要就去考虑技术实现细节，要用什么先进的技术，界面如何美观，性能如何优越等等，虽然这些确实重要，但是相比起来，忠实的实现涉众的期望，满足涉众的需求才是较为重要，也是一个项目成败的关键。在实际的项目中，我们可以通过需求调研找出相关的涉众，这里我就直接列出本案例的涉众分析报告：
员工：公司的正式录用雇员； 期望：通过网上办理账务业务申请，计算机控制流程。
部门经理：部门负责人，负责审核员工提交的申请；期望：方便审核操作，通过计算机代替原来的手工审核方式。
公司主任：公司负责人，负责2次审核员工提交的申请；期望：方便审核操作，通过计算机代替原来的手工审核方式，界面友好易用。
财务主任：公司财务部门负责人，负责发放报账款项； 期望：通过计算机转账的方式替代原来的人为付款方式。
我们开始分析下本案例中的业务用例获取工作。说到用例，就必须结合边界和业务主角，否则用例的粒度就会出现问题，因为用例是以参与者（业务主角）为核心的，是由业务主角发起的以达到业务主角完整目标为标准的。要获取用例就必须先得出边界，边界有了，那么边界外的业务主角就有了，那么业务主角对这个边界内的目标就是用例了。
我们先来看看一个小例子，没有引入边界的概念对获取用例有什么影响，比如我去食堂就餐，要先领取餐具，然后点菜，打菜的阿姨帮忙盛菜，接着我刷卡付款，去盛饭和汤，之后是找座位，较后才开始就餐。那么领取餐具，点菜，刷卡付款之类的算是一个用例吗 ？说算也算，说不算也不算。因为这要根据边界来确定的，我们都知道用例是以主角发起的以完成主角的完整目标为标准的。这里的主角就是我本人，要确定我的目标就必须先确定边界，比如以整个食堂为边界，那么我去食堂的目的就是就餐，就餐才是我的完整目标，而其他诸如领取餐具，点菜，刷卡付款之类的都不是我去食堂的目的，这些只是我完成就餐的步骤而已，但如果把边界粒度降低到食堂的内部，那么这个时候领取餐具，刷卡付款之类的也是一个用例了，虽然都是用例，但是和就餐这个用例的粒度是不同的，因为他们边界所在的抽象层次不同。所以要描述用例就必须先划分出边界来，主角站在边界外对这个边界提出目标，一个目标就是一个用例，否则在描述系统的时候就会出现如我去食堂的目的是刷卡付款这样的笑话来，当然了，除非我去食堂的目的真的只是为了付款.
这个项目中，要去找业务主角和边界：员工，财务主任，员工信息边界，财务信息边界。那我们就可以找用例了。我以员工账务服务边界为例，根据涉众分析报告和客户访谈（这个在实际项目中需要好好历练的，我觉得要有技巧引导客户，还要有较强的总结概括能力吧）得出的。假定我从与客户访谈的结果中得出员工对这个系统的期望和目标有通过计算机申请报销业务，申请借款业务，这两个期望都是与员工账务服务这个特定的业务目标有关的，所以可以作为业务用例被纳入到员工账务服务边界之中。如果假设员工也可以参与管理账务信息，那么得出的员工对系统的期望就不止这两个，但是分析的时候要注意与员工账务服务这一业务目标相关的期望只有申请报销业务和申请借款业务两个，其他的期望是与管理账务信息这个业务目标有关，应当被划分到管理账务信息边界中去。 接下来是建立业务模型阶段，建立业务模型的目的是为了通过UML这种对象语言将现实世界描述出来，是我们为了理解客户的业务并和客户达成业务上的理解而建立的模型（我们的系统将要面对的问题领域就是这个样子），它不需要考虑计算机环境，相对于系统模型来说，他没有加入计算机元素，是对现实业务的一种直观的理解。我们平时开发时接触的《软件需求规格说明书》来源于系统模型，他描述的是软件系统要实现的功能范围，和计算机环境密切相关，软件需求只是整个需求过程的一部分，可以从业务需求中推导出来的。
务模型主要包括业务用例，业务用例实现场景，业务规则，业务用例规约等等，限于个人掌握程度及个人精力所限，本案例中我主要讲述业务用例和业务用例场景图，业务用例场景主要是描述业务用例的执行过程，一般通过活动图中的泳道来绘制，这里以“申请报销”用例来说明：
员工报销申请用例： 员工：申请报销，部门经理 第一审核，公司主任 再次审核，财务主任是发放报销费用。
到此为止，用例已经全部找出来了，接着就是要进入用例实现阶段了，因为用例只是描述了系统应该做什么，是对系统提出的设想，用例实现的目的就是实现需求，把设想变为现实，由于我们采用的是面向对象的方法，所以用例实现的过程就是用对象之间的交互来实现需求的过程。不少人到这一步，包括我自己，可能直接进入类设计，数据库表结构设计了，但是经常说不清楚类是如何推导出来的，为什么是设计2个类，为什么不是3个类 ？ 美其名曰：经验，哈哈，无非就是拍脑袋拍出来的咯，尤其是在业务复杂的大型项目中，这种拍脑袋出来的设计估计要经过反复修改才能满足需求。现在我发现，原来从系统需求到设计之间可以通过分析模型作为过渡，通过分析模型推导出设计模型，推导出设计类。分型模型就是采用分析类（边界类，控制类，实体类）来实现用例场景的一种对象模型，这个抽象层次上需求已经通过对象之间的交互实现出来了，而又不必去关注具体的技术细节，如采用什么语言，什么框架之类的，可能安心的为需求到设计之间的跨越做一个桥梁。绘制分析类图一般需求根据用例场景来推导，先一步步的分析场景中的活动：
创建新申请报账单：这是一条由外面发出的命令，需要用边界对象接受它；
展现录入新报账单界面：这是一个控制逻辑，需要有控制对象处理；
输入报账单信息：这是一个人工活动，由边界接受，报账单是一个实体对象；
提交申请：这是一条外界发出的指令，由边界对象接受；
验证信息：这是业务规则，通过控制对象来处理；
保存申请单：这是一段处理逻辑，由控制对象处理，同时，报账单作为实体对象封装了要处理的数据；
发送邮件通知：这是一段处理逻辑，需要由控制对象处理；
显示结果：这个是处理结果，用控制对象处理，并反映到边界对象。根据上面的分析，接下来我绘制出员工报销申请用例实现的分析类时序图。
在绘制该时序图的过程中我们得到了关键对象以及这些对象的方法，接下来把这些对象及其方法绘制在一个图里，定义出他们的关系，就得出了分析类静态图如下：
这些分析类就是我们进行系统设计的基础了，分析类结合采用的具体框架（比如SSH），架构等，就可以推导出设计类，产生设计模型了。
推导设计类的过程由于要结合具体框架，可能要实现某某接口，继承某个抽象类等原因，这里就不说了，等过段时间我再新写一篇文章来说吧。由于我工作中的项目采用 SSH框架，所以我曾经疑惑觉得怎么没有看到 Action 类啊，Service类呢， pojo呢，DAO呢，没看到啊！后来才恍然醒悟，哦，原来所处的抽象层次不同，分析模型的抽象层次比设计模型高，不涉及到具体的框架，架构，语言等实现方式，所以在这个抽象层次上，可以不去考虑实现细节，屏蔽掉无关的信息，而专注于通过分析类的3种对象之间的交互来实现需求，为需求到设计之间搭建桥梁，设计模型就是在分析模型的基础上结合具体框架，架构，语言等实现方式实例化分析模型的过程。完整而全面的分析模型就可以作为系统概要设计文档了。
