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