2008-7-2916:42:50 我在做一个报表的项目，帮微软的一个部门制作自动化报表生成工具。我发现，我很难用Usecase 去描述所有的需求。工作流程是这样的：程序从数据仓库里读取数据，输出到Excel 的模板。
大的流程很简单，但是里面有很多的细节的东西是比较麻烦的。用户有很多的需求是针对数据的格式提出的，比如希望用什么样的chart 来显示，希望加入什么新的统计方法，等等。这些需求我觉得很难用UseCase 来描述 
潘：也就是说，功能需求比较简单，其他需求比较多，是吧 
2008-7-2916:48:28 是的。用户只是输入一些参数，然后就等着看excel 格式报表，就这样 
潘：用例本来就分为这样的结构来描述：用例、路径、步骤、约束。你的需求在约束的层次上面比较多 
潘：用户有很多的需求是针对数据的格式提出的，比如希望用什么样的chart 来显示，希望加入什么新的统计方法，等等－－这些需要一一理清，哪些是需求（例如业务规则、非功能需求），哪些我们自己想的设计 
2008-7-2916:50:42 是的 
潘：判断的标准是：如果不满足××，是不是某一类涉众的正当利益就一定会受到侵害？例如"希望××chart"来表示，可以思考，如果不满足这个，哪一类涉众一定会不满意，他为什么不满意。另外，"输入一些参数，然后就等着看excel 格式报表"这样的功能很可能不是涉众之所以要买你的软件的价值。很多软件不都是"输入一些参数，然后就等着看excel 格式（水晶.Word...）格式的报表"吗
2008-7-2916:53:26 哦，没有，我只是描述一下用户使用的情形。绝对不会这样和用户去沟通的，呵呵 
潘：你卖什么功能给他，这些功能表现得要多好，把这些写清楚，就是最好的需求了 
2008-7-2916:55:09 好的，我明白 
2008-7-2916:55:20 我的另一个困惑在于分析和设计上，我感觉自己在公开课上听到的分析方法，不能覆盖到全部流程。特别是后端的数据处理过程，以及包含的计算方法和业务规则，我找不到什么合适的表示方法 
潘：例如？是不是说一个方法里面有很复杂的算法？ 
2008-7-29 16:58:25 有这种情况。我先说一下现状吧。我加入这个项目组的时候，项目已经Release 过一次了。 我加入之后不久就Release 第2 个版本。现有的一些代码我看了一下，感觉不是很理想，问题比较多。所以我打算把整个系统梳理一遍。首先就是了解用户的工作现状，用UML 描述出来。之后，对我们已经实现的功能作一个……怎么说呢，算是"逆向"分析吧。逆向的时候，还是直接套用了Entity-View-Control 这种方式来分配职责，在sequence 里面可以画出从用户界面接受参数输入、提交执行查询的过程，但后面还有一系列的处理，例如在存储过程里面的处理（这个系统的存储过程里面封装了太多业务逻辑，甚至还有不少是用于界面处理的逻辑），ExcelAdd-in 里面的处理（C#），Excel 模板里面的处理(Formula,VBA,...)，在类识别和职责分配上面，不像前端那么清晰，没有一个像entity-view-control 那样的成熟方法，基本上还要靠摸索，这方面有没有什么比较好的分析方法？
潘：方法里封装了太多业务逻辑－－这个UML 可以表达，活动图或者序列图。但问题是，方法里封装了太多业务逻辑－－这本身就不对 2008-7-2917:08:32 是的，我是想解决这个问题 
潘：面向对象就是要把业务逻辑分摊到各个对象上 
2008-7-2917:09:07 没错，我就是感觉分配职责的问题比较棘手 
潘：感觉棘手就对了，说明你已经接触到了业务的核心机制 
2008-7-2917:09:34 因为太散了，t-sql，vba，c#代码里面都有 
潘：我想，先不要针对具体某个大方法来慢慢找类，先对业务领域做一个全面的分析，找出核心的类和他们之间的关系。再来看看这些业务逻辑可以分摊在哪些类上 
2008-7-2917:11:56 对一个报表系统来说，有哪些比较成型的分析方法呢？例如一些模式之类的？另外，这种系统是否适合用ooa/ood 呢？很多报表系统都是基于sql 或者cube 技术的，不是一种procedural 的东西。
潘：当然适合。基于sql 或者cube 技术－－后头的数据源变了而已嘛，以后没准还有基于XML，SOAP。。。的呢 如果你的核心领域不是具体某种类型的应用，而是报表本身。那么，业务核心机制就应该由图、表、数据、行、列、表这样的类构成。
2008-7-2917:16:07 恩，与我所想一致:D。我也向这个方向考虑过，不过没有怎么深入，呵呵