use case,面向对象和功能分解的问题，请各位大侠赐教!
　

---

我现在面向对象的设计的做法是按一定的功能抽象出use case,
比如说打印报表，综合查询，综合统计，权限模块等等use case,
然后按use case抽象出相应的接口(抽象基类)，
每个模块都继承自这些接口，
功能扩展的话，都采用delegate(组合)，不采用继承，
但我觉得这样似乎得出来的设计还是功能分解的。
请各位赐教~~~
谢谢!

该怎么设计呢?谢谢!

这样的use case 更像以前的功能模块（modules）, 也就是“功能分解”， use case 不应该用来做功能分解， 功能分解应该在作domain model， 也就是不同层次的class diagram 来做， 而且不是按照功能模块来， 应该按照OO来。

use case是需求分析， 用来cover用户的需求， 然后驱动整个项目的开发进程。不管用什么方式approch, 它的核心是“Identify the actors/support actors" 以及这些用户各自要用该系统做什么事情。

个人觉得用分解功能模块来代替use case 似乎有类似之处， 但是不能达到use case这个工具的目的：尽量cover全部的需求. 因为use case 的分析方法/思路 与 分解功能模块 不太一样。而且分解功能模块已经参杂了技术分析，可能蒙蔽一些另外可用的解决方案， use case更加面对客户的业务(business)。

关键是我的需求大概也就是这些功能模块，
因为这些功能模块已经是长时间的项目后，
用户确定下来所需要的，
我现在的问题是要把它们转成OO的形式，
如何设计接口呢？
多谢!

我个人的经验是原来的功能模块和现在的OO在基本的思路上， 或者思维方式上不一样。就是要如何thinking in OO的问题。OO是根据名词来划分domain， 然后再找出每个名词要做的动作（这些抽象的名词+抽象的动作就是接口，它们有很强的通用性）, 功能模块是根据动作来划分， 然后再找出需要操作的名词（这样也可以有接口， 但是它们是通过动作导出的，如何保证接口的通用以及如何标定接口的适用范围就有问题）。

use cases虽然也是按照功能划分， 但是并不用来“导出”设计， 它们是用来驱动项目的进程。

不是用oo概念设计的系统，其architecture和OO系统不兼容，oo系统的architecture 有一个参考实现：http://www.ratio.co.uk/architectural_reference_model.pdf 您可以看看这篇文章。

不是用oo概念设计的系统转化成为OO系统有很多风险，你们应该仔细调研一下。个人认为首先确定转成oo的目的和好处：常见的就是提高维护性，扩展性(scalability)。

然后确定是否需要对现有的系统作改动以达到这些好处：如果你已有的系统没有很强的扩展需求， 还是用旧设计，旧方法，旧流程比较稳妥。如果你的系统原来是为一个specific用户设计的， 但是现在想把它做成一个有一定通用性的产品，个人建议是重新来过！看起来好像浪费了前面的成果，其实不然：
1。 以前项目的最重要成果还在使用：客户的业务需求。而且你可以跳出原来的系统设计，利用rup/uml更加全面，抽象地描述需求，
2。 为了适应更加广泛的需求，或者其他特别需求， 重新按照oo方法进行分析设计比起打补丁在短期内看似乎花费更多资源时间， 但是长期来说系统的维护性，扩展性要好很多，如果你考虑作产品， 一定要下这个决心， architecture上面的问题是补不过来的。我们公司有很多实际的例子，补丁打完后根本没办法维护，经常还要再补。但是这么做一定要解决skill & technology risk(参考UML_Distilled_2e.chm chapter 2, 在文件共享中有).

一般的方法是先识别对象，再设计接口。而不是反过来。但是先设计接口可不可以呢？也是可以的，但不是如你这般理解的接口。在我的weblog上有一片文章与此有一点点关系，可以给你参考一下。smilemac.blogbus.com

 回复: use case,面向对象和功能分解的问题，请各位大侠赐教!
　

---

我个人认为，问题不在于没有区分清楚use case和功能分解，而是因为你没有一个architecture为依据，而只好从功能角度做设计了。
　

 回复: 这样的情况确实在很多公司存在，包括我们自己
　

---

构架方面的refactory是要做的.毕竟是灵魂:)

 说得对.作为了解refactoring重要性的开发人员和architect, 这个决定是显而易见的
　

---

但是作为公司的经理和sponsor(负责项目成本的)， 他们不知道这个道理， 总是认为把已有的东西丢掉太浪费。他们的architecture技术层面大都也停留在c/s 2 层结构和用功能分解进行项目设计上， 要说服他们真的很难。

采用RUP进行软件开发的不同iteration之间进行比较底层的refactoring有好处这个结论几乎已经被大家接受。然而Architecture上的refactoring 对项目的好处和带来的风险至今没有统一的结论， 至少在北美没有相关的统计数据来支持，老板一提到我们这个项目要从vb6 转 .NET就是说要逐步进行， 先不要转数据库设计， 再不要一次转原来用vb做的COM,只能部分转。 我心里说：那么什么都不能动了。原来按照功能分解的模块怎么能转到.NET上还能赋予.NET提供的scalability等等优点？ 而且全是用aggregation实现的功能要不从头设计， 根本没有办法做到interface development。

 回复: 说得对.作为了解refactoring重要性的开发人员和architect, 这个决定是显而易见的
　

---

还有一种情况就是老板要你一股脑从头到尾全部重新来搞，不过对不起，时间只有1个月，人员就这么多，到时候你就得拿出东西应用到若干具体项目。
最近我们做的项目就是这样，前面这周的人员分工，架构设计，业务设计，开发测试的迭代做得很不错，感觉很多地方其实是契合了一些主要的过程原理的(由于具体原因，没有专门进行过程设计上的工作)。
可惜，昨天听到消息就是1个月内要全部搞定，心里立刻很恼火，为了进度不求质量，预定了后期无休止的维护修改工作，累死累活的又是我们。

或者挑出几个关键的use case做1~2个iteration来满足客户目前紧迫的需要， 如果全新的做法不能在短时间满足客户需求, 就当机立断按照原来的做法添加几个紧急补丁(当然还是要建立相应的文档以便后续工作进行)。理性的老板应该能在了解情况后迅速召开会议制定应变方案.

个人认为,不管这么样，这么短的时间如果走完整的SDLC不可能的话，只能走emergency process, 一个成熟的公司, 不管它的管理层技术水平如何, 一套应对不同业务需求的processes必须建立. 如果没有, 作为QA,如果没有QA, architect必须利用这样的机会向管理层建议这么一个应急process,包括如何考虑风险, 如何选择方案. 这样以后遇到类似的情况就有据可依.

商场如战场,软件开发最终也是为了商业利益. 商场变化无端, 技术上的战略战术也应该有相应变化,最好是事先准备--emergency process: 有正规军正规作战走RUP, 但是也要有快速反应流程甚至游击战. 但是不能像阿拉伯人那样一辈子打游击战和自杀攻击, 要发展内需,提高自我综合能力, 为转变正规战做准备, 并主动创造条件, 一旦条件成熟,正规作战才能取得最终胜利.

如果一个公司的老板不能理性的接受这些提议的话, 这样的老板根本没有前途, 我会乘早走人. 宁可到一个公司老板技术能力不强,但是至少明白作事情有个过程这个道理, 像现在, 我虽然觉得郁闷, 但是不会被整天压着加班做的还是垃圾然后烦躁生气. 老板和客户沟通的能力对下面的人影响很大, 会沟通的老板也懂得体恤下属, 知道该急的事情急, 该缓的事情缓, 张弛有道下属也会做好配合.