![系统分析与设计用例图和活动图_第1页](http://file4.renrendoc.com/view/f1004086e0f310ce4b7b072a700bed2e/f1004086e0f310ce4b7b072a700bed2e1.gif)
![系统分析与设计用例图和活动图_第2页](http://file4.renrendoc.com/view/f1004086e0f310ce4b7b072a700bed2e/f1004086e0f310ce4b7b072a700bed2e2.gif)
![系统分析与设计用例图和活动图_第3页](http://file4.renrendoc.com/view/f1004086e0f310ce4b7b072a700bed2e/f1004086e0f310ce4b7b072a700bed2e3.gif)
![系统分析与设计用例图和活动图_第4页](http://file4.renrendoc.com/view/f1004086e0f310ce4b7b072a700bed2e/f1004086e0f310ce4b7b072a700bed2e4.gif)
![系统分析与设计用例图和活动图_第5页](http://file4.renrendoc.com/view/f1004086e0f310ce4b7b072a700bed2e/f1004086e0f310ce4b7b072a700bed2e5.gif)
版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领
文档简介
每一个产品的需求是对现实世界特定问题的一种描述,而有些问题描述也许是非常的错综复杂,以至在我们对其进行分析时,会觉得无从下手甚至不知所措。
需求分析是系统设计和开发的基础,需求分析的好坏会直接影响后继设计和开发的质量,严重时会影响到系统的成败。UML中的用例图就是为了方便我们分析与交流产品需求而生,同时也为我们把产品需求转化为系统需求提供方便。
产品需求:一般反映的是现场的具体现象,经常是由产品工程师/销售人员收集或由用户直接提供,表现的较为松散、粗放,是一种比较切合现实的描述。
系统需求:一般是在对产品需求进行一定的分析后,对其中不能实现或实现起来有困难的部分进行了一定的取舍,同时对一些较为笼统的需求进行明确和细化,甚至会对一些需求进行了一定的抽象和重组。有时也会结合具体应用加入了一些逻辑的描述(即现实以外的抽象术语),表现的更加切合软件系统。一般在评审通过后,系统需求会以《产品需求规格说明说》的方式提供,并成为系统开发的范围依据。
接下来我将介绍一下本人在用例分析过程中的一些心得和休会。
一、“Somebodydosomething”模式
在我们对需求进行分析时,我们可以本着“Somebodydosomething”的模式来寻找用例/关键用例,当然这里的“somebody”可以泛指人、物或其它系统等。我们可以以“做某件事”作为一个用例,而后成为系统的一项功能,即满足一点需求。假如能DO完所有的THINGS,那么我们的系统也就成了。
二、用例分析要注意事项1、单一场景,即每一个用例只为说明一件事,我个人反对包罗万象的“上帝”用例。
2、简朴原则,即每一个用例要通俗易懂,能非常明确、简洁地说明其某项功能和作用,无任何歧义及多余的想象空间。
3、唯一性,即每一件事/场景只能出现一次,假如其它地方要用到同样的场景可以采用“引用”的方式进行组合。
三、分而治之个个击破的思想1、
N阶的问题
在对新员工面试时,我一般会问一个“汉诺塔”的问题,在这个过程中我并不看重答案,只在呼解决问题的方法。即递归中是如何把“N阶的问题转化成N-1阶,最后成为1阶的问题”的思想。其实需求分析也是一个要把错综复杂的N阶问题,最后转化成1阶问题的过程,这种从N至1的方法不仅在需求分析中能用上,其实在后继的其他设计中也同样很有用。
2、
自上而下或自下而上
对需求的分析我们是可以采用自上而下或自下而上的进行分析,相信这些大家都有耳闻,在此不做详述。就我个人而言比较喜欢“自上而下”的分析方法,即由“宏观”到“微观”的过程,其实有点像我们任务分解中的WBS分解方式。对需求中描述的场景和所要解决的问题应用“单一场景”、“简朴原则”和“唯一性”逐个分解,至到合乎规定为止。
拿我们的“MusicStore”项目来说吧,系统无非是“系统出售唱片”(当然这个需求有点简朴),但要满足这个规定就得提供“管理员提供唱片”和“客户购买唱片”等功能。以此类推“管理员提供唱片”也许会引发“管理员创建唱片资料”、“管理员修改唱片资料”和“管理员删除唱片资料”等新的功能;同样“客户购买唱片”也许引发“客户添加唱片到购物车”、“客户移除购物车中的唱片”和“客户结帐”等功能。如此反复递归,我们最后会发现仿佛用户要的功能我们都能提供且足“单一场景”、“简朴原则”和“唯一性”的规定。假如真是如此,那么我们的分析过程基本也就告一段落,之所以说是告一段落,是由于一些复杂的需求只对其表象进行分析是远远不够的,还得站在更高的全局的视角来进一步审阅,也许还得对其进行一定的重组甚至抽象,直到满足系统的规定,后继我们将会有相关的例子。
3、
边界和委托
边界,在需求定义的场景中,有一部分场景他们的工作背景和工作方式都比较类似,且彼此之间有着较为紧密的联系,那么这些用例就可以组成一个相对封闭的区间,这就是用例边界。
有时候我们也会根据不同的actor来区分不同的边界。
比如:“管理员创建唱片资料”、“管理员修改唱片资料”和“管理员删除唱片资料”就可以认为是“管理唱片资料”这样一个边界。
由于VS2023并未提供Boundary功能,而是以subsystem来提供。为了更好的说明问题所以此处提供2张图,第二张由EA绘制。
有时我们会把同一个边界内具有相对内聚性的用例抽象成一个用例。
委拖,在进行用例分析时,当出现有些用例已超过了当前的边界,但是与边界内的一些用例又有较为紧密的关系时,我们往往可以考虑使有“委托”的方式来,简化分析过程。
就拿“客户结账”用例来说吧,它也许会引发出“系统查询帐户余额”、“系统转账”等一系列新的用例出来。此时我们也许会出现,其实我的目的就是“结帐”,至于怎么结帐及结账的细节并不是我在本场景的重要议题,由此也许可以拟定“查询帐户余额”等已超过本用例的边界,从而我们可以“委托的方式”委派给“银联系统付款”,从而一笔带过。
有时候我们可以简朴的认为“服务”就是边界外的委托。
在分析中我们可以先不关心大象是如何放进冰箱的,只关心大象能不能放进冰箱!(此图来自互联网)
4、
活用“Include”和“Extend”和“Generalization”
在用例会析中,少不了对“include”、“extern”和“Generaliztion”的应用。Include:重要是指包含这些用例,包含并不指子用例就一定会同时发生。比如:管理管理唱片信息新增唱片信息修改唱片信息删除唱片信息导出唱片信息
Extend:是指在满足某一情况时一定会触发某个用例。“客户结帐”在“未登录”的情况下会触发“登录”用例。由于未发现VS2023提供extensionpoints的功能。为了更好的说明问题所以此处提供2张图,第二张由EA绘制。
Generaliztion:泛化,在用例视图中我一般只用在Actor上面使用,在实际的用例中则使用较少。
五、系统用例图的“画法”1、
不要“网状化”
很多人喜欢把分析后的所有用例用一张图来显示,小系统还好说,系统大了就成了张蜘蛛网,凌乱的很,我个人建议尽量不要“网状化”用例图,以便不知从何看起。
2、
层次性表述
以多层的方式来渐渐细化用例,由大到小、由全局到局部的层层进行细化。这种类似于根与叶子方式,在后继的子系统分析,子模块分析也大有帮助。
3、
内聚性
假如说层次是是一个纵向的表现方式,那么内聚性就是一个横向的表现方式。它一般用来规划一些较为完整的场景过程。比如我们的“管理唱片资料”就是一个较为内聚性的表现方式,当然内聚性的粗细粒度可结合具体的项目来定夺。
4、
主次有别
在系统用例图中,并不一定所有的用例都要所有列入,在说明和解决问题时,我们其实大部分用例关系只需引入重要的用例即可。假如面面俱到就会出现“网状化”的现象,使得说明效果还适得其反。
5、
逐步完善
每一个系统用例图都很难一步到位的进行提供,很多时候都是一个逐步完善的过程,在我参与的一些项目中有一些都是通过了几轮的迭代之后才基本稳定。我们重要讲解了在需求分析中的用例分析和绘制的方法和技巧,但是用例图只告诉我们系统要“做什么”,至于“怎么做”却并没有很直观的描述。为了更形象的说明我们的系统是如何一一满足用户需求的,并向用户提供“怎么做”的细节描述,我们将使用“活动图”来对用例进行补充性说明。
[
注意:UML中并没有说“活动图”是用于对“用例图”补充说明,但就我个人而言我更喜欢这样来定义它,并在实践中进行应用。]
[
技巧:UML图一般会分为静态图和动态图。用例图属于静态图,而后而所述的“活动图”属于动态图。在我们对某个问题进行分析和设计时一般都会使用静态图和动态图相结合的方式来进行说明和描述。]
四、
ActivityDiagram
(VS2023工具示例图)
五、活动图1、活动图中的三板斧
通过上图我们会发现,其实ActivityDiagram还是有很多元素的,其实在我们的工作中你会发现在大部分时候我们并不需要对于这“十八般武艺”样样精通,其实只需三板斧即可!
第一板:开始-结束
第二板:分支-合并
第三板:分叉-联结
当然,要让这三板斧连贯起来我们还得有节点“Action”和线“Connector”。
(上面的命名为我个人习惯,也许有误)
2、参考示例
①:“创建唱片”示例:
②:“管理订单”示例:
③:当然尚有很多其它的元素这里并没有提到,我们将在后继说明中陆续讲解,我个人认为在当前的分析阶断,重点用“三板斧”来解决。在架构设计和概要设计时我们还会用到其它的一些元素。
3、没有“泳道”
“泳道”UML在进行“活动图”时,一个非常直观好用的工具,但在VS2023中去并未提供,很遗憾在最新的VS11Bate版中也未提供对“泳道”的支持,感爱好的朋友也只能用替代方案了。方法如下:
从“SinpleShapes”中拖入一个“Rectangle”,分别设立它的“LineThickness”为“0.01”、“Color”为“=DarkGray”。
再从“UMLActivityDiagram”中手入一个“ObjectNode”,并设立其属性“Color”为“Gainsboro”。
以“创建唱片资料”为例,效果如下:
(此方案由CSDN论坛中的网友提供,虽非正统,但也不错)
4、没有Activity图
在VS2023中并未直接提供UML中标准的“Activity”图。
①:按MSDN上对Activity的解释如下:
Theflowofworkthatisdepictedbyanactivitydiagram.Toseethepropertiesofanactivity,youmustselectitin
UMLModelExplorer.IsReadOnly
-Iftrue,theactivityshouldnotchangethestateofanyobject.IsSingleExecution
-Iftrue,thereisatmostoneexecutionofthisdiagramatatime.
②:相应在视图中就是这样,呵呵。
5、困惑的“ActivityParameterNode”
在上一点中,我们说了在VS2023的元素中并没有正规的Activity图,那么“ActivityParameterNode”就显得“生不缝时”或是“文不对题”了。在实际应用中叫成“ActionParameterNode”是否更合适呢?这与“InputPin”和“OutputPin”又有何本质区别呢(关于InputPin和OutputPin在实践应用将在后继讲解)?
我个人觉得“ActivityParameterNode”的定义与标准UML定义并不相符。(微软向来都不太尊重标准,实用就行!)
以下摘自OMG《UML2.0SuperstructureSpecification》对“Activityparameternodes”的部分说明:
①:Activityparameternodesaredisplayedontheborder.
②:Anactivityparameternodeisanobjectnodeforinputsandoutputstoactivities.
③:示例图
④:再上一个VS2023示例图:
6、回锅“Artifact”。
“Artifact”并非UML中定义的元素,但在用例图中是个非常不错的扩展,他的存在使的基于“用例驱动”的设计方案变得异常的方便。
①、在VS2023中如何建立“Artifact”
一方面,我们建立相应的用例图,同时我们为不同的用例建立相应的活动图。如上图的“创建唱片资料用例图”和“创建唱片资料活动图”,在当前工作区中打开用例图。
然后,在解决方案中选中相应的活动图,点击鼠标“左键”不放,然后拖动到用例图所在的工作区中,这时就会自动创建一个“Artifact”。
最后,使用“Dependency”关系,使得特定用例和它相应的活动图进行关联,类图等也可采用同样方式进行关联。
②、点评
在此不得不为VS2023叫好,由于有了这个功能,所有复杂的设计都可以与用例进行关联,就如刚才的活动图,同样可以是以后的类图,时序图等。这也是即便有正版的VS2023也不用,改投VS2023的怀抱,由于它可以使的分析和设计如此的方便和灵活。可以使得分析和设计在不断的迭代中显示完善。
(是不是真的可以实现“文档去死”的梦想?)
7、属性其实在所有的元素都也许还带有一些特殊属性以表达更明确的意图,比如:Action有Body、Language、Localconditions等,CallBehaviorAction有IsSynchronous、Behavior等,大家在使用时可以进行设立,以便表达更精确的意思。
六、
需求分析演练1、需求背景
据CCAV报道:今年CD/DVD高产,可是Music农们却快乐不起来,由于销路不畅,上好的CD/DVC旧在地摊上。为了帮助Music农解决销售问题,本地Z&F积极组织调研,最终决定与“MusicStore”合作,来提供一个能为Music农和购买者建立信息交互的平台,从而为Music农扩大产品销量、达成让Music农增产能增收的目的…..
(此需求改编自“果农丰收,滞销,Z&F帮忙”)
2、需求收集
通过收集,我们决定对“MusicStore”增长以下需求,以便支持唱片的个人交易功能。
①:求购者可以发布求购信息。
②:求购者可以查询出售信息。
③:出售者可以查询求购信息。
④:出售者可以申请一个小店,并在小店中发布出售信息。(我们只收取少许服务费,你懂的)
3、需求分析
①:参考用例
②:真理在哪?
在上一文中我们说到了通过“somebodydosomething”的方式寻来找用例,也就是通过主谓宾的方式来发现事务的本质,以防止“定、状、补”等信息对我们结识事务本质的干扰,以便明确系统的真实意图!
但是“颜回煮粥”的故事告诉我们“耳听为虚,眼见也不一定为实!”,即便是事实也要经得起推敲!
而需求分析中的“推敲”就是对需求进行进一步分析,接下来我们看看需求分析进一步后对“Actor”的影响。
在“①:参考用例”中我们原认为可以反映用户需求,但通过调查,我们发现某些Music农,对岛国的某些蓝光影视很感爱好(正常渠道无法购得,常以二手“Music”的方式出现)而这个时候“Music农”就不再是出售者,转身成为了购买者。也就是一个人他即也许是求购者,也也许是出售者。假如这样的话,当我们在解决“用户登录”这样的用例时就会很为难。
通过度析,我们也许会认为其实我们并不规定细分“求购者”和“出售者”,而采用了类似“权限”来控制。而用例图就变成了类似如下:
当然也有人提出了人员派生的方法来实现,类似:
这也是一种常见的方法,但在本次需求中我个人并不十分推荐这样做,在分析的初期也许有用,但随着分析的进一步,我们会发现“求购者”和“出售者”在系统中会被逐渐淡化,在最后的程序实现中也许跟本就不会出现。刚才我们也提到了“权限控制”的替代方案,最重要的是“派生和承继”隐含了“多态”,但在本次需求中要实现这样的“多态”有些困难,在此并不深究,后继会跟进。
(本文只作引导,不一
温馨提示
- 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
- 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
- 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
- 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
- 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
- 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
- 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。
最新文档
- 盾构施工方案
- 肛管狭窄病因介绍
- 网络安全漏洞管理规范(修改版)
- 职业技术学院大数据与会计专业人才培养方案
- 上海市进才实验中学2024-2025学年(五四学制)九年级上学期12月月考语文试题(无答案)1734420516
- 智能制造生产线技术及应用 教案 4-1 工业机器人产线集成概述
- 热伤风病因介绍
- 《无创机械通气使用》课件
- 开题报告:指向工程思维的高中技术开放性试题命题研究
- 开题报告:职业教育数字化背景下高校教师数字素养提升路径研究
- 水泥产品售后服务标准化方案
- 2024年高考真题-化学(福建卷) 含解析
- 医学免疫学(本)学习通超星期末考试答案章节答案2024年
- 2024亚马逊卖家状况报告
- 生态系统的信息传递课件
- 2024年秋季学期新人教版生物7年级上册课件 第3章 微生物 2.3.1 微生物的分布
- 中国长江三峡集团有限公司二级机构负责人招聘真题
- 2024-2025学年新教材高中政治 第二单元 认识社会与价值选择 6.1 价值与价值观说课稿 统编版必修4
- 2024年计算机操作员考试-计算机操作员高级考试近5年真题附答案
- 工程建设领域农民工…管理三方协议(参考文本)
- 2024年保密措施和管理制度(四篇)
评论
0/150
提交评论