UML用例图之泛化(generalization)、扩展(extend)和包含(include)关系--UML一波流系列讲解

用例这个东西自从发明以来就快速发展了，而且逐渐的分成了两派。一个是这个帖子里面反应的，uml用例图的这派。另外一派，则是完全抛开图式，只有文字表达的那派。有两本书可以做代表，一个是你说的这本，另外一本是有效用例模式。其中你的这本的作者就是这派人的代表。

而楼主的问题，其实并不是你说的那样，而是我认为的他其实是纯的用例图拉出来，而没有跟后面的代码编写结合起来看。这个问题其实也是个常见问题了，因为大家学习的时候往往是采取从前到后的顺序，比较习惯性的先解决前面的问题后解决拉的问题。

但是方法层次这样做是有问题的，因为实际的应用方法绝对不是流线化的，而仅仅是训练方法才会是流线化结构化的。或者这样说，面向使用的方法不能采取从前到后的流线方式，而这种从前到后的流线方法是面向学习的方法。

我们讨论的泛化，扩展和包含就是一个例子。比如如果我们从编码的角度看，从对象分析的角度看，很难确定这三者究竟会在最终产品层面，也就是代码层面带来什么不同。而且更多的情况是，你在这里分析了半天，结果代码完全都是一样的。这样的事情，就是在扯淡。而把面向学习的方式，使用在面向应用的方面就往往会是经常性的扯淡。结果不仅学的东西搞糊涂了，做起来也更混乱了。

以用例文本描述为核心，辅以图示是我比较认同的做法。



所以我建议将主要精力放在用例描述上。

用例图应该很难和代码结合起来，其表达能力毕竟有限。用例的文本描述则不然。根据用例描述的用例场景所做的设计（用例实现）就比较容易契合到代码。

以用例文本描述为核心，辅以图示是我比较认同的做法。



所以我建议将主要精力放在用例描述上。

用例图应该很难和代码结合起来，其表达能力毕竟有限。用例的文本描述则不然。根据用例描述的用例场景所做的设计（用例实现）就比较容易契合到代码。

如果你有兴趣，看看本版我以前关于用例的发言，就会知道我跟你的看法基本一致。

但是本贴的一个大问题，在于他们试图描绘一些内容，这些内容很类似在编写代码，但是又不能保证这些工作最终能反应到代码中去。而不管你是用文字的方式，还是用图式，对此都是一样的。