UseCase的误区(Java开发者)

Q：
在作usecase的时候很容易使一些设计人员产生一些误区，比如用例之间的不连贯性，数据流的流转，还有其他的一些弱点，如何避免这些问题呢？
A：
用例是帮助确定系统边界的一个好方法。合理使用不会出大问题。
而且在过程的不同阶段，对用例的关心是不一样的，用例自身要能够跟踪。全过程跟踪。所使用的software process对如何更好的使用用例是有影响的。
它是software process的一部分，如从系统的角度研究，会有所帮助的。
它是一把双面刃，玩熟练了，就好了。
Q：
设计人员过早的进入use case，并且过早的分解use case ，使得这个系统的内部结构不闭合，如何避免这种问题呢？
A：
一个好的process会有很大帮助的。
例如RUP,它定义了每个阶段你可以得到的制品。当然实际工作中，需要自己把握这个度。即不可以过早进入细节阶段，造成过渡设计；也不能没有细节，完全在粗线条下工作，造成没有设计。
可以适度裁减适合自己公司，自己团队的一个过程。需要一个稳定的团队来实践，特别是一个稳定的过程教练。团队波动太大，不利与过程的发展，那么具体的某一个技术(use-case,class diagram....)的使用效果也不太好。稳定的团队，合适的/清晰的过程，合理的角色分配应该有所帮助的
Q：
组织机构模型，数据模型，业务流程模型，功能模型（use case），作应用设计的时候我们一直走的是这种方式
A：
组织机构模型，数据模型，业务流程模型，功能模型（use case）是具体的技术,不是process. process定义每个阶段可以得到的制品,例如在需求阶段得到什么粒度的use-case, 在分析阶段,你的use-case一定是对需求阶段use-case的trace,在这一阶段你希望use-case的细化到什么成度,是否需要其view帮助描述use-case. 在每一个阶段制品不同,但从整个process来看,它们是连续的,可trace,可管理的.
同样,你在那一阶段引入数据模型,达到什么粒度,都需要定义清晰.
这个过程就是软件过程裁剪,也可以说是我们软件企业自己的流程改造.而这一过程,又可以通过UML描述,又以原始的过程为指导.