UML系统分析与设计02－用例图和活动图（上）

    每一个产品的需求是对现实世界特定问题的一种描述，而有些问题描述可能是非常的错综复杂，以至在我们对其进行分析时，会觉得无从下手甚至不知所措。

    需求分析是系统设计和开发的基础，需求分析的好坏会直接影响后继设计和开发的质量，严重时会影响到系统的成败。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绘制。

 

 

 

    有时我们会把同一个边界内具有相对内聚性的用例抽象成一个用例。

 

 

    委拖，在进行用例分析时，当出现有些用例已超出了当前的边界，但是与边界内的一些用例又有较为紧密的关系时，我们往往可以考虑使有“委托”的方式来，简化分析过程 。

    就拿“客户结账”用例来说吧，它可能会引发出“系统查询帐户余额”、“系统转账”等一系列新的用例出来。此时我们可能会出现，其实我的目的就是“结帐”，至于怎么结帐及结账的细节并不是我在本场景的主要议题，由此可能可以确定“查询帐户余额”等已超出本用例的边界，从而我们可以“委托的方式”委派给“银联系统付款”，从而一笔带过。

 

    有时候我们可以简单的认为“服务”就是边界外的委托。

 

    在分析中我们可以先不关心大象是怎样放进冰箱的，只关心大象能不能放进冰箱！

(此图来自互联网)

 

4、  活用“Include”和“Extend”和“Generalization”

    在用例会析中，少不了对“include”、“extern”和“Generaliztion”的应用。

Include:主要是指包含这些用例，包含并不指子用例就一定会同时发生。

比如：管理管理唱片信息 新增唱片信息 修改唱片信息 删除唱片信息 导出唱片信息

 

Extend：是指在满足某一情况时一定会触发某个用例。

“客户结帐”在“未登录”的情况下会 触发 “登录”用例。

由于未发现VS2010提供extension points的功能。为了更好的说明问题所以此处提供2张图，第二张由EA绘制。

 

 

 

Generaliztion：泛化，在用例视图中我一般只用在Actor上面使用，在实际的用例中则使用较少。

 

 

五、系统用例图的“画法”

1、  不要“网状化”

    很多人喜欢把分析后的所有用例用一张图来显示，小系统还好说，系统大了就成了张蜘蛛网，凌乱的很，我个人建议尽量不要“网状化”用例图，以便不知从何看起。

 

2、  层次性表述

    以多层的方式来渐渐细化用例，由大到小、由全局到局部的层层进行细化。这种类似于根与叶子方式，在后继的子系统分析，子模块分析也大有帮助。

 

3、  内聚性

    如果说层次是是一个纵向的表现方式，那么内聚性就是一个横向的表现方式。它一般用来规划一些较为完整的场景过程。比如我们的“管理唱片资料”就是一个较为内聚性的表现方式，当然内聚性的粗细粒度可结合具体的项目来定夺。

 

4、  主次有别

    在系统用例图中，并不一定所有的用例都要全部列入，在说明和解决问题时，我们其实大部分用例关系只需引入主要的用例即可。如果面面俱到就会出现“网状化”的现象，使得说明效果还适得其反。

 

5、  逐步完善

    每一个系统用例图都很难一步到位的进行提供，很多时候都是一个逐步完善的过程，在我参与的一些项目中有一些都是经过了几轮的迭代之后才基本稳定。