所在位置:答疑 - 内容   
帮微软的一个部门制作自动化报表生成工具
 

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。我也向这个方向考虑过,不过没有怎么深入,呵呵