UML,统一建模语言，在软件系统分析和设计中被广泛应用。作为一个初学者，我们总会感觉UML很复杂，有时候会感觉不知从何下手，有时会候也会困惑不同的UML图应该用在什么场合才较为合适。

我记得很多年前我看到别人含有UML图例的文档时就觉得这文档很上档次，当然我也见过公司里有些人故意在文档放些UML图，自以为得意，但最终却没把意思表述清楚，有些表述甚至是错的。所以我们大可不必太把UML当回事，虽然他在系统分析和设计过程中用的越来越多，但我们不要为了UML而UML，UML只是一种语言，是一种工具，是为我们开发和设计服务的，系统开发和设计的核心是思想，所有的工具只是为了更好的表述这种思想。

前些天在某技术论坛里看到一帖子，想请大家帮忙看看他的用例图，并提一点建议和意见。尚不去讨论他的图质量如何，但从一个侧面就反映了在我们软件开发过程中对UML的要求和使用是越来越多、越来越广。当然，期间我也看到有些大牛关于UML无用论的发言，我是觉得是偏激了。就我个人的从业经历来看，UML还是很重要的，特别是在设计岗位上的朋友。

这里就我个人的一些UML在系统分析和设计过程中的一些体会拿了来与大家交流一下，一起学习一起进步。主要目的是交流如何结合UML输出《软件需求分析说明书》、《系统架构说明书》和《概要设计说明书》。 当然对反对架构、反对文档、反对条条框框，追求极限敏捷的朋友，您基本上可以就此return了。

在后面对基于UML的分析和设计是以面向对象设计思想为基础的，同时借助于VS2010开发工具进行UML绘制。

对于没有安装VS2010的朋友也可以使用“Enterprise Architect”，“PowerDesigner”等其它UML工具。最早我是用PowerDesigner的，后来由于版权问题公司禁止了，然后改用Enterprise Architect。至于Rose很久没用了，早期由于其对.net的支持不太友好而弃用。目前基本上用VS2010，VS2010绘的图不仅色彩很好，更主要的是方便设计与开发的统一，可以在统一的解决方案中进行管理。如图：

当然VS2010也有不足之处，没有提供对“需求管理”的支持，同样没有对数据库设计的支持，相反“Enterprise Architect”却更胜一筹，当然VS2010可能更侧重于开发和测试，再者大部分人可能更喜欢用WORD来管理需求。

接下来先简单的介绍一下VS2010中UML的使用方法和步骤。

1、新增项目，选择“Modeling Projects”。

2、新增后解决方案多一项目。

3、在新增项，这里就先加一个“用例”吧。

4、增加完后解决方案类似，大本解决方案中为了方便管理，增加了一些目录（文件夹）。

5、本系列将会以参考“MVC Music Store”的部分需求（主要是简单），当然只为说明问题不一定完全照抄。

用例图和活动图（上）

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

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

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

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

在上一篇《UML系统分析与设计02－用例图和活动图（上）》中，我们主要讲解了在需求分析中的用例分析和绘制的方法和技巧，但是用例图只告诉我们系统要“做什么”，至于“怎么做”却并没有很直观的描述。为了更形象的说明我们的系统是如何一一满足用户需求的，并向用户提供“怎么做”的细节描述，我们将使用“活动图”来对用例进行补充性说明。

[ 注意：UML中并没有说“活动图”是用于对“用例图”补充说明，但就我个人而言我更喜欢这样来定义它，并在实践中进行应用。]

[ 技巧：UML图一般会分为静态图和动态图。用例图属于静态图，而后而所述的“活动图”属于动态图。在我们对某个问题进行分析和设计时一般都会使用静态图和动态图相结合的方式来进行说明和描述。]

四、 Activity Diagram

（VS2010工具示例图）

五、活动图

1、 活动图中的三板斧

通过上图我们会发现，其实Activity Diagram还是有很多元素的，其实在我们的工作中你会发现在大部分时候我们并不需要对于这“十八般武艺”样样精通，其实只需三板斧即可！

第一板：开始－结束

第二板：分支－合并

第三板：分叉－联结

当然，要让这三板斧连贯起来我们还得有节点“Action”和线“Connector”。

(上面的命名为我个人习惯，可能有误)

2、 参考示例

①：“创建唱片”示例：

②：“管理订单”示例：

③：当然还有很多其它的元素这里并没有提到，我们将在后继说明中陆续讲解，我个人认为在当前的分析阶断，重点用“三板斧”来解决。在架构设计和概要设计时我们还会用到其它的一些元素。

3、 没有“泳道”

“泳道”UML在进行“活动图”时，一个非常直观好用的工具，但在VS2010中去并未提供，很遗憾在最新的VS11Bate版中也未提供对“泳道”的支持，感兴趣的朋友也只能用替代方案了。方法如下：

从“Sinple Shapes”中拖入一个“Rectangle”,分别设置它的“Line Thickness”为“0.01”、“Color”为“=DarkGray”。

再从“UML Activity Diagram”中手入一个“Object Node”,并设置其属性“Color”为“Gainsboro”。

以“创建唱片资料”为例，效果如下：

（此方案由CSDN论坛中的网友提供，虽非正统，但也不错）

4、 没有Activity图

在VS2010中并未直接提供UML中标准的“Activity”图。

①：按MSDN上对Activity的解释如下：

The flow of work that is depicted by an activity diagram. To see the properties of an activity, you must select it in UML Model Explorer.

• Is Read Only - If true, the activity should not change the state of any object.
• Is Single Execution - If true, there is at most one execution of this diagram at a time.

②：对应在视图中就是这样，呵呵。

5、 困惑的“Activity Parameter Node”

在上一点中，我们说了在VS2010的元素中并没有正规的Activity图，那么“Activity Parameter Node”就显得“生不缝时”或是“文不对题”了。在实际应用中叫成“Action Parameter Node”是否更合适呢？这与“Input Pin”和“Output Pin”又有何本质区别呢（关于Input Pin和Output Pin在实践应用将在后继讲解）？

我个人觉得“Activity Parameter Node”的定义与标准UML定义并不相符。（微软向来都不太尊重标准，实用就行！）

以下摘自OMG《UML2.0 Superstructure Specification》对“Activity parameter nodes”的部分说明：

①：Activity parameter nodes are displayed on the border.

②：An activity parameter node is an object node for inputs and outputs to activities.

③：示例图

④:再上一个VS2010示例图：

6、 回锅“Artifact”。

“Artifact”并非UML中定义的元素，但在用例图中是个非常不错的扩展，他的存在使的基于“用例驱动”的设计方案变得异常的方便。

①、在VS2010中如何建立“Artifact”

首先，我们建立相应的用例图，同时我们为不同的用例建立相应的活动图。如上图的“创建唱片资料用例图”和“创建唱片资料活动图”，在当前工作区中打开用例图。

然后，在解决方案中选中相应的活动图，点击鼠标“左键”不放，然后拖动到用例图所在的工作区中，这时就会自动创建一个“Artifact”。

最后，使用“Dependency”关系，使得特定用例和它对应的活动图进行关联，类图等也可采用同样方式进行关联。

②、点评

在此不得不为VS2010叫好，因为有了这个功能，所有复杂的设计都可以与用例进行关联，就如刚才的活动图，同样可以是以后的类图，时序图等。这也是即便有正版的VS2008也不用，改投VS2010的怀抱，因为它可以使的分析和设计如此的方便和灵活。可以使得分析和设计在不断的迭代中显示完善。

（是不是真的可以实现“文档去死”的梦想？）

7、 属性

其实在所有的元素都可能还带有一些特殊属性以表达更明确的意图，比如：Action有Body、Language、Localconditions等，Call Behavior Action有IsSynchronous、Behavior等，大家在使用时可以进行设置，以便表达更精准的意思。

六、 需求分析演练

1、 需求背景

据CCAV报道：今年CD/DVD高产，可是Music农们却高兴不起来，由于销路不畅，上好的CD/DVC旧在地摊上。为了帮助Music农解决销售问题，当地Z&F积极组织调研，最终决定与“MusicStore”合作，来提供一个能为Music农和购买者建立信息交互的平台，从而为Music农扩大产品销量、达到让Music农增产能增收的目的…..

（此需求改编自“果农丰收，滞销，Z&F帮忙”）

2、 需求收集

经过收集，我们决定对“MusicStore”增加以下需求，以便支持唱片的个人交易功能。

①：求购者可以发布求购信息。

②：求购者可以查询出售信息。

③：出售者可以查询求购信息。

④：出售者可以申请一个小店，并在小店中发布出售信息。（我们只收取少许服务费，你懂的）

3、 需求分析

①：参考用例

②：真理在哪？

在上一文中我们说到了通过“somebody do something”的方式寻来找用例，也就是通过主谓宾的方式来发现事务的本质，以防止“定、状、补”等信息对我们认识事务本质的干扰，以便明确系统的真实意图！

但是“颜回煮粥”的故事告诉我们“耳听为虚，眼见也不一定为实！”，即便是事实也要经得起推敲！

而需求分析中的“推敲”就是对需求进行深入分析，接下来我们看看需求分析深入后对“Actor”的影响。

在“①：参考用例”中我们原以为可以反映用户需求，但经过调查，我们发现某些Music农，对岛国的某些蓝光影视很感兴趣（正常渠道无法购得，常以二手“Music” 的方式出现）而这个时候“Music农”就不再是出售者，转身成为了购买者。也就是一个人他即可能是求购者，也可能是出售者。如果这样的话，当我们在处理“用户登录”这样的用例时就会很为难。

经过分析，我们可能会认为其实我们并不要求细分“求购者”和“出售者”，而采用了类似“权限”来控制。而用例图就变成了类似如下：

当然也有人提出了人员派生的方法来实现，类似：

这也是一种常见的方法，但在本次需求中我个人并不十分推荐这样做，在分析的初期可能有用，但随着分析的深入，我们会发现“求购者”和“出售者”在系统中会被逐渐淡化，在最后的程序实现中可能跟本就不会出现。刚才我们也提到了“权限控制”的替代方案，最主要的是“派生和承继”隐含了“多态”，但在本次需求中要实现这样的“多态”有些困难，在此并不深究，后继会跟进。

（本文只作引导，不一定是最终的正确答案。）

③：做个善于发现的人

常言道，有什么样的要求，我就给什么样的设计。所对需求分析的好坏直接关系到产品的最终命运。作为一个负责任的需求分析人员一定要做到多思而后断，善于从不同的视角来审视、推敲同一样的需求。洞察用户的真实意图，发现需求背后的故事！

比如：需求中有“小店”，为什么要“小店”？会不会有“市场”和“商城”？

④：没有远见必有近忧！

不管是做项目还是做产品，都必定会面临“没有远见必有近忧”问题，这也正是很多公司对需求分析人员要求有一定的行业知识的重要性，对这一点我也很赞成。

做项目时，用户可能会随时想起一些功能要求你实现，也许有些强势的项目经理会以《需求规格说明书》中没有定义而拒绝，但在现实生活动往往没这么容易。

做产品时更甚，如果没有考虑好或设计好，对产品的后继发展将埋下祸根。

（对需求的深挖掘/Digging Out Concepts，DDD中叫隐喻/Making implicit concepts Explicit，我个人认为是很有必要的。虽然在项目管理理论中并不推荐进行“镀金”，但是在开发初期的“多谋善虑”一定是利大于弊。只是在最终的决策中我们可能要根据项目的不同目标，综合各方因素进行一定的平衡和取舍，但对某些具有显著特征的要求，那怕在需求中没有强烈要求，但在设计时也要留有余地。这也许会被人诟病为“过度设计”，但凡事都是一个度的问题，也很考验分析和设计人员的能力，因为有些事情是可以预知的，这也是附合产品的远景规划。）

4、 输出

当这些都处理妥当后，那么我们的又一个重要的里程碑即将完成。即，输出《软件系统需求分析说明书》，下一讲中我们将给出一个说明书的较为典型的格式。