实际案例类用例PPT资料.ppt

上传人:b****1 文档编号:14363931 上传时间:2022-10-22 格式:PPT 页数:71 大小:2.58MB
下载 相关 举报
实际案例类用例PPT资料.ppt_第1页
第1页 / 共71页
实际案例类用例PPT资料.ppt_第2页
第2页 / 共71页
实际案例类用例PPT资料.ppt_第3页
第3页 / 共71页
实际案例类用例PPT资料.ppt_第4页
第4页 / 共71页
实际案例类用例PPT资料.ppt_第5页
第5页 / 共71页
点击查看更多>>
下载资源
资源描述

实际案例类用例PPT资料.ppt

《实际案例类用例PPT资料.ppt》由会员分享,可在线阅读,更多相关《实际案例类用例PPT资料.ppt(71页珍藏版)》请在冰豆网上搜索。

实际案例类用例PPT资料.ppt

基础用例通过扩展隐含地合并了/扩展了另一个用例的行为。

通过扩展我们将扩展用例的行为放入基用例之中。

2022/10/22,4,基本用例,扩展用例,extend,基本用例,包含用例,include,2022/10/22,5,4,本讲主要内容,静态模型类图的建模实例,1,2,用例图的建模方法,用例描述方法,3,用例图建模实例,需求的重要性,开发软件系统最为困难的部分就是准确说明开发什么。

最为困难的概念性工作就是编写出详细技术需求,这包括所有面向用户、面向机器和其它软件系统的接口。

同时这也是一旦做错,将最终会给系统带来极大损害的部分,并且以后再对它进行修改也极为困难。

Thehardestsinglepartofbuildingasoftwaresystemisdecidingpreciselywhattobuild.Nootherpartoftheconceptualworkisasdifficultasestablishingthedetailedtechnicalrequirements,includingalltheinterfacestopeople,tomachines,andtoothersoftwaresystems.Nootherpartoftheworksocripplestheresultingsystemifdonewrong.Nootherpartismoredifficulttorectifylater,FrederickBrooks,NoSilverBullet:

EssenceandAccidentsofSoftwareEngineering,1987.,Maria:

一个职员想改名字Sparkle,系统不允许,能帮忙吗?

、Phil:

她结婚了吗?

Maria:

没有啊,系统好像只能在修改婚姻状况才能改名。

Phil:

是啊,当时你们没有告诉我系统要处理这样的情况,所以只能在修改婚姻状况对话框中才能改变姓名啊。

每个人都可以随时改变姓名只要她愿意,请在下周五之前解决这个问题,否则Sparkle无法支付她的账单。

这不是我的错啊,我从来不知道你们需要处理这种情况,我现在正忙着做别的系统,一周内不行,很抱歉。

那我怎么跟Sparkle说呢?

她不能付账单,只能挂账了。

Phil:

你要明白,这不是我的错,如果你一开始就告诉我,就不会发生了,你不能因我未猜出你的想法而责备我。

Maria愤怒地屈服:

好吧,好吧,真是恨透计算机系统了,等你修改好了,马上通知我,行吧?

人力资源Maria,开发人员Phil,收集、编写、协商、修改产品需求过程中的手续和做法失误带来的。

涉及到如下问题:

非正式信息的收集未确定或不明确的功能未发现或未经交流的假设不完善的需求文档突发的需求变更过程,人力资源Maria,开发人员Phil,杀一个程序员不需要用枪,改三次需求就可以了。

WeneedSRS,中途更换了所有的开发者客户被迫与新的需求人员坐在一起分析:

我想和你们谈谈需求客户:

我已经告诉你的前任了,我要的是你们给我编个系统需求未编写成文档,整个项目得从头开始,仅仅一堆邮件、零碎的谈话,不规范。

2022/10/22,11,一、用例描述,用例模型,2022/10/22,12,2022/10/22,13,用例描述,应该避免这样一种误解认为由参与者和用例构成的用例图就是用例模型,用例图只是在总体上大致描述了系统所能提供的各种服务,让我们对于系统的功能有一个总体的认识。

除此之外,我们还需要描述每一个用例的详细信息,这些信息包含在用例规约中,用例模型是由用例图和每一个用例的详细描述用例规约所组成的。

2022/10/22,14,用例描述,用例描述有许多种方法,如简单文字、模板、表格、形式化语言和图形等,开发人员可根据项目进展及用户特点灵活选择。

用例规约基本上是用文本方式来表述的,为了更加清晰地描述事件流,也可以选择使用状态图、活动图或序列图来辅助说明。

只要有助于表达的简洁明了,就可以在用例中任意粘贴用户界面和流程的图形化显示方式,或是其他图形。

如活动图有助于描述复杂的决策流程,状态转移图有助于描述与状态相关的系统行为,序列图适合于描述基于时间顺序的消息传递。

优秀需求的特征,完整性正确性可行性必要性划分优先级无二义性可验证性,Wiegers,K.E.SoftwareRequirements,,示例1改进前,“产品必须在固定的时间间隔内提供状态消息,并且每次时间间隔不得小于60s。

”疑问:

什么是状态消息?

固定时间间隔与每次时间间隔?

不得小于60s,那么多长才合适?

每次间隔是否需要保持一致?

示例1修改后,“后台任务管理器应该在用户界面的制定区域显示状态消息”A.在后台任务进程启动之后,消息必须每隔60(10)秒更新一次,并且保持连续的可见性。

B.如果正在正常处理后台任务进程,那么后台任务管理器必须显示后台任务进程当前已完成的百分比。

C.当完成后台任务时,后台任务管理器必须显示一个“已完成”的消息。

D.如果后台任务中止执行,那么后台任务管理器必须显示一个出错消息。

每个需求可以单独设计测试用例进行测试。

示例2修改前,分析程序应当能生成HTML标记出错的报告,这样就可以使HTML的初学者使用它来迅速排错。

疑问:

迅速?

模糊缺乏对出错内容的报告定义需求不完整HTML初学者?

仅仅是他们?

HTML初学者到底是用的是分析程序还是出错报告?

何时生成这样的报告?

示例2修改后,A在HTML分析程序完全分析完一个文件之后,该分析程序必须生成一个出错报告,这个报告中包含了在分析文件过程中所发现错误的HTML所在的行号以及文本内容,还包含了对每个错误的描述。

B如果在分析过程中未发现任何错误,就不必生成出错报告。

示例3修改前,如果可能的话,应当根据主货物编号列表在线确认所输入的货物编号如果可能的话意味什么?

无法确信待确定客户可能需求可能不需要应当、必须、可能必须将要,示例3修改后,系统必须根据在线的主货物编号列表确认所输入的货物编号。

如果在主列表中查不到该货物的编号,系统必须显示一个出错消息并且拒绝订货。

考虑了异常情况,用例编号:

USECASE_USER_01用例名称:

启动系统级别:

用户目标主参与者:

用户GPS设备涉众及其利益:

用户前置条件:

本机存有相关数据文件最小保证:

系统提示启动失败信息触发事件:

用户启动程序主成功场景:

1系统读取配置文件2系统读取数据文件3系统显示地图4系统启动GPS5系统显示用户位置,速度,方向信息。

5a、GPS设备损坏或缺失:

提示无法启动GPS。

不执行6。

数据变化:

无,系统用例叙述(公司),用例描述,1基本用例信息2执行流程3条件或规则4相关文档5优先级,系统用例叙述,一种用例描述格式,一种用例描述格式,1、基本用例信息用例名称用例编号用例简述只需三言两语,简洁说明该用例,以增强用例叙述的可理解性。

用例图在用例叙述的开头处附上相关的用例图件,不仅可以一目了然地得知用例的名称,执行者名称等,也丰富了用例叙述的表达方式,摆脱文字格式的单调性。

系统执行者相关用例常见的相关性有两方面,其一是执行用例前必须先行执行过某相关用例,其二是执行用例期间可能驱动其他的包含用例(InclusionUseCase),或是因条件符合驱动其他的扩展用例(ExtensionUseCase).,2、执行流程主要流程替代流程例外流程,一种用例描述格式,主要流程、替代流程、例外流程,主要流程:

这是用例叙述最核心的部分,其记载了整个用例正常的执行过程。

替代流程:

一个用例叙述里面,通常会包含一段主要流程,同时可以包含数段替代流程。

如果将主要流程比拟成经常使用的大马路的话,替代流程就是比较少用的羊肠小道,不过走完一段羊肠小道之后,小径的尽头还是会再度接回大马路。

例外流程:

例外流程跟替代流程不同,替代流程这条小径的尽头会接回主要流程,可是一旦进入了例外流程之后,系统将不会继续执行完剩下的主要流程。

也就是说,例外流程这条小径的尽头不会接回主要流程。

主要流程、替代流程、例外流程,例子:

在基金模拟项目中,投资人上网申购单笔基金的正常流程就是主要流程。

可是,有些投资人在申购的过程中可能不是这么顺畅。

例如,单笔申购国内基金最低金额是一万元,如果投资人没有注意到这个约束,键入低于一万元的申购金额的话,这时可以用替代流程来说明如何处理这种情况。

分析:

替代流程跟例外流程有细微差异。

用例成功执行的过程中,正常流程就是主要流程,期间出现的小插曲就是替代流程,但是,例外流程处理的是,用例执行失败的情况,例如,网络有问题,导致申购交易时间逾时,这时候“上网单笔申购基金”的系统用例就算执行失败,所以会引发例外流程,来处理用例执行失败的事件。

流程及替代流程编号,3、条件及规则前置条件这是执行用例之前的检验,惟有在满足某些重要条件时,才会执行该用例,以确保用例可以正确执行。

后置条件相对于前置条件,后置条件代表用例执行完毕时,可以通过后置条件自行检验是否执行成功。

失败时状态记录用例执行失败时的状态。

业务规则重要的业务规则或计算公式都要记录下来。

一种用例描述格式,业务规则,业务人员在执行业务流程时,会使用到许多重要的业务规则或计算公式,这些也都是系统必须遵守的条件及规则,所以必须记录下来。

比方说,在基金模拟项目中,就有如下的条件及公式:

定期定额申购最低金额,国内基金为3000元,境外基金为5000元。

(业务规则)单笔申购最低金额,国内基金为10000元,境外基金为30000元(业务规则)申购金额以千元为倍数。

(业务规则)定期定额申购扣款日为每月5、15、25日择一扣款。

(业务规则)定期定额当月未扣款成功,将不再补款(业务规则)债券型基金只承作单笔申购(业务规则)手续费=申购金额基金管理费银行折扣。

(计算公式),4、相关文档用例叙述的历史版本UML图参考画面其他非UML文档,一种用例描述格式,相关文档(需求变化用例如何适应?

),由于用例驱动(UseCaseDriven)是当今软件开发的基础模型,常作为系统开发文件的汇集点,由它链接到相关的文档所以用例叙述。

一旦业务流程或需求有所变化时,可以快速搜寻出以用例叙述为首的一连串相关的文档,然后进行修改。

常见的相关文档有:

用例叙述的历史版本:

用例改版时,用例叙述也跟着同步改版。

可以在现行版本里多加一个字段,以链接旧有的历史版本以及改版说明。

UML图:

跟该用例相关的业务用例图、活动图、系统用例图、状态图、类图或序列图,等等。

参考画面:

有时候附上画面设计的图片,让阅读者可以对该用例有更具体的想象。

其他非UML文档:

例如会议记录、PDF、EXCEL电子文件、表设计,等等。

2022/10/22,34,2022/10/22,35,二、用例模型建模方法,需求分析阶段流程,用例建模过程划定系统边界和范围确定执行者和用例对用例进行描述定义用例之间的关系审核用例模型,与用户会谈,发现参与者及高层用例,确定系统边界和范围;

定义业务流程(业务用例模型)定义系统范围(系统用例图),与用户深入交谈,获取深层次需求,产生详细描述场景和序列的用例模型。

分析用例间的包含、扩展、泛化关系。

用例建模的步骤1定义系统边界和范围,系统软硬件系统(开发满足某种需求的

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 考试认证 > IT认证

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1