my world

用例图是需求分析中的产物,我的朋友曾与我经常讨论关于它的东西,现在也有越来越多的专业朋友喜欢关注它,不过,对它的不理解或是误解普遍存在.
  今天是我五一休息的最后一天,因为明天得去公司加班,呵呵,在这空闲之余我想谈谈大家比较关注的那一部分我个人的理解.
  先用我自己的话谈谈用例图的功能或是说作用,用例图就是需求分析员与客户在需求上将达成一致意见的设计图纸,他们之间的交流全靠这张图纸,需求都是在这张图纸上体现出来的,描述了客户将如何使用这个系统.用例描述着一个个故事场景,用难理解一点的话来说,就是描述着用户期待的一个个系统目标,实际上客户在描述他的需求的时候就是在给我们讲一个个故事的来龙去脉,我们如何将他口中或是文档中描述出来的故事设计成用例这就是关键,关键之处就是你怎么去用一个用例来概括一个故事场景,而且正好就是用户期待一个系统完成的目标.
  呵呵,有点抽象吧,不要紧,我接下来纠正一下朋友们对用例的一些误解.
  1、用例之间的包含关系不是用来表示用例之间的谁先谁后的关系，在用例图中用例之间不存在先后关系，包含是指主动去包含的那个用例拥有被包含的用例的过程，也就是说一个过程包含了另一个过程，再说明一点就是说我走这个过程必要经过另一个过程，这就是一个用例包含另一个用例。可以看得出用我们贴切生活的语言来描述能更易让我们理解一些东西，这也是我曾总是强调一些朋友别去用华丽的词来封装本来你都不是很理解的东西的原因，为了理解用例，我们在交流并学习他时，希望在口头描述时，用“过程”或“场景”代替“用例”，用“使用”来代替“包含”，我最怕我的朋友把包含说成调用，因为用这词难免会让我们程序员想起是程序里的方法或说是功能上的调用，这样会使我们无法避免地纠缠在实现的细节中.
  2、用例他不是功能分解，这也是我要大家避免用“调用”这个词来修饰“包含”的原因之一，只有功能才总是说这个功能调用那个功能。再重复一遍，用例真没别的什么，他就是用户渴望得到的一个系统目标，比如用户希望查询系统能达到查询、更新、删除甚至新增的目标，那么用例就是查询、更新、删除和新增。可以看到设计用例是站在用户的角度来思考的，考虑的是用户将会如何来使用系统，跟功能分解不是一回事。
  3、用例图不能描述用例执行的先后关系，你应该用活动图来描述他的更细节的东西。
  4、一般稍大一点的系统，你别妄想设计出用例图后就可以马上用代码实现我们的系统，一般的做法应该是用例图->活动图->时序图（可以发现对象以及他的行为）->协作图(可以发现对象之间的关联，对改良设计、提高内聚和降低耦合有好处）->类图，小系统都会做到心中有数，不一定要用这种UML高级的东西，因为用上他会增加你的工作量，而且还会让你感觉在浪费时间。
  用例还有很多东西需要大家去了解的,如如何找出参与者和行为,如何划分系统边界,如何理解用例的一些其他关系(扩充,泛化等)等.
  UML算是一个庞然大物了,用例图是UML中的其中一种,还有很多图,你不仅要去学习他的很多种图画法,去了解他们之间的区别,了解他们用的时机,而且最重要的就是你一定要很好地掌握他的思想.
  呵呵，今天的主题是在这空闲之余谈谈大家比较关注的那一部分，所以将不会大篇幅来讲解用例了.大家如果还是感觉不过瘾,可以加入我的QQ群(个人资料里有介绍),一起讨论,一起进步.