没头没尾--项目开发笔记：如何编写最外层用例?!

标题：没头没尾--项目开发笔记：如何编写最外层用例?!

关键词：结构式的开发，用例驱动开发

02月14号：街上到处都是拿着鲜花的小丫头，比过年都热闹！！

 

项目将要进入最后的实施阶段，各个子系统也开始了扫尾工作。由于项目中出现的问题很多都是由于设计中的原因，与项目小组的成员进行讨论的时候有时候还是会不自觉的回到项目最初我们有什么工作没有做好，从而从项目中得到更多的经验。

 

如何编写最外层用例

市面上有非常多的关于UML，关于Use case编写，关于RUP的书。可是没有关于如何在我们已经有结构化的想法，或者说，当我们的脑子中已经有全局与整体的设计思路想法时，去总结与实现Use Case？

 

最外层用例是指主actor在用例之外的最高层次的Use Case。简单的说就是对这个系统要完成什么工作的最抽象的说明。如果对最外层用例不清楚，可以看一眼《编写有效用例》（Alistair Cockburn著，机械工业出版社）

 

先简单的介绍一下我们的项目。由于背景将会对Use case设计产生很大的影响，所以在此先进行说明。

 

本系统的目标是制作出一个跨企业的信息平台，为目标公司的客户进行服务。这些服务分成很多的方面，比如提供给银行的公司财务情况查询，提供给生产厂商销售情况的报告。提供给销售的商场以及店铺货源的情况，提供给物流，安装服务公司送货以及安排信息。从中赚取提高销售效率，减少运输损耗的费用。

设定目标公司为A公司，信息平台名称B系统。

      

以下是二种对这个系统的最外层用例的描述：

¨         项目最初描述的最外层用例

————————————————————————————————————

u        用例名称

         最外层用例

u        简要说明

         A公司决定让其业务合作伙伴以及最终的用户通过互联网访问B系统以达到减少A公司本地人员的工作量以及提升工作效率的目的。B系统负责完成进销存业务、其它业务处理以及报表管理。一些系统维护人员还负责管理基础信息的认定与实现。包括四个用例：基础设置子系统，进销存子系统，其它业务处理子系统，报表子系统。

u        用例范围

         跨企业信息平台

u        主执行者

         客户

u        用例层次

         白云（最高层次）

u        前置条件

         有新业务产生

u        触发事件

         客户有购货的需求

u        主成功场景

l 系统维护人员操作基础设置子系统维护基础设置的数据。

l 操作人员操作进销存子系统完成进销存业务。

l 操作人员通过报表系统分析查询业务结果。

l 操作人员通过其它的业务子系统完成对系统中的其它业务处理。（注，其它业务子系统包括财务资金等等子系统，将会子用例描述中强调）

u        扩展

         无

u        未解决的问题

         无

————————————————————————————————————

 

设计此版本的最外层用例时，由于公司内已经有一些相类似的产品的设计方案与DEMO。所以出现在我脑中的第一感觉就是我们将要完成的系统一定中会有几个菜单项，比如基础设置，进货管理，销售管理，库存管理，财务资金管理，报表打印子系统等等。从这个基础上再进行了一次抽象之后，我们将最外层用例定义成上述的描述。

这个描述应该说并没有错误，但是当你顺着这个最外层的用例向下展开你的其它子用例与子子用例时，就会出现以下的一些问题：

1.         当从基础设置展开时，我们根据需求定义出了一些常用对象设置，比如商品设置，价格设置，库房设置，机构设置等等，但是具体每一个设置中要设置到多详细，需求中的定义并不是很清楚。所以当我们对应需求在做基础设置之中的子用例与子子用例时，有一种不知道这些设置是从哪里来的感觉。

2.         当与客户交流的时候，客户往往并不关心你的设置要搞什么东东，他们最为关心的是把业务是不是可以运行。所以从关心的角度来说，对我们与客户交流的时候，这样的最外层设计使得我们对系统的关注出现了偏差。（例：我们做出的DEMO给客户，客户对我们的基础设置没有提出太多的问题。但是在提交给客户的测试版本中，发现有一些基础对象的设计不对，这时候才又要对系统进行修改。）

……………………

也就是说我们的设计可能会被这个最外层用例带成这样一种形式：

       考虑有多少个基础设置对象设计 –》 考虑业务处理 –》再根据业务处理的特性来修改基础设置对象的设计

 

所以总的来说，设计出这种类型的最外层用例的情况一定是设计人员刚从结构化设计的角度转向用例驱动的设计与开发方式（出这种用例设计的人一定是个程序员或以前干过程序设计的）。这种设计方式是从开发者的角度出发，而不是从设计者的角度出发的。（写完这篇笔记之后我与一个朋友进行交流，他告诉他以前也同样有过这种类型的错误。）

 

¨         第二次描述最外层用例描述

————————————————————————————————————

u        用例名称

         最外层用例

u        简要说明

         A公司决定让其业务合作伙伴以及最终的用户通过互联网访问B系统以达到减少A公司本地人员的工作量以及提升工作效率。B系统负责完成销售业务以及报告销售情况。一些系统维护人员还必须为客户和职员设置安全存取级别。包括四个用例：增加服务（A公司本地），增加服务（客户），报告业务情况，管理安全存取权限。

u        用例范围

         跨企业平台

u        用例层次

         白云（最高层次）

u        主执行者

         客户

u        前置条件

         客户有购货的需求

u        主成功场景

l 客户通过电话，邮件联系A公司操作人员，请求一个新的服务。A公司的操作人员通过B系统处理服务请求。

l 客户直接通过B系统的客户端，请求与处理新的服务。

l 客户通过B的系统可以查询出销售情况以及其它相关情况的报表。

l B的系统维护人员将要对客户以及操作人员进行安全存取权限的设置。

u        扩展

         无

u        未解决的问题

         无

————————————————————————————————————

 

这种最外层的设计方法应该说是完全从用户的角度考虑的，并且还有一点，这个最外层并不是完全包括我们已前实现过系统的所以最上层菜单。（没有基础设置等等）。但是应该说这个最外层用例方便我们将关注的焦点转向用户真正需要什么？而真正的从用户的角度出发来考虑问题。

 

所以针对已经有设计经验与开发经验的朋友，我想可能对最外层用例的处理需要做到以下的两点：

1.转化你的角度，不要先上来就抽象你认为一定要存在的子系统。而是应该放在用户的角度思专

2.学会放弃。不要把最外层用例搞成一个系统最终设计版本的一个高级抽象形式。用例这个东东与最后的设计并不一定完全一样。（比如基础设置之类的服务性系统，也许并不会在最外层用例中显示出来。）

 

以上的说法只是我的一些感觉，也许并不一定正确。画最外层用例应该说有很多的方法可选择，也许针对一个项目可以有很多“正确的”最外层用例的设计方法。上面两种划分方式应该说只从最外层用例的角度来说都是正确的，但是如果加上对后续过程发展的影响，我的感觉是第二种方式会比第一种方式好一点，可以说是清楚一点。朋友们如果有一些其它的体会，欢迎与我交流。mailto:[e-mail]