首先,让我们来定义什么是”用例的实现”？

我们知道在系统设计软件实践过程中通常要遵循一定的步骤或迭代，在这个迭代过程中，一般而言第一步是创建设计类图的基础版本或为初步模型，然后是开发交互图。通常情况下，会给每一个用例产生一个交互图。开发交互图是面向对象系统设计的核心，经常会使用到的是用例图、用例描述、系统顺序图和设计类图。我们称这些设计模型的最终结果为“用例的实现”。一言以蔽之，“用例的实现”指的是对每个用例的详细系统过程进行说明。

本文我们结合某省邮政行业的CRM系统的一些典型用例做实现并进行探讨。

在软件企业中，用例的实现通常会包含在某些需求文档或设计文档中，比如在软件架构设计中，所以本文也以一系列的视图来描述CRM系统的“骨架”。也许它会让你觉得CRM系统原本也可以脉络清晰，而实际上它是一份“架构设计”的文档的雏形。这些视图包括用例视图、流程视图、部署视图和实施视图。它们是用 Rose 模型表示的, 并且使用统一建模语言 (UML，Unified Modeling Language)。

1. 用例视图

对于所选择的场景集和（或）作为迭代焦点的用例集，用例视图是很重要的输入。用例视图描述那些代表了某些重要的核心功能的场景集、用例集。它还要描述那些在构架方面的、涉及范围很广（使用了许多构架元素）的场景集、用例集，或者描述那些强调或阐明了构架的某一具体的细微之处的场景集、用例集。

1.1 CRM系统中具有重要意义的用例

如上图中，是某省邮政行业CRM系统中与营销主管和营销员相关的一些用例，对于这些用例的说明如下：

• 管理营销日志
  系统用户提供自己的用户名和密码，系统对提供的信息进行审核，只有对审核通过的用户才允许进行系统操作。
• 回复营销日志
  本用例允许预算单位每个月根据自己的用款情况提出下一个月或下几个月的用款计划。
• 察看营销事务
  本用例允许国库司用户对所管预算部门的用款计划审批。
• 处理营销事务
  本用例允许国库司用户对所管预算部门的用款计划审批。

1.2 用例实现

1.2.1 管理营销日志

对于领域模型的描述，如下图：

分析模型的描述，如下图：

1.2.2 增加营销日志（主场景），如下图：

设计模型，如下图：

2 增加营销日志（主场景），如下图：

现在让我们探讨一下这些顺序图的设计规则：

• 接受每个输入消息并确定由这个输入消息产生的所有内部消息。
  确定消息的目标：需要什么消息、哪个类—目的地—需要这条消息，以及哪个类（消息源）提供这条消息。这种分析有助于理清内部消息、源对象和目的地对象。
• 在处理每个消息的时候，要辨别出受之影响的类的完整集合，即从域类图中找到需要的所有对象。在用例的前提条件和后续条件中罗列的任何类都应该包含到设计中去， 即被创建的类、创建用例对象的类、用例期间更新的类，以及提供用例需要信息的类。
• 充实消息的结构、添加迭代、正/误条件、返回值和传递参数。传递参数应该参考域类的属性。返回值和传递参数可以是属性，也可以是类中的对象。
  此时，我们还是在设计问题域类，下面我们以分层模型去看用例的实现。

2. 逻辑视图（Logic view）

逻辑视图主要支持系统的功能需求，它是系统提供给最终用户的服务。在面向对象技术中，通过抽象、封装和继承，可以用对象模型来代表逻辑视图，用类图来描述逻辑视图，以及这些主要类在服务包和子系统中的组织以及如何将子系统组织为多个层。类图也用于表示类的存在以及类与类之间的相互关系，它是从系统构成的角度来描述当前的系统，即一系列用例实现的构成。

包和子系统的分层模型描述如下图：

软件设计原则中的对象职责用于定义每一层的逻辑任务，我们总结出每层的主要职责和任务如下。

（1）表示层

表示层包含所有表示用户看到的应用程序屏幕的边界类。该层的职责是：

• 提供友好、方便的用户界面
• 收集、预处理用户的输入信息
• 显示数据字段
• 编辑并校验输入数据的合法性
• 格式化处理结果
• 将输入数据向前传递给请求控制层

展示的方式支持浏览器方式、应用程序方式。

（2）请求控制层

请求控制层包括代表驱动应用程序行为的用例管理器的所有控制器类。该层代表从客户机到中间层的边界。该层的职责是：

• 提供系统统一入口
• 接收并分发用户请求
• 将用户请求转换为业务层数据对象 （HttpRequest、XML<——>VO）
• 错误消息格式化、转换
• 管理用户session
• 安全认证、记录日志等通用处理

请求控制层要支持多种通讯协议，即HTTP、RMI等。

（3）应用层

应用层包括应用程序领域内的业务处理类，该层表示业务服务层的边界和门面。该层的职责是：

• 提供业务服务门面
• 管理事务
• 管理缓存

对外提供的类型包括：普通JAVA类（POJO）、EJB、RMI服务、Web Service等。

（4）领域层

领域层包括表示应用程序领域内“事物”的所有实体类，这些实体类驻留在服务器上，并利用数据访问类和基础服务类来协助完成它们的职责。领域层的职责是：

• 管理业务逻辑对象；
• 提供核心业务逻辑实现。

（5）数据访问层

数据访问层位于对象业务层和底层关系型数据库之间，负责将对象映射到关系型数据库中，主要职责是：

• 负责对象的持久化；
• 提供数据访问接口。

（6）基础复用类

包括平台中提供基础服务的类。

在基础服务类中，主要提供了大部份企业应用都需要用到的类库：

• 异常处理
• 日志处理
• 组织结构
• 用户权限
• 数据字典
• 功能模块配置
• 数据访问

本文初步探讨了用例的实现和系统架构视图的之间的关系，我们知道不论是用例实现还是架构设计本身都是一个很大的话题，都可以作更深入的探讨，而如何把二者有机地结合起来, 也是值得我们去思考的问题。