教学课件第4章 建立用例模型.ppt
![资源得分’ title=](/images/score_1.gif)
![资源得分’ title=](/images/score_1.gif)
![资源得分’ title=](/images/score_1.gif)
![资源得分’ title=](/images/score_1.gif)
![资源得分’ title=](/images/score_05.gif)
《教学课件第4章 建立用例模型.ppt》由会员分享,可在线阅读,更多相关《教学课件第4章 建立用例模型.ppt(82页珍藏版)》请在得力文库 - 分享文档赚钱的网站上搜索。
1、2022年4月23日星期六第1页第4章 建立用例模型o4.1 需求获取o4.2 分析需求o4.3 用例在需求分析中的使用o4.4 识别参与者o4.5 确定用例o4.6 用例的粒度o4.7 用例间的关系o4.8 用例描述o4.9 用例建模o总结2022年4月23日星期六第2页第4章 建立用例模型o需求分析就是分析软件用户的需求是什么。o需求分析之所以重要,就因为他具有决策性、方向性和策略性的作用,它在软件开发过程中具有举足轻重的地位,在一个大型软件系统的开发中,他的作用要远远大于程序设计。o需求分析的任务就是解决“做什么”的问题,就是要全面地理解用户的各项要求,并准确地表达所接受的用户需求。 2
2、022年4月23日星期六第3页第4章 建立用例模型o整个软件需求工程研究领域划分为需求开发和需求管理两部分。 需求工程 需求开发 需求管理 验证 编写规格说明 分析 问题获取 2022年4月23日星期六第4页4.1 需求获取o1问题引入问题引入n需求是客户在项目立项时就有的一个愿景。客户需求将决定在整个项目中需要承办方具体做些什么,即承办方的任务。承办方在明确了需求后,就会开始后期的设计、开发、测试、部署等工作。2022年4月23日星期六第5页4.1 需求获取n需求获取在软件工程中非常重要,因为后续的设计、开发等都基于需求。如果需求获取不正确或在需求开发过程中很多功能没有挖掘出来,那么在后期选
3、择弥补时,将会造成项目延期以及成本大幅度增加的严重后果。n如何获取需求是摆在承办方面前的首要任务。2022年4月23日星期六第6页4.1 需求获取o2解答问题解答问题n在需求获取过程中,主要需要弄清楚3个问题,即:o明确需要获取的信息(What)o明确所获取信息的来源和渠道(Where)o怎样获取需求(How)。2022年4月23日星期六第7页4.1 需求获取o3分析问题分析问题n(1) 明确需要获取的信息(What)n通常需求获取需要获取的信息包括三大类:oa. 与问题域相关的背景信息(如业务资料、组织结构图和业务处理流程等);ob. 与要求解决的问题直接相关的信息;oc. 用户对系统的特别
4、期望与施加的任何约束信息。2022年4月23日星期六第8页4.1 需求获取n(2) 明确所获取信息的来源和渠道(Where)n需求信息的来源通常包括:oa. 来自客户的需求;ob. 竞争对手的产品优势与不足;oc. 国家政策、业务规则以及相关行业标准;od. 实施产品设计所需满足的需求;oe. 执行测试验证工作所需满足的需求;of. 实施系统安装、维护所需满足的需求。 2022年4月23日星期六第9页4.1 需求获取n获取需求信息的渠道包括:oa. 用户或客户ob. 公司研发管理部门oc. 公司技术管理部门od. 项目实施部门oe. 营销管理部门of. 旧有系统的研发项目组og. 来自项目组内
5、2022年4月23日星期六第10页4.1 需求获取n(3) 怎样获取需求(How)n需求获取技术包括但不限于:oa. 用户访谈ob. 用户调查oc. 现场观摩用户的工作流程,观察用户的实际操作od. 从行业标准、规范中提取需求oe. 文档挖掘of. 需求讨论会og. 原型法 2022年4月23日星期六第11页4.2 分析需求o1问题引入问题引入n通过需求获取,总结出客户服务系统主要功能需求包括以下几个方面:o(1) 客户可以通过不同的方式(如电话,互联网)对软件产品或项目提出使用中的BUG或疑难问题以及投诉建议等内容。o(2) 客户服务人员应当能保存客户资料,保存客户历次来电内容,并对客户提出
6、的问题及时给予解答,不能在电话中处理的应当交由相关技术工程师继续跟进处理。o(3) 对需要安排上门维护的申请应能及时反映给相关部门领导,并由其作出派工处理。2022年4月23日星期六第12页o(4) 应能及时反馈有派工任务的消息给相关技术工程师,并能保存其处理结果。o(5) 各部门领导应能对投诉的申请给予及时处理,并能保存处理结果。o(6) 公司领导和部门领导应能及时查询客户的来电内容,了解产品使用情况及客户服务人员的售后服务质量等相关业务的综合统计信息。n以上需求信息需要进行详细的分析、归纳。 2022年4月23日星期六第13页4.2 分析需求o2解答问题解答问题n经过分析,为满足上述需求的
7、客户服务系统应包括以下几个模块:o(1) 基础资料维护模块。包括客户基础资料录入修改,客户服务系统用户信息的添加、删除和修改,软件产品的基础资料维护,已上线项目的基础资料维护以及FAQ经验库的数据维护。o(2) 客户服务业务处理模块。包括客户咨询服务处理,故障申报处理,投诉处理,客户服务人员回访处理,维护人员上门处理,部门领导派工处理。o(3) 信息查询统计模块。包括基础资料查询统计,客户咨询的查询与统计,派工单完成情况,回访情况,维护报告查询统计以及相关报表的查询。 2022年4月23日星期六第14页4.2 分析需求o3分析问题分析问题n软件系统的需求分析可以由产品工程师或系统分析师软件系统
8、的需求分析可以由产品工程师或系统分析师或两者分阶段合作完成全部的需求分析工作。其主要或两者分阶段合作完成全部的需求分析工作。其主要任务是逐步细化所有的软件功能,找出系统各元素间任务是逐步细化所有的软件功能,找出系统各元素间的联系、接口特性和设计上的限制,分析它们是否满的联系、接口特性和设计上的限制,分析它们是否满足需求,剔除不合理部分,增加需要部分。最后,综足需求,剔除不合理部分,增加需要部分。最后,综合成系统的解决方案,给出待开发系统的详细逻辑模合成系统的解决方案,给出待开发系统的详细逻辑模型。其主要包括以下几个步骤:型。其主要包括以下几个步骤:2022年4月23日星期六第15页4.2 分析
9、需求n(1) 提取出核心、主要、急迫的业务,明晰业务流程n(2) 运用管理思想,优化业务流程n(3) 进行业务分类,规划系统蓝图o以上内容主要是针对系统功能性需求,除此之外,系统还有性能需求也需要明确。 2022年4月23日星期六第16页4.3 用例在需求分析中的使用o1. 问题引入问题引入n规划出了软件的功能模块,只是软件的功能框架结构,下一步就需要明确描述每个模块的具体内容。包含什么内容、能做什么操作,每一个功能点的说明、业务规则、详细功能描述等等。这些软件需求规格必须描述的内容需要有个标准的表现方式。2022年4月23日星期六第17页4.3 用例在需求分析中的使用o2. 解答问题解答问题
10、n用例 (Use Case) 是一种描述系统需求的方法,使用用例的方法来描述系统需求的过程就是用例建模。用例模型包括用例图和用例描述。n用例图主要由以下模型元素构成:2022年4月23日星期六第18页4.3 用例在需求分析中的使用o(1) 参与者 (Actor) n参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统,他们代表的是系统的使用者或使用环境。2022年4月23日星期六第19页4.3 用例在需求分析中的使用o(2) 用例 (Use Case) n用例用于表示系统所提供的服务,它定义了系统是如何被参与者所使用的,它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生
11、的一段对话。 2022年4月23日星期六第20页4.3 用例在需求分析中的使用o(3) 关联 ( Association) n关联用于表示参与者和用例之间的对应关系,它表示参与者使用了系统中的哪些服务(用例),或者说系统所提供的服务(用例)是被哪些参与者所使用的。 2022年4月23日星期六第21页4.3 用例在需求分析中的使用o以课程注册系统为例,当参与者是学生时,学生使用该系统可以进行登录系统、注册课程和查看报告的操作。登录注册课程学生查看报告2022年4月23日星期六第22页4.3 用例在需求分析中的使用o3. 分析问题分析问题n用例方法完全站在用户的角度上(从系统的外部)来描述系统的功
12、能。n在用例方法中,把被定义系统看作是一个黑箱,我们并不关心系统内部是如何完成它所提供的功能的。n用例方法首先描述了被定义系统有哪些外部使用者(抽象成为Actor),这些使用者与被定义系统发生交互;针对每一参与者,用例方法又描述了系统为这些参与者提供了什么样的服务(抽象成为Use Case),或者说系统是如何被这些参与者使用的。n所以从用例图中,我们可以得到对于被定义系统的一个总体印象。2022年4月23日星期六第23页4.3 用例在需求分析中的使用n与传统的功能分解方式相比,用例方法完全是从外部来定义系统的功能,它把需求与设计完全分离开来。n在面向对象的分析设计方法中,用例模型主要用于表述系
13、统的功能性需求,系统设计主要由对象模型来记录描述。另外,用例定义了系统功能的使用环境与上下文,每一个用例描述的是一个完整的系统服务。用例方法比传统的SRS更易于被用户所理解,它可以作为开发人员和用户之间针对系统需求进行沟通的一个有效手段。 2022年4月23日星期六第24页4.4 识别参与者o1. 问题引入问题引入n客户服务系统是对公司和客户进行统一管理的系统,根据客户服务系统案例需求说明书,具体包括以下几个方面:o(1) 基础资料维护。包括系统管理员添加、删除、修改客户服务系统账户信息,添加、修改、删除公司产品及项目信息;客户服务人员添加、修改、删除客户资料信息,添加、修改、删除经验库信息等
14、。o(2) 业务处理。包括客户服务人员新增、修改、删除客户咨询信息;维护人员处理客户问题、填写维护报告;部门领导处理投诉,安排任务等。o(3) 统计查询。包括客户资料查询、客户来电咨询查询、经验库查询、客户服务系统用户信息查询、回访任务及维护报告查询等。n明确以上信息后,分析系统的参与者。2022年4月23日星期六第25页4.4 识别参与者o2. 解答问题解答问题n对于这个系统,通过需求陈述文档,可以得到以下一些信息:o系统管理员维护系统用户帐号和产品项目信息。o客户服务人员维护客户资料、客户咨询以及经验库信息。o维护人员填写维护报告。o部门领导处理投诉。n所以创建以下参与者:系统管理员、客户
15、服务人员、维护人员、部门领导。 2022年4月23日星期六第26页4.4 识别参与者o3. 分析问题分析问题n参与者是在系统之外,透过系统边界与系统进行有意义交互的任何事物。通俗地讲,参与者就是我们所要定义系统的使用者。寻找参与者可以从以下问题入手:o(1) 系统开发完成之后,有哪些人会使用这个系统?o(2) 系统需要从哪些人或其他系统中获得数据?o(3) 系统会为哪些人或其他系统提供数据?o(4) 系统需要与哪些其他系统交互?o(5) 系统是由谁来维护和管理并保持其正常运行?o(6) 系统需要应付(处理)哪些硬设备?o(7) 谁(或什么)对系统运行产生的结果感兴趣?o(8) 有没有自动发生的
16、事件? 2022年4月23日星期六第27页4.4 识别参与者o注意:n系统参与者一定是与系统有直接联系的事物,这里事物包括人和其他系统。n在客户服务系统中,客户打电话给客户服务人员反馈问题,客户服务通过系统对反馈的问题进行处理,在这个业务过程中,客户并没有直接操作客户服务系统,就没有直接联系,所以客户不是系统的参与者。n又如超市的收银系统,收银员是该系统的参与者,而超市客户则不是;银行系统中,银行的窗口服务员是参与者,而在窗口存钱或取钱的客户不是参与者。但在银行ATM系统中,客户从银行ATM机存取款,客户是ATM系统中的参与者。 2022年4月23日星期六第28页4.5 确定用例o1. 问题引
17、入问题引入n找到参与者之后,就需要根据参与者来确定系统的用例。2022年4月23日星期六第29页4.5 确定用例o2. 解答问题解答问题n对于每一个参与者,相对应的用例如下:2022年4月23日星期六第30页4.5 确定用例o客户服务人员:n(1) 登录系统n(2) 查询客户信息及咨询记录n(3) 查询经验库信息n(4) 查询基础资料信息n(5) 补充完善经验库信息n(6) 维护客户资料n(7) 维护来电记录 2022年4月23日星期六第31页4.5 确定用例o维护人员:n(1) 查询自己的派工单及报告信息n(2) 接受并处理自己的派工单n(3) 填写报告2022年4月23日星期六第32页4.
18、5 确定用例o系统管理员:n(1) 管理用户n(2) 维护基础资料n(3) 维护系统 2022年4月23日星期六第33页4.5 确定用例o部门领导:n(1) 查询客户资料及咨询信息n(2) 查询项目及产品信息n(3) 查询维护人员派工单的执行情况n(4) 安排派工任务2022年4月23日星期六第34页4.5 确定用例o3. 分析问题分析问题n确定用例主要是看各参与者需要系统提供什么样的服务,或者说参与者是如何使用系统的,用例命名往往采用动宾结构。参与者与用例连起来读,往往是一条通顺的句子,例如:客户服务人员(参与者)维护客户资料(用例)。2022年4月23日星期六第35页4.5 确定用例o寻找
19、用例可以从以下问题入手(针对每一个参与者):n(1) 参与者为什么要使用该系统?n(2) 参与者是否会在系统中创建、修改、删除、访问、存储数据?如果是的话,参与者又是如何来完成这些操作的?n(3) 参与者是否会将外部的某些事件通知给该系统?n(4) 系统是否会将内部的某些事件通知该参与者? 2022年4月23日星期六第36页4.6 用例的粒度o1. 问题引入问题引入n对于一个系统来说,不同的人进行用例分析后得到的用例数目有多有少。n如果用例粒度很大,那么得到的用例数就会很少,如果用例粒度很小,那么得到的用例数就会很多。n那么到底多大的粒度才是比较合适的? 2022年4月23日星期六第37页4.
20、6 用例的粒度o2. 解答问题解答问题n用例(大小)粒度的决定在于客户,用例的关键在于准确反映客户需求。2022年4月23日星期六第38页4.6 用例的粒度o3. 分析问题分析问题n用例是一种用来探索需求的技术,而需求和设计之间的区别在于需求解决的是系统“做什么”的问题;而设计则是针对需求中提出的问题,解决系统该“怎么做”的问题。需求调研的过程是发现和界定问题的过程,设计的过程是寻找解决方案的过程。需求分析的思维方式是总结和抽象,系统设计的思维方式是分解和细化。2022年4月23日星期六第39页4.6 用例的粒度o在确定用例过程中,主要有两个方面的问题会迷惑分析者:n当分析人员面对具有业务流程
21、的用例时该如何处理;n面对具有功能分解的用例时如何处理。2022年4月23日星期六第40页4.6 用例的粒度o(1)具有业务流程的用例的处理方法n具有业务流程的用例是指某个用例需要分几个业务阶段来完成,如客户服务系统中维护人员接受派工单需要首先查看到派工单,然后选择接受派工单。那么对于查看派工单和接受派工单,究竟是作为一个用例好,还是作为两个用例好?我们对这类问题处理的原则是什么? 2022年4月23日星期六第41页4.6 用例的粒度n用例是被从现实的场景中抽象出来的。如果这些场景有紧密的联系(高内聚),且能真正反映用户的需求,那么用用例技术来组织它们则可以复用这些场景中的步骤描述,从而达到事
22、倍功半的效果。n在该例中,查看派工单和接受派工单两个步骤的真正目的就是让维护人员接受派工任务,用户的需求也在于此,这两个步骤是紧密联系在一起的,所以把它们作为一个用例。2022年4月23日星期六第42页4.6 用例的粒度o(1)具有功能分解的用例的处理方法n具有功能分解的用例是指该用例往往可以分解为多个用例,如:维护客户资料,在该用例中客户服务人员可以做3件事:增加一条客户资料、修改一条客户资料、删除一条客户资料,那么分析人员可以有两种方案,第一种方案是把这个用例单独看作一个用例来描述,第二种方案则是分成3个用例来描述。2022年4月23日星期六第43页4.6 用例的粒度n不同的人对这个问题会
23、有不同的看法。n从捕获用户需求的角度考虑,建议采用第一种方案,采用第二个方案的主要问题是限制了分析人员的思路。n虽然从系统实现的角度看,对客户资料的操作有添加、删除、修改等,但事实上,用户真正目的可能并不是对记录的添加、修改和删除,而是别的目的。如维护人员填写维护信息,虽然这个要求会涉及到维护信息的增加、删除和修改,但如果采用第二个方案有可能忽视了维护人员报告维护信息这个真正的用户需求。 2022年4月23日星期六第44页4.7 用例间的关系o1. 问题引入问题引入n用例之间本来是独立的、并行的,但是某些时候用例之间确实是具有一定的业务关系,例如客户在浏览Web站点时可以选择是否在线购买商品,
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 教学课件第4章 建立用例模型 教学 课件 建立 模型
![提示](https://www.deliwenku.com/images/bang_tan.gif)
限制150内