用usecase驱动ooa,ood,oop的困惑.txt

一些关于UML的经典讨论

用usecase驱动ooa,ood,oop的困惑

--------------------------------------------------------------------------------
根据rup，用usecase驱动ooa,ood,oop，即对每一个usecase，从分析设计一直到产品，然后开始第二个usecase......，再开始第三个usecase.....。我们知道，这些usecase中有很多class是共享的。这样就导致了问题：做第二个usecase时必将对第一个usecase中的一些共享的class进行修改，即后面做的usecase要对前面做的进行修改。这些修改有可能使前面usecase驱动的产品毁坏。 

1==========
原文(cattom于2001/04/29 16:51粘贴) 
我也想听听是怎么一回事？ 
--------------------------------------------------------------------------------

2==========
原文(王正光于2001/04/30 08:16粘贴) 
回复: 用usecase驱动ooa,ood,oop的困惑。。。 
--------------------------------------------------------------------------------
1,这个问题很好。 
2,面向对象设计和编程的重要方面是代码重用。 
3,在多个USECASE中，我们知道好多类是可以重用的，但可能接口（INTERFACE）不一样，否则的话，USECASE中用的是同一个类。 
4,所以我们可以设计具有多个接口（INTERFACE）的类，实现类在多个USECASE中的重用。

3==========
原文(jasperyeh于2001/05/01 16:12粘贴) 
Re: 用usecase嵌oa,o,p的困惑。。。 
--------------------------------------------------------------------------------
按照我的理解， 
我首先讲述“固化”的概念： 
对于class(?)，引用继承机制，我们可以产生基类的变体。这个子类中的接口允许一定程度上的不同，当然不是本质的不同。 
实际上，这是一个固化的过程。我所谓“固化”，是指基类的定义和接口，在一定的进度之后，应该予以确定。这样，假定以后你需要一个略微不同的class，你需要从固化类中继承一个中间类来实现要求。 
除了对象理论的参照之外，明眼人一见便知，这和微软的所谓“界面固化”（UI Frozon）的道理有相似之处。 
推而广之，算法固化，设计方案固化，...，（我想的太乱了） 

其次，更新与自适应： 
类的集成和类层次树的形成，一个目的就是自动得到新特性。假定A类接口形成，B继承于A。当A暴露的接口改变时，B将会自动获得A的改变，这是强大的能力！应该善用之。 
请注意这和“固化”没有任何冲突：改动A的暴露接口时，第一原则是已经暴露的接口不应该被修改。 
这里体现一个软件开发人员的分析功力了，你是否能够让自己以前设定的接口一直适用下去呢？如果不能，应该继续加强分析(即对对象进行抽象)能力，不再赘言。 
要言之，你可以对暴露接口进行添加，不可以改动和删除，这将导致雪崩的不可测后果。 
第二原则是，隐藏的属性和内部的接口允许被有节制的调整，将不会影响到继承类。 
同样，这也是一种能力，应该掌握那些可以被暴露，哪些不应该被暴露给继承类。关于这一点，想想Undocumented Windows API吧。要想一棵树有序，你需要在设计时做出n个决定，我相信，每一个决定都是“痛苦”的。 
而，已经做好的类设计只能有节制的被调整，盖因如果你改了个底朝天的话，岂不是说你以前的设计太差，只能换掉？ 

最后，版本控制： 
也许我们没有必要持续保持接口的一致性，你当然可以这么做，而我也当然不会反对。那么，请做好相应的说明文档，标记上合适的版本跟踪。 
别忘了，并不是只有源代码的，文档，设计稿，图样，任何东西都可以进行版本跟踪。 

以后，不知道，我会不会被check out 为jy77.0.20500107，;) 

一家之言，你可以参考并调整你的类和类图设计。并，敬请指正。