UML系统分析与设计02-用例图和活动图.docVIP

? ? 每一个产品的需求是对现实世界特定问题的一种描述，而有些问题描述可能是非常的错综复杂，以至在我们对其进行分析时，会觉得无从下手甚至不知所措。 ? ? 需求分析是系统设计和开发的基础，需求分析的好坏会直接影响后继设计和开发的质量，严重时会影响到系统的成败。UML中的用例图就是为了方便我们分析与交流产品需求而生，同时也为我们把产品需求转化为系统需求提供方便。 ???????? 产品需求：一般反映的是现场的具体现象，经常是由产品工程师/销售人员收集或由用户直接提供，表现的较为松散、粗放，是一种比较切合现实的描述。 ???????? 系统需求：一般是在对产品需求进行一定的分析后，对其中不能实现或实现起来有困难的部分进行了一定的取舍，同时对一些较为笼统的需求进行明确和细化，甚至会对一些需求进行了一定的抽象和重组。 有时也会结合具体应用加入了一些逻辑的描述（即现实以外的抽象术语），表现的更加切合软件系统。一般在评审通过后，系统需求会以《产品需求规格说明说》的方式提供，并成为系统开发的范围依据。 ?????????????????? ???????? 接下来我将介绍一下本人在用例分析过程中的一些心得和休会。 ? 一、“Somebody do something”模式 ???????? 在我们对需求进行分析时，我们可以本着“Somebody do something”的模式来寻找用例/关键用例，当然这里的“somebody”可以泛指人、物或其它系统等。我们可以以“做某件事”作为一个用例，而后成为系统的一项功能，即满足一点需求。如果能DO完所有的THINGS，那么我们的系统也就成了。 ? 二、用例分析要注意事项 1、单一场景，即每一个用例只为说明一件事，我个人反对包罗万象的“上帝”用例。 ? ? 2、简单原则，即每一个用例要通俗易懂，能非常明确、简洁地说明其某项功能和作用，无任何歧义及多余的想象空间。 ? ? 3、唯一性，即每一件事/场景只能出现一次， 如果其它地方要用到同样的场景可以采用“引用”的方式进行组合。 ? ? 三、分而治之个个击破的思想 1、? N阶的问题 ? ? ? 在对新员工面试时，我一般会问一个“汉诺塔”的问题，在这个过程中我并不看重答案，只在呼解决问题的方法。即递归中是如何把“N阶的问题转化成N-1阶，最后成为1阶的问题”的思想。 其实需求分析也是一个要把错综复杂的N阶问题，最后转化成1阶问题的过程，这种从N至1的方法不仅在需求分析中能用上，其实在后继的其他设计中也一样很有用。 ? 2、? 自上而下或自下而上 ? ? 对需求的分析我们是可以采用自上而下或自下而上的进行分析，相信这些大家都有耳闻，在此不做详述。就我个人而言比较喜欢“自上而下”的分析方法，即由“宏观”到“微观”的过程，其实有点像我们任务分解中的WBS分解方式。 对需求中描述的场景和所要解决的问题应用“单一场景”、“简单原则”和“唯一性”逐一分解，至到合乎要求为止。 ? ? ? 拿我们的“MusicStore”项目来说吧，系统无非是“系统出售唱片”（当然这个需求有点简单），但要满足这个要求就得提供“管理员提供唱片”和“客户购买唱片”等功能。以此类推“管理员提供唱片”可能会引发“管理员创建唱片资料”、“管理员修改唱片资料”和“管理员删除唱片资料”等新的功能；同样“客户购买唱片”可能引发“客户添加唱片到购物车”、“客户移除购物车中的唱片”和“客户结帐”等功能。如此反复递归，我们最后会发现好像用户要的功能我们都能提供且足“单一场景”、“简单原则”和“唯一性”的要求。如果真是如此，那么我们的分析过程基本也就告一段落，之所以说是告一段落，是因为一些复杂的需求只对其表象进行分析是远远不够的，还得站在更高的全局的视角来进一步审视，可能还得对其进行一定的重组甚至抽象，直到满足系统的要求，后继我们将会有相关的例子。 ? 3、? 边界和委托 ? ? 边界，在需求定义的场景中，有一部分场景他们的工作背景和工作方式都比较类似，且彼此之间有着较为紧密的联系，那么这些用例就可以组成一个相对封闭的区间，这就是用例边界。 ? ?有时候我们也会根据不同的actor来区分不同的边界。 ? ? 比如：“管理员创建唱片资料”、“管理员修改唱片资料”和“管理员删除唱片资料”就可以认为是“管理唱片资料”这样一个边界。 ? ? 由于VS2010并未提供Boundary功能，而是以subsystem来提供。为了更好的说明问题所以此处提供2张图，第二张由EA绘制。 ? ? ? ? ? 有时我们会把同一个边界内具有相对内聚性的用例抽象成一个用例。 ? ? ? ? 委拖，在进行用例分析时，当出现有些用例已超出了当前的边界，但是与边界内的一些用例又有较为紧密的关系时，我们往往可以考虑使有“委托”的方式来，