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

to peterwei

你理解错了。我的意思是，你做的事情全都没有错误，但是你做的事情没有价值。

其次，我注意到你用到了建模这个词。但是我认为，你现在根本就不是在建模。

最终我最奇怪的是你究竟是在做什么，因为我根本就看不出你到底是要做什么？是要编程，还是要分析，还是要。。。。。？？？？？

说实话，我并没有在任何一个项目中完全的uml建模。实际的项目中一般就是需求获取、用例分析、类图、时序图，进入迭代开发。我很想知道你眼中的建模是什么概念。
其实在实际的工作中，分析这个用例的时候，需求基本上已经从客户那边获取完毕。这个阶段算是分析细化阶段，进一步是从用例分析中为了工作任务的细化和分解。好吧，我也承认为了让我的文档里更好看些。当然也算是写一下小教程，让完全不知道的人学习一下。

to peterwei
建模就是建模啊，建模不是编码啊。既然是模型，肯定就不是实际的产品。也就是说既然是模型，就不能也不应该，也不可能过细。而用例是可以做的很细的，细到在很多时候联代码都不能反应出这些细节。当然我不能说这样的用例分析就没有用，毕竟在业务分析的观点下，这样可以更清晰的解释业务的全景和业务原子，但是很遗憾你不是业务分析人员。

其次你说的什么用例在需求分析之中的用途等等，我建议你看看我以前发布在本版的关于用例和UP的讨论，那里面写的很详细了。

。。。。。。。加油看～～～

用例分析，最核心的不是用例图，也不是它们之间的关系，而是用例描述。

UML Distilled: A Brief Guide to the Standard Object Modeling Language 3rd Edition

 

Writing Effective Use Cases

 

这两本书讲得比较清楚了。推荐之！

[quote="walkalone"]
用例分析，最核心的不是用例图，也不是它们之间的关系，而是用例描述。

UML Distilled: A Brief Guide to the Standard Object Modeling Language 3rd Edition


Writing Effective Use Cases


这两本书讲得比较清楚了。推荐之！


你推荐的书很好，但是非常可惜你的推荐跟本讨论一点关系都没有。

而且你第二本书说的用例，跟我们讨论的东西根本就不是一个东西。

Writing Effective Use Cases 这本我有看过的,还行。但确实我们是在说画用例图的时候以及用例的关系。

 

何出此言？这2本书是我据主贴内容所荐。

 

因为，楼主似乎过于执着用例图和用例关系了。这样并不能带来多少益处，反而带来不少弊端。用例描述才是其核心。

 

对于用例分析，一般应该尽可能简化用例关系。特别是要慎用扩展关系，尽量不用泛化关系。其弊大于利。这2本书都给予了不错的指导。

 

我们应该将主要精力放在用例描述上。第二本书提供了不错的指导。

我并没有过于执着，其实就是相当于一个教程总结一样的东西。实际的项目过程中基本上就是文档描述每个用例就完事了。

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

 

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

 

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

 

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