UML系统分析与设计02-用例图和活动图.docx
《UML系统分析与设计02-用例图和活动图.docx》由会员分享,可在线阅读,更多相关《UML系统分析与设计02-用例图和活动图.docx(20页珍藏版)》请在得力文库 - 分享文档赚钱的网站上搜索。
1、每一个产品的需求是对现实世界特定问题的一种描述,而有些问题描述可能是格外的错综简单,以至在我们对其进展分析时,会觉得无从下手甚至不知所措。需求分析是系统设计和开发的根底,需求分析的好坏会直接影响后继设计和开发的质 量,严峻时会影响到系统的成败。UML 中的用例图就是为了便利我们分析与沟通产品需求而生,同时也为我们把产品需求转化为系统需求供给便利。产品需求:一般反映的是现场的具表达象,常常是由产品工程师/销售人员收集或由用户直接供给,表现的较为松散、粗放,是一种比较切合现实的描述。系统需求:一般是在对产品需求进展肯定的分析后,对其中不能实现或实现起来有困难的局部进展了肯定的取舍,同时对一些较为笼
2、统的需求进展明确和细化甚,至会对一些 需求进展了肯定的抽象和重组。 :/fz.qqq23 有时也会结合具体应用参加了一些规律的描述即现实以外的抽象术语,表现的更加切合软件系统。一般在评审通过后,系统需求会以产品需求规格说明说的方式供给,并成为系统开发的范围依据。接下来我将介绍一下本人在用例分析过程中的一些心得和休会。一、“Somebody do something”模式在我们对需求进展分析时,我们可以本着“Somebody do something”的模式来查找用例/关键用例,固然这里的“somebody”可以泛指人、物或其它系统等。我们可以以“做某件事”作为一个用例,而后成为系统的一项功能,
3、即满足一点需求。假设能 DO 完全部的THINGS,那么我们的系统也就成了。二、用例分析要留意事项1、单一场景,即每一个用例只为说明一件事,我个人反对包罗万象的“上帝”用例。2、简洁原则,即每一个用例要通俗易懂,能格外明确、简洁地说明其某项功能和作用,无任何歧义及多余的想象空间。3、唯一性,即每一件事/场景只能消灭一次, :/ 假设其它地方要用到同样的场景可以承受“引用”的方式进展组合。三、分而治之个个击破的思想1、 N 阶的问题在对员工面试时,我一般会问一个“汉诺塔”的问题,在这个过程中我并不看重答案, 只在呼解决问题的方法。即递归中是如何把“N 阶的问题转化成 N-1 阶,最终成为 1 阶
4、的问题”的思想。其实需求分析也是一个要把错综简单的 N 阶问题,最终转化成 1 阶问题的过程,这种从N 至 1 的方法不仅在需求分析中能用上,其实在后继的其他设计中也一样很有用。2、 自上而下或自下而上对需求的分析我们是可以承受自上而下或自下而上的进展分析,信任这些大家都有耳 闻,在此不做详述。就我个人而言比较宠爱“自上而下”的分析方法,即由“宏观”到“微观”的过程,其实有点像我们任务分解中的 WBS 分解方式。对需求中描述的场景和所要解决的问题应用“单一场景”、“简洁原则”和“唯一性”逐一分解, 至到符合要求为止。拿我们的“MusicStore”工程来说吧,系统无非是“系统出售唱片”固然这个
5、需求有点简洁,但要满足这个要求就得供给“治理员供给唱片”和“客户购置唱片”等功能。以此类推“治理员供给唱片”可能会引发“治理员创立唱片资料”、“治理员修改唱片资料”和“治理员删除唱 片资料”等的功能;同样“客户购置唱片”可能引发“客户添加唱片到购物车”、“客户移除购物车中的唱片”和“客户结帐”等功能。如此反复递归,我们最终会觉察似乎用户要的功能我 们都能供给且足“单一场景”、“简洁原则”和“唯一性”的要求。假设真是如此,那么我们的分析过程根本也就告一段落,之所以说是告一段落,是由于一些简单的需求只对其表象进展分 析是远远不够的,还得站在更高的全局的视角来进一步打量,可能还得对其进展肯定的重组
6、甚至抽象,直到满足系统的要求,后继我们将会有相关的例子。3、 边界和托付边界,在需求定义的场景中,有一局部场景他们的工作背景和工作方式都比较类似,且彼此之间有着较为严密的联系,那么这些用例就可以组成一个相对封闭的区间,这就是用例边界。有时候我们也会依据不同的actor 来区分不同的边界。比方:“治理员创立唱片资料”、“治理员修改唱片资料”和“治理员删除唱片资料”就可以认为是“治理唱片资料”这样一个边界。由于 VS2010 并未供给Boundary 功能,而是以subsystem 来供给。为了更好的说明问题所以此处供给2 张图,其次张由EA 绘制。有时我们会把同一个边界内具有相对内聚性的用例抽象
7、成一个用例。委拖,在进展用例分析时,当消灭有些用例已超出了当前的边界,但是与边界内的一些用例又有较为严密的关系时,我们往往可以考虑使有“托付”的方式来,简化分析过程 。就拿“客户结账”用例来说吧,它可能会引发出“系统查询帐户余额”、“系统转账”等一系列的用例出来。此时我们可能会消灭,其实我的目的就是“结帐”,至于怎么结帐及结账的细节并不是我在本场景的主要议题,由此可能可以确定“查询帐户余额”等已超出本用例的边界,从而我们可以“托付的方式”委派给“银联系统付款”,从而一笔带过。有时候我们可以简洁的认为“效劳”就是边界外的托付。在分析中我们可以先不关心大象是怎样放进冰箱的,只关心大象能不能放进冰箱
8、!(此图来自互联网)4、 活用“Include”和“Extend”和“Generalization”在用例会析中,少不了对“include”、“extern”和“Generaliztion”的应用。Include:主要是指包含这些用例,包含并不指子用例就肯定会同时发生。比方:治理治理唱片信息 增唱片信息 修改唱片信息 删除唱片信息 导出唱片信息Extend :是指在满足某一状况时肯定会触发某个用例。“客户结帐”在“未登录”的状况下会 触发 “登录”用例。由于未觉察VS2010 供给extension points 的功能。为了更好的说明问题所以此处供给2 张图,其次张由EA 绘制。Genera
9、liztion:泛化,在用例视图中我一般只用在Actor 上面使用,在实际的用例中则使用较少。五、系统用例图的“画法”1、 不要“网状化”很多人宠爱把分析后的全部用例用一张图来显示,小系统还好说,系统大了就成了张蜘蛛网,凌乱的很,我个人建议尽量不要“网状化”用例图,以便不知从何看起。2、 层次性表述以多层的方式来渐渐细化用例,由大到小、由全局到局部的层层进展细化。这种类似于根与叶子方式,在后继的子系统分析,子模块分析也大有帮助。3、 内聚性假设说层次是是一个纵向的表现方式,那么内聚性就是一个横向的表现方式。它一般用来规划一些较为完整的场景过程。比方我们的“治理唱片资料”就是一个较为内聚性的表现
10、方式,固然内聚性的粗细粒度可结合具体的工程来定夺。4、 主次有别在系统用例图中,并不肯定全部的用例都要全部列入,在说明和解决问题时,我们其实大局部用例关系只需引入主要的用例即可。假设面面俱到就会消灭“网状化”的现象,使得说明效果还适得其反。5、 逐步完善每一个系统用例图都很难一步到位的进展供给,很多时候都是一个逐步完善的过程,在我参与的一些工程中有一些都是经过了几轮的迭代之后才根本稳定。我们主要讲解了在需求分析中的用例分析和绘制的方法和技巧,但是用例图只告知我们系统要“做什么”,至于“怎么做”却并没有很直观的描述。为了更形象的说明我们的系统是如何一一满足用户需求的,并向用户供给“怎么做”的细节
11、描述,我们将使用“活动图”来对用例进展补充性说明。 留意:UML 中并没有说“活动图”是用于对“用例图”补充说明,但就我个人而言我更宠爱这样来定义它,并在实践中进展应用。 技巧:UML 图一般会分为静态图和动态图。用例图属于静态图,而后而所述的“活动图”属于动态图。在我们对某个问题进展分析和设计时一般都会使用静态图和动态图相结合的方式来进展说明和描述。四、 Activity DiagramVS2010 工具例如图五、活动图1、 活动图中的三板斧通过上图我们会觉察,其实 Activity Diagram 还是有很多元素的,其实在我们的工作中你会觉察在大局部时候我们并不需要对于这“十八般武艺”样样
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- UML 系统分析 设计 02 用例图 活动
限制150内