其他系统用例的场景图绘制也是依样画葫芦了，这里就省略了。所有系统用例和系统用例场景图绘制出来后，再配合相应的用例规则，用例规约（前置条件，后置条件，流程等），那么完整的系统用例模型就出来了，以此为基础便可以撰写系统需求文档，即软件需求规格说明书。

到此为止，用例已经全部找出来了，接着就是要进入用例实现阶段了，因为用例只是描述了系统应该做什么，是对系统提出的设想，用例实现的目的就是实现需求，把设想变为现实，由于我们采用的是面向对象的方法，所以用例实现的过程就是用对象之间的交互来实现需求的过程。

不少人到这一步，包括我自己，可能直接进入类设计，数据库表结构设计了，但是经常说不清楚类是如何推导出来的，为什么是设计2个类，为什么不是3个类 ？ 美其名曰：经验，哈哈，无非就是拍脑袋拍出来的咯，尤其是在业务复杂的大型项目中，这种拍脑袋出来的设计估计要经过反复修改才能满足需求。现在我发现，原来从系统需求到设计之间可以通过分析模型作为过渡，通过分析模型推导出设计模型，推导出设计类。分型模型就是采用分析类（边界类，控制类，实体类）来实现用例场景的一种对象模型，这个抽象层次上需求已经通过对象之间的交互实现出来了，而又不必去关注具体的技术细节，如采用什么语言，什么框架之类的，可能安心的为需求到设计之间的跨越做一个桥梁。绘制分析类图一般需求根据用例场景来推导，先一步步的分析场景中的活动：

创建新申请报账单：这是一条由外面发出的命令，需要用边界对象接受它；

 展现录入新报账单界面：这是一个控制逻辑，需要有控制对象处理；

输入报账单信息：这是一个人工活动，由边界接受，报账单是一个实体对象；

提交申请：这是一条外界发出的指令，由边界对象接受；

验证信息：这是业务规则，通过控制对象来处理；

保存申请单：这是一段处理逻辑，由控制对象处理，同时，报账单作为实体对象封装了要处理的数据；

发送邮件通知：这是一段处理逻辑，需要由控制对象处理；

显示结果：这个是处理结果，用控制对象处理，并反映到边界对象。

根据上面的分析，接下来我绘制出员工报销申请用例实现的分析类时序图：

出处：CSDN
责任编辑：bluehearts

上一页 面向对象分析过程案例实战 [4] 下一页 面向对象分析过程案例实战 [6]

◎进入论坛网络编程版块参加讨论