UML活动图_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
上传于||文档简介
&&x​i​e​ ​x​i​e​ ​g​u​a​n​ ​k​a​n
阅读已结束，如果下载本文需要使用
想免费下载本文？
你可能喜欢UML系统分析与设计02－用例图和活动图（下） - 推酷
UML系统分析与设计02－用例图和活动图（下）
& & &在上一篇《
》中，我们主要讲解了在需求分析中的用例分析和绘制的方法和技巧，但是用例图只告诉我们系统要“做什么”，至于“怎么做”却并没有很直观的描述。为了更形象的说明我们的系统是如何一一满足用户需求的，并向用户提供“怎么做”的细节描述，我们将使用“活动图”来对用例进行补充性说明。
[&注意：UML中并没有说“活动图”是用于对“用例图”补充说明，但就我个人而言我更喜欢这样来定义它，并在实践中进行应用。]
& & [&技巧：UML图一般会分为静态图和动态图。用例图属于静态图，而后而所述的“活动图”属于动态图。在我们对某个问题进行分析和设计时一般都会使用静态图和动态图相结合的方式来进行说明和描述。]
Activity Diagram
& & &（VS2010工具示例图）
活动图中的三板斧
& & &通过上图我们会发现，其实Activity Diagram还是有很多元素的，其实在我们的工作中你会发现在大部分时候我们并不需要对于这“十八般武艺”样样精通，其实只需三板斧即可！
& & &第一板：开始－结束
& & &第二板：分支－合并
& & &第三板：分叉－联结
& & &当然，要让这三板斧连贯起来我们还得有节点“Action”和线“Connector”。
(上面的命名为我个人习惯，可能有误)
& & &①：“创建唱片”示例：
& & &②：“管理订单”示例：
& & &③：当然还有很多其它的元素这里并没有提到，我们将在后继说明中陆续讲解，我个人认为在当前的分析阶断，重点用“三板斧”来解决。在架构设计和概要设计时我们还会用到其它的一些元素。
没有“泳道”
& & &“泳道”UML在进行“活动图”时，一个非常直观好用的工具，但在VS2010中去并未提供，很遗憾在最新的VS11Bate版中也未提供对“泳道”的支持，感兴趣的朋友也只能用替代方案了。方法如下：
& & &从“Sinple Shapes”中拖入一个“Rectangle”,分别设置它的“Line Thickness”为“0.01”、“Color”为“=DarkGray”。
& & &再从“UML Activity Diagram”中手入一个“Object Node”,并设置其属性“Color”为“Gainsboro”。
& & &以“创建唱片资料”为例，效果如下：
（此方案由
CSDN论坛中的网友提供，虽非正统，但也不错）
没有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.
& & &②：对应在视图中就是这样，呵呵。
困惑的“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示例图：
回锅“Artifact
& & &“Artifact”并非UML中定义的元素，但在用例图中是个非常不错的扩展，他的存在使的基于“用例驱动”的设计方案变得异常的方便。
& & &①、在VS2010中如何建立“Artifact”
& & &首先，我们建立相应的用例图，同时我们为不同的用例建立相应的活动图。如上图的“创建唱片资料用例图”和“创建唱片资料活动图”，在当前工作区中打开用例图。
& & &然后，在解决方案中选中相应的活动图，点击鼠标“左键”不放，然后拖动到用例图所在的工作区中，这时就会自动创建一个“Artifact”。
& & &最后，使用“Dependency”关系，使得特定用例和它对应的活动图进行关联，类图等也可采用同样方式进行关联。
& & &②、点评
& & &在此不得不为VS2010叫好，因为有了这个功能，所有复杂的设计都可以与用例进行关联，就如刚才的活动图，同样可以是以后的类图，时序图等。这也是即便有正版的VS2008也不用，改投VS2010的怀抱，因为它可以使的分析和设计如此的方便和灵活。可以使得分析和设计在不断的迭代中显示完善。
（是不是真的可以实现“文档去死”的梦想？）
其实在所有的元素都可能还带有一些特殊属性以表达更明确的意图，比如：Action有Body、Language、Localconditions等，Call Behavior Action有IsSynchronous、Behavior等，大家在使用时可以进行设置，以便表达更精准的意思。
需求分析演练
报道：今年CD/DVD高产，可是Music农们却高兴不起来，由于销路不畅，上好的CD/DVC旧在地摊上。为了帮助Music农解决销售问题，当地Z&F积极组织调研，最终决定与“MusicStore”合作，来提供一个能为Music农和购买者建立信息交互的平台，从而为Music农扩大产品销量、达到让Music农增产能增收的目的…..
& & &（此需求改编自“果农丰收，滞销，Z&F帮忙”）
& & &经过收集，我们决定对“MusicStore”增加以下需求，以便支持唱片的个人交易功能。
& & &①：求购者可以发布求购信息。
& & &②：求购者可以查询出售信息。
& & &③：出售者可以查询求购信息。
& & &④：出售者可以申请一个小店，并在小店中发布出售信息。（我们只收取少许服务费，你懂的）
& & &①：参考用例
& & &②：真理在哪？
& & &在上一文中我们说到了通过“somebody do something”的方式寻来找用例，也就是通过主谓宾的方式来发现事务的本质，以防止“定、状、补”等信息对我们认识事务本质的干扰，以便明确系统的真实意图！
& & &但是“颜回煮粥”的故事告诉我们“耳听为虚，眼见也不一定为实！”，即便是事实也要经得起推敲！
& & &而需求分析中的“推敲”就是对需求进行深入分析，接下来我们看看需求分析深入后对“Actor”的影响。
& & &在“①：参考用例”中我们原以为可以反映用户需求，但经过调查，我们发现某些Music农，对岛国的某些蓝光影视很感兴趣（正常渠道无法购得，常以二手“Music” 的方式出现）而这个时候“Music农”就不再是出售者，转身成为了购买者。也就是一个人他即可能是求购者，也可能是出售者。如果这样的话，当我们在处理“用户登录”这样的用例时就会很为难。
& & &经过分析，我们可能会认为其实我们并不要求细分“求购者”和“出售者”，而采用了类似“权限”来控制。而用例图就变成了类似如下：
& & &当然也有人提出了人员派生的方法来实现，类似：
& & &这也是一种常见的方法，但在本次需求中我个人并不十分推荐这样做，在分析的初期可能有用，但随着分析的深入，我们会发现“求购者”和“出售者”在系统中会被逐渐淡化，在最后的程序实现中可能跟本就不会出现。刚才我们也提到了“权限控制”的替代方案，最主要的是“派生和承继”隐含了“多态”，但在本次需求中要实现这样的“多态”有些困难，在此并不深究，后继会跟进。
（本文只作引导，不一定是最终的正确答案。）
& & &③：做个善于发现的人
& & &常言道，有什么样的要求，我就给什么样的设计。所对需求分析的好坏直接关系到产品的最终命运。作为一个负责任的需求分析人员一定要做到多思而后断，善于从不同的视角来审视、推敲同一样的需求。洞察用户的真实意图，发现需求背后的故事！
& & &比如：需求中有“小店”，为什么要“小店”？会不会有“市场”和“商城”？
& & &④：没有远见必有近忧！
& & & 不管是做项目还是做产品，都必定会面临“没有远见必有近忧”问题，这也正是很多公司对需求分析人员要求有一定的行业知识的重要性，对这一点我也很赞成。
& & &做项目时，用户可能会随时想起一些功能要求你实现，也许有些强势的项目经理会以《需求规格说明书》中没有定义而拒绝，但在现实生活动往往没这么容易。
& & &做产品时更甚，如果没有考虑好或设计好，对产品的后继发展将埋下祸根。
（对需求的深挖掘/
Digging Out Concepts
，DDD中叫隐喻/
Making implicit concepts Explicit
，我个人认为是很有必要的。虽然在项目管理理论中并不推荐进行“镀金”，但是在开发初期的“多谋善虑”一定是利大于弊。只是在最终的决策中我们可能要根据项目的不同目标，综合各方因素进行一定的平衡和取舍，但对某些具有显著特征的要求，那怕在需求中没有强烈要求，但在设计时也要留有余地。这也许会被人诟病为“过度设计”，但凡事都是一个度的问题，也很考验分析和设计人员的能力，因为有些事情是可以预知的，这也是附合产品的远景规划。）
& & &当这些都处理妥当后，那么我们的又一个重要的里程碑即将完成。即，输出《软件系统需求分析说明书》，下一讲中我们将给出一个说明书的较为典型的格式。
已发表评论数()
已收藏到推刊！
请填写推刊名
描述不能大于100个字符!
权限设置： 公开
仅自己可见
正文不准确
排版有问题
没有分页内容
视频无法显示
图片无法显示BI即商务智能，它是一套完整的解决方案..
微软12亿美元现金收购企业社交供应商Yamm..
解析使用Visio绘制UML序列图六大技巧
软网提示：本文和大家重点讨论一下UML序列图绘制技巧， 主要从六个方面向大家介绍，相信通过本文的学习你对绘制UML序列图的方法有一定的认本文和大家重点讨论一下UML序列图绘制技巧， 主要从六个方面向大家介绍，相信通过本文的学习你对绘制UML序列图的方法有一定的认识。UML序列图绘制技巧 请尝试本文所介绍的技巧来创建有效的UML序列图。本文改编自TheObjectPrimer2ndEdition的第6章。有一些方法可以帮助您提高UML序列图的质量和效力。它们包括：◆和主题问题专家一起验证决策◆使解决方案尽量简单◆为绘制消息和返回值选择一种一致而有效的风格◆将UML序列图分层◆遵循一致的逻辑风格◆牢记UML序列图是动态的　验证决策在开发图1序列图的过程中，我做了一些对其它模型可能有潜在影响的决策。例如，在对第10步建模时，假设（大致上是个设计决策）费用显示屏幕同时也处理学生对费用是否可接受所进行的验证。该决策应该由用户界面原型反映出来，并由主题问题专家(SME)进行验证。您应该和SME（特别是那些对于如何开发类似模型有着深刻见解的富有经验的人）一起执行序列图的绘制工作。保持简单在对第2和第3步建模时，我忽然意识到学生可能应该使用口令进入系统。在向SME提出了这个概念后发觉我错了：姓名和学号组合对于我们的目的来说已经足够唯一，并且学校也不希望增加复杂的口令管理。这是个很有意思的决策，因为这是学校的一个运作策略，所以可以作为一条商业规则记载到增补规范中。通过与SME一起检验这个想法，而不是假定我比他们知道得更多，我避免了&镀金&的机会，因而减少了我们小组开发这一系统所需的工作。绘制消息和返回值我更喜欢从左至右地绘制消息，从右至左地绘制返回值，尽管这样对于复杂的对象／类来说不总是非常合适。我将消息上的标签和返回值对齐到离箭头最近的位置。我不喜欢在序列图上标出返回值，为的是使图尽可能地简化。不过，始终标出返回值也同样有效，特别是在UML序列图用于设计而不是分析目的时。（我希望我的分析图尽量简单，而设计图尽量全面。）在分析期间，我的目标是理解逻辑和确保逻辑的正确性。而在设计期间，则要赋予消息精确的细节，如图1中的注释提醒我对&qualifications()&消息执行的任务。将序列图分层我喜欢将UML序列图从左至右地分层。先标出参与者，然后是控制器类，然后是用户界面类，最后是商业类。在设计期间，可能需要添加系统类和持久类，我通常将它们放在序列图的最右侧。以这种方式将序列图分层往往使它们更易于阅读，并且更容易找出分层逻辑问题，例如用户界面类直接访问持久类（在今后的建模技巧中将对此做更多介绍）。遵循一致的逻辑风格请注意，在图1UML序列图所示的过程中，逻辑风格做了部分更改。一开始，特别是在登录时，用户界面处理一些基本逻辑--而在选择研习班，以及稍后的验证时，则是控制器类进行处理。这实际上是个设计问题。我不会在这个问题上纠缠太久，但和往常一样，我建议选择一种适合于您的建模风格，然后始终如一地贯彻在所有序列图中。牢记序列图是动态的您可能听说过诸如动态建模和静态建模这样的术语，其他一些熟悉面向对象建模技术的开发人员常常会提到它们。您甚至可能听到过有关每种风格的优点的争论。软件开发网动态建模技术主要集中在标识系统中的行为，包括序列图的绘制和活动图的绘制（请参阅&如何绘制UML活动图&）以及UML协作图的绘制。而静态建模则集中在系统的静态方面，包括类、它们的属性，以及类之间的关联。类模型和持久／数据模型一样，都是静态建模的主要产物。因此实际上没有什么好争论的--要想恰如其分地说明面向对象系统，同时需要动态和静态建模技术。
Visio画UML图基本操作及技巧解析
掌握六大技巧轻松实现UML序列图绘制
Java建模：UML序列图
专家指导 如何在UML序列图中表示分支
养成良好的UML序列图绘制习惯&【责任编辑：程华权 TEL：（010）】
移动互联网正在重新定义企业，企业如何抢占移动互联时代发展先机？如何打破传统商业模式？如何寻找新的营销手段？在这里找到答案：