系统分析及其设计应用用例图和活动图.doc

每一种产品需求是对现实世界特定问题一种描述，而有些问题描述也许是非常错综复杂，以至在咱们对其进行分析时，会觉得无从下手甚至不知所措。 需求分析是系统设计和开发基本，需求分析好坏会直接影响后继设计和开发质量，严重时会影响到系统成败。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来区别不同边界。 例如：“管理员创立唱片资料”、“管理员修改唱片资料”和“管理员删除唱片资料”就可以以为是“管理唱片资料”这样一种边界。 由于VS并未提供Boundary功能，而是以subsystem来提供。为了更好阐明问题因此此处提供2张图，第二张由EA绘制。 有时咱们会把同一种边界内具备相对内聚性用例抽象成一种用例。 委拖，在进行用例分析时，当出既有些用例已超过了当前边界，但是与边界内某些用例又有较为紧密关系时，咱们往往可以考虑使有“委托”方式来，简化分析过程 。 就拿“客户结账”用例来说吧，它也许会引起出“系统查询帐户余额”、“系统转账”等一系列新用例出来。此时咱们也许会浮现，其实我目就是“结帐”，至于怎么结帐及结账细节并不是我在本场景重要议题，由此也允许以拟定“查询帐户余额”等已超过本用例边界，从而咱们可以“委托方式”委派给“银联系统付款”，从而一笔带过。 有时候咱们可以简朴以为“服务”就是边界外委托。 在分析中咱们可以先不关怀大象是如何放进冰箱，只关怀大象能不能放进冰箱！(此图来自互联网)4、 活用“Include”和“Extend”和“Generalization” 在用例会析中，少不了对“include”、“extern”和“Generaliztion”应用。Include:重要是指包括这些用例，包括并不指子用例就一定会同步发生。例如：管理管理唱片信息 新增唱片信息 修改唱片信息 删除唱片信息 导出唱片信息Extend：是指在满足某一状况时一定会触发某个用例。“客户结帐”在“未登录”状况下会 触发 “登录”用例。由于未发现VS提供extension points功能。为了更好阐明问题因此此处提供2张图，第二张由EA绘制。Generaliztion：泛化，在用例视图中我普通只用在Actor上面使用，在实际用例中则使用较少。五、系统用例图“画法”1、 不要“网状化” 诸多人喜欢把分析后所有用例用一张图来显示，小系统还好说，系统大了就成了张蜘蛛网，凌乱很，我个人建议尽量不要“网状化”用例图，以便不知从何看起。2、 层次性表述 以多层方式来徐徐细化用例，由大到小、由全局到局部层层进行细化。这种类似于根与叶子方式，在后继子系统分析，子模块分析也大有协助。3、 内聚性 如果说层次是是一种纵向体现方式，那么内聚性就是一种横向体现方式。它普通用来规划某些较为完整场景过程。例如咱们“管理唱片资料”就是一种较为内聚性体现方式，固然内聚性粗细粒度可结合详细项目来定夺。4、 主次有别 在系统用例图中，并不一定所有用例都要所有列入，在阐明和解决问题时，咱们其实大某些用例关系只需引入重要用例即可。如果面面俱到就会浮现“网状化”现象，使得阐明效果还适得其反。5、 逐渐完善 每一种系统用例图都很难一步到位进行提供，诸多时候都是一种逐渐完善过程，在我参加某些项目中有某些都是通过了几轮迭代之后才基本稳定。咱们重要解说了在需求分析中用例分析和绘制办法和技巧，但是用例图只告诉咱们系统要“做什么”，至于“怎么做”却并没有很直观描述。为了更形象阐明咱们系统是如何一一满足顾客需求，并向顾客提供“怎么做”细节描述，咱们将使用“活动图”来对用例进行补充性阐明。 注意：UML中并没有说“活动图”是用于对“用例图”补充阐明，但就我个人而言我更喜欢这样来定义它，并在实践中进行应用。 技巧：UML图普通会分为静态图和动态图。用例图属于静态图，而后而所述“活动图”属于动态图。在咱们对某个问题进行分析和设计时普通都会使用静态图和动态图相结合方式来进行阐明和描述。四、Activity Diagram （VS工具示例图）五、活动图1、活动图中三板斧 通过上图咱们会发现，其实Activity Diagram还是有诸多元素，其实在咱们工作中你会发当前大某些时候咱们并不需要对于这“十八般武艺”样样精通，其实只需三板斧即可！ 第一板：开始结束 第二板：分支合并 第三板：分叉联结 固然，要让这三板斧连贯起来咱们还得有节点“Action”和线“Connector”。 (上面命名为我个人习惯，也许有误)2、参照示例 ：“创立唱片”示例： ：“管理订单”示例： ：固然尚有诸多其他元素这里并没有提到，咱们将在后继阐明中陆续解说，我个人以为在当前分析阶断，重点用“三板斧”来解决。在架构设计和概要设计时咱们还会用到其他某些元素。3、没有“泳道” “泳道”UML在进行“活动图”时，一种非常直观好用工具，但在VS中去并未提供，很遗憾在最新VS11Bate版中也未提供对“泳道”支持，感兴趣朋友也只能用代替方案了。办法如下： 从“Sinple Shapes”中拖入一种“Rectangle”,分别设立它“Line Thickness”为“0.01”、“Color”为“=DarkGray”。 再从“UML Activity Diagram”中手入一种“Object Node”,并设立其属性“Color”为“Gainsboro”。 以“创立唱片资料”为例，效果如下： （此方案由CSDN论坛中网友提供，虽非正统，但也不错）4、没有Activity图 在VS中并未直接提供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 inUML 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” 在上一点中，咱们说了在VS元素中并没有正规Activity图，那么“Activity Parameter Node”就显得“生不缝时”或是“文不对题”了。在实际应用中叫成“Action Parameter Node”与否更适当呢？这与“Input Pin”和“Output Pin”又有何本质区别呢（关于Input Pin和Output Pin在实践应用将在后继解说）？ 我个人觉得“Activity Parameter Node”定义与原则UML定义并不相符。（微软向来都不太尊重原则，实用就行！） 如下摘自OMGUML2.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. ：示例图 :再上一种VS示例图：6、回锅“Artifact”。 “Artifact”并非UML中定义元素，但在用例图中是个非常不错扩展，她存在使基于“用例驱动”设计方案变得异常以便。 、在VS中如何建立“Artifact” 一方面，咱们建立相应用例图，同步咱们为不同用例建立相应活动图。如上图“创立唱片资料用例图”和“创立唱片资料活动图”，在当前工作区中打开用例图。 然后，在解决方案中选中相应活动图，点击鼠标“左键”不放，然后拖动到用例图所在工作区中，这时就会自动创立一种“Artifact”。 最后，使用“Dependency”关系，使得特定用例和它相应活动图进行关联，类图等也可采用同样方式进行关联。 、点评 在此不得不为VS叫好，由于有了这个功能，所有复杂设计都可以与用例进行关联，就如刚才活动图，同样可以是后来类图，时序图等。这也是即便有正版VS也不用，改投VS怀抱，由于它可以使分析和设计如此以便和灵活。可以使得分析和设计在不断迭代中显示完善。 （是不是真可以实现“文档去死”梦想？）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、输出 当这些都解决妥当后，那么咱们又一种重要里程碑即将完毕。即，输出软件系统需求分析阐明书，下一讲中咱们将给出一种阐明书较为典型格式。