需求分析与用例建模.pptx

1、用例建模 Use-Case Modeling,吴晓霞,-2-,课程内容,UML概述 理解需求 需求，难在何处？ 以用例为中心组织需求 基于用例的需求分析过程,-3-,课程内容,UML概述 理解需求 需求，难在何处？ 以用例为中心组织需求 基于用例的需求分析过程,同样的东西（对象）在不同人的眼里 ,如果在你的世界里出现了这样的事情 ,抽象画？还是表达某种神秘信息的作品？,想做什么事情？,UML简介,UML (Unified Modeling Language)为面向对象软件设计提供统一的、标准的、可视化的建模语言。适用于描述以用例为驱动，以体系结构为中心的软件设计的全过程。 UML的定义包括UM

2、L语义和UML表示法两个部分。 UML语义：UML对语义的描述使开发者能在语义上 取得一致认识，消除了因人而异的表达方法所造成的影响。 UML表示法：UML表示法定义UML符号的表示法，为开 发者或开发工具使用这些图形符号和文本语法为系统建模提供了标准。,-8-,-9-,UML发展现状,目前通用的是UML 1.x版 主要UML 1.3、UML 1.4 2003年3月正式发布UML 1.5 UML 2.0 2003年6月OMG采纳了UML 2.0的Superstructure的提案 正式文本尚未发布 ,-10-,UML 9种图,类 图：类以及类之间的相互关系 对象图：对象以及对象之间相互关系 构

3、件图：构件及其相互依赖关系 部署图：构件在各节点上的部署顺序图：强调时间顺序的交互图 协作图：强调对象协作的交互图 状态图：类所经历的各种状态 活动图：对工作流建模 用例图：需求捕获，测试依据,结 构,行为,用例图,静态图,实现图,交互图,行为图,-11-,UML建模工具,IBM Rational Rose 2003 Borland Together 7.0 Microsoft Visio 2003 Sybase PowerDesigner 10 NetBeans UML “非程序员杂志”第26到30期UML工具一览，列出了约129个UML开发工具,-12-,内容安排,UML概述 理解需求 需

4、求，难在何处？ 以用例为中心组织需求 基于用例的需求分析过程,认识问题,分析问题,解决问题,最终用户(提出问题),开发团队(解决问题),以用户的身份站在用户的角度认识问题 获取需求用例建模技术,以开发者的身份站在用户的角度分析问题 分析需求用例分析技术,以开发者的身份站在开发团队的角度分析问题 解决需求面向对象设计,-14-,需求建造“正确”的系统,需求：系统必须满足的条件或具备的能力 软件质量准则“FURPS” 功能性（Functionality） 可用性（Usability） 可靠性（Reliability） 性能（Performance） 可支持性（Supportability）,非功能

5、性需求,-15-,内容安排,UML概述 理解需求 需求，难在何处？ 以用例为中心组织需求 基于用例的需求分析过程,-16-,需求：饮料问题,我要一瓶饮料 差不多，但我要无糖饮料 很好，不过我要绿茶的 啊，没有大瓶的,大瓶的无糖绿茶饮料,难捕获，易变！,-17-,需求：如此脆弱,客户/用户的要求/想法/期望,软件设计,软件产品,分析和设计,编码和测试,验 收,没价值的 软件需求,补文档,-18-,需求：也需要开发,客户/用户的要求/想法/期望,软件设计,软件产品,开发,编码和测试,验收,有价值的 软件需求,分析和设计,-19-,获取好的需求,需求收集包括五个关键步骤 找到可以帮助你理解这个系统的

6、人 倾听这些相关人员的描述，并从他们的角度来理解系统 利用一个容易理解的模型来描述用户希望如何使用这个系统以及为他们提供的什么价值 详细地描述系统和客户以及系统和外部系统之间的交互 重构（refactor）这个详细描述以保证它是可读且易懂的,-20-,内容安排,UML概述 理解需求 需求，难在何处？ 以用例为中心组织需求 基于用例的需求分析过程,-21-,需求问题：对策,难捕获,易变,从用户视角看问题,合理的结构,用例,-22-,以用例为中心组织需求,-23-,内容安排,UML概述 理解需求 需求，难在何处？ 以用例为中心组织需求 基于用例的需求分析过程,-24-,基于用例的需求分析过程,1.

7、 获取原始需求 2. 开发一个可以理解的需求 2.1 识别角色 2.2 识别用例 2.3 构建用例图 3 详细、完整地描述需求 进行用例阐述 4 重构用例模型 4.1 识别用例间的关系 4.2 对用例进行组织和分包,-25-,基于用例的需求分析过程,1. 获取原始需求 2. 开发一个可以理解的需求 2.1 识别角色 2.2 识别用例 2.3 构建用例图 3. 详细、完整地描述需求 进行用例阐述 4. 重构用例模型 4.1 识别用例间的关系 4.2 对用例进行组织和分包,-26-,获取需求的技巧,-27-,获取需求：考勤卡应用程序,初次访谈记录 开发者：谁将使用这个应用程序？ 客 户：所有用它来

8、记录可记帐以及不可记帐的工时的雇员 开发者：现在考勤卡应用程序是什么样的？ 客 户：每半个月就用一个Excel表格来记录。每个雇员都将通过他的表格填好，然后用电子邮件发给我。这个表格相当标准：纵向是收费项目代码，横向是日期。雇员可以在每个条目上填写说明。 开发者：这个收费项目代码可以从什么地方得到？ 开发者：谁来管理收费项目代码？ 客 户：嗯，必要的时候由我来添加这个代码。而每个经理总会告诉他的下属应该填写什么。 ,-28-,基于用例的需求分析过程,1. 获取原始需求 2. 开发一个可以理解的需求 2.1 识别角色 2.2 识别用例 2.3 构建用例图：确定角色和用例之间的关系 3. 详细、完

9、整地描述需求 进行用例阐述 4. 重构用例模型 4.1 识别用例间的关系 4.2 对用例进行组织和分包,-29-,相关术语,场景：是用来描述用户和系统之间交互的顺序的步骤,用例：是为了达到某一用户目标而组合在一起的一组场景,用例图：用来显示在系统（或其它实体）内的用例与系统角色之间的关系,主要使用场合：需求获取、定义、分析,用例模型：是系统既定功能及系统环境的模型，并作为客户和开发人员之间的契约。用例模型用作分析、设计和测试活动的基本输入。,-30-,用例图元素,角色,用例,系统边界,直接关联,扩展,包含,泛化,注释体,注释连接,关联,31,2.1 识别角色,角色（actor）是指在系统外部与

10、系统交互的人或其他系统，它以某种方式参与了系统内用例的执行。角色在UML中通常以一个稻草人图符来表示。 角色类型：角色不仅可以由人承担，还可以是其它系统、硬件设备、甚至是时钟 ： 1）其它系统：当系统需要与其它系统交互时，如ATM柜员机系统中，银行后台系统就是一个角色； 2）硬件设备：如果系统需要与硬件设备交互时，如在开发IC卡门禁系统时，IC卡读写器就是一个角色； 3）时钟：当系统需要定时触发时，时钟就是角色,32,2.1 识别角色,通过向用户提问来识别角色： 谁使用系统提供的主要功能？（主要角色） 谁来维护、管理系统？（次要角色） 谁需要借助于系统完成日常工作任务？ 系统需要控制的硬件设备

11、有哪些？ 系统需要与其他哪些系统交互？ 系统从哪儿得到信息？ 对系统产生的结果感兴趣的人或事是哪些？ ！不能把目光只专著于人身上。,33,ATM系统的角色,1、谁使用ATM系统的主要功能（提款）？,答：储户,2、谁使用ATM系统的支持以完成日常工作任务？,答：出纳员？还不肯定，先放在这里,3、谁来维护、管理并保持系统正常运行？,答： ATM系统工程师，银行人员,34,ATM系统的角色,5、ATM系统需要处理哪些设备？,答：信用卡,6、谁对ATM系统运行的结果感兴趣？,答：银行会计、储户,4、该系统需要和哪些系统交互？,答：目前还不清楚,35,ATM系统的角色,-36-,识别角色：考勤卡系统,开

12、发者：谁将使用这个应用程序？ 客 户：所有用它来记录可记帐以及不可记帐的工时的雇员 开发者：现在考勤卡应用程序是什么样的？ 客 户：每半个月就用一个Excel表格来记录。每个雇员都将通过他的表格填好，然后用电子邮件发给我。这个表格相当标准：纵向是收费项目代码，横向是日期。雇员可以在每个条目上填写说明。 开发者：这个收费项目代码可以从什么地方得到？ 开发者：谁来管理收费项目代码？ 客 户：嗯，必要的时候由我（业务经理）来添加这个代码。而每个经理总会告诉他的下属应该填写什么。 ,37,2.2 识别用例,用例，就是一件事情，要完成这件事情，需要做一系列的活动；而做一件事情可以有很多不同的方法和步骤，

13、也可能会遇到各种各样的意外情况，因此这件事情是由很多不同情况的集合构成的，在UML中我们称之为场景。一个场景就是一个用例的实例。 从本质上讲,一个用例是用户与计算机之间的一次典型交互作用。在UML中,用例被定义成系统执行的一系列动作（功能）。,38,1.用例的特征,响应性。一个用例不自动执行，总是有执行者启动。 这件事必须由一个执行者发起，执行者的愿望是 用例存在的原因。不存在没有执行者的用例，也不应该主动启动另一个用例。,39,回执性。 用例执行完毕，向执行者提供可识别的返回值。用例的执行结果对角色来说是可观测的和有意义的。如，系统会监控角色在系统里的操作，并在角色删除数据之前备份。虽然它是

14、系统的一个必需组成部分，但它在需求阶段却不应该作为用例出现。因为这是一个后台进程，对角色来说是不可观测的，它应该在系统用例分析阶段定义。又比如，登录系统是一个有效的用例，但输入密码却不是。这是因为登录系统对角色是有意义的，这样他可以获得身份认证和授权，但输入密码却是没有意义的，输入完了呢？有什么结果吗？,1.用例的特征,完整性。 用例表示一个完整的功能，必须是一完整的描述。 必须以向执行者提供返回值作为该用例完整性的标志。,40,41,用例的特征-动宾短语,用例必然是以动宾短语形式出现的。即，这件事必须有一个动作和动作的受体。 例如，喝水是一个有效的用例，而“喝”和“水”却不是。虽然生活常识告

15、诉我们，在没有水的情况下人是不会做出喝这个动作的，水也必然是喝进去的，而不是滑进去的。 但是我们所见的很多用例中类似“计算”，“统计”，“报表”，“输出”，“录入”之类的并不在少数。,-42-,用例的命名,执行者视角： 一个简单、描述性的名称，一般为带有动作性的词。,43,2寻找和确定用例,业务用例：开始阶段，在确定用户需求过程中，系统分析员通过与客户交流建立业务模型来发现和确定的用例。 系统用例：系统构造阶段，系统分析和设计人员在进行系统分析和设计时，根据系统的需求建立的用例。 在系统开发的开端阶段，应把注意力集中在业务用例上，在精化阶段和构建阶段再考虑系统用例。,-44-,识别用例：考勤卡

16、系统,开发者：谁将使用这个应用程序？ 客 户：所有用它来记录可记帐以及不可记帐的工时的雇员 开发者：现在考勤卡应用程序是什么样的？ 客 户：每半个月就用一个Excel表格来记录。每个雇员都将通过他的表格填好，然后用电子邮件发给我。这个表格相当标准：纵向是收费项目代码，横向是日期。雇员可以在每个条目上填写说明。 开发者：这个收费项目代码可以从什么地方得到？ 开发者：谁来管理收费项目代码？ 客 户：嗯，必要的时候由我（业务经理）来添加这个代码。而每个经理总会告诉他的下属应该填写什么。 ,-45-,用例要点,可观测用例止于系统边界 结果值用例是有意义的目标 系统执行结果值由系统生成 由角色观测业务语

17、言、用户观点 一组用例实例用例的粒度,-46-,要点：用例止于系统边界,描述交互，而不是内在的系统活动,-47-,要点：有意义的目标,48,目标和步骤的误区,-49-,要点：结果值由系统生成,系统需要处理的，由系统生成,-50-,要点：业务语言而非技术语言,用户词汇，而不是技术词汇 如：发票，商品，洗衣机 而不是：记录，字段，COM，C+等,-51-,要点：用户观点而非系统观点,用户观点,系统观点,-52-,用例的命名,执行者视角： 一个简单、描述性的名称，一般为带有动作性的词。,-53-,要点：用例粒度-1,用例要有路径，路径要有步骤；而这一切都是可观测的 最常犯错误：粒度过细，陷入功能分解

18、 过细的粒度，一般都会导致技术语言的描述，而不再是业务语言,-54-,用例粒度-2,把步骤当用例把系统活动当用例,-55-,用例粒度-3,“四轮马车” C(Create) R(Read) U(Update) D(Delete) 所有业务最终对会成为CRUD？ CRUD能为Actor提供价值？ CRUD掩盖业务，锐变成关系数据库的建模： “系统就是数据的增删改查” 关心数据的存储和维护，反而忽略了用户的目的,-56-,用例粒度-4,如果确实是CRUD？ 如果CRUD不涉及复杂的交互，一个用例“管理”即可 不管是C、R、U、D，都是为了完成“管理”目标 甚至很多种的基本数据管理都可以用一个用例表示

19、,-57-,用例粒度-5,灵活处理CRUD,可以把包含复杂交互的路径独立出去形成用例,58,用例粒度实例,ATM取钱的场景中，取钱，读卡，验证账号，打印回执单等都是可能的用例？ 客户代表说：我希望这台ATM能支持跨行业务，我插入卡片输入密码后，可以让我选择是取钱还是存钱；为了方便，可以设置一些默认的存取金额按钮；我可以修改密码，也可以挂失；还有我希望可以交纳水费、电费和电话等费用；为了安全起见，ATM上应当有警示小心骗子的提示条，还有摄像头；如果输入三次密码错误，卡片应当被自动吞没。,59,用例粒度判断,支持跨行业务 插入卡片 输入密码 选择服务 取钱 存钱 挂失卡片 交纳费用 警示骗子 三次

20、错误吞没卡片,60,用例粒度判断,支持跨行业务 错，这是一个业务规则，限定业务的范围 插入卡片 错，这是一个过程步骤，不是完整目标 输入密码 错，这是一个过程步骤，不是完整目标 选择服务 错，这是一个过程步骤，不是完整目标 取钱 对，这是一个完整有效的目标 存钱 对，这是一个完整有效的目标 挂失卡片 对，这是一个完整有效的目标 交纳费用 对，这是一个完整有效的目标 警示骗子 错，已超出了边界范围 三次错误吞没卡片 错，这是一个业务规则，限定业务 的范围,-61-,思考：识别用例-1,Email客户端（如：outlook express），A在北京发邮件给上海的B，系统提醒B你有“新邮件”，B收

21、邮件,错误,-62-,思考：识别用例-2,-63-,2.3 构建用例图,-64-,基于用例的需求分析过程,1. 获取原始需求 2. 开发一个可以理解的需求 2.1 识别角色 2.2 识别用例 2.3 构建用例图 3. 详细、完整地描述需求 进行用例阐述 4.重构用例模型(高级用例建模方法) 4.1 识别用例间的关系 4.2 对用例进行组织和分包,-65-,进行用例阐述：写用例规约,用例规约(Use case Specification) ：更进一步的精度 用例文档的核心，作为用例文档的总图 进一步的精度：有层次的文档 文档中每一句话都有其价值,用例图是骨架，而用例规约则是其内在的肉,-66-,

22、谁来写用例文档,最完美：业务人员接受训练，写出优美的用例文档 最现实：业务人员提供素材，开发人员写用例文档 最糟糕：业务人员不管，完全由开发人员杜撰,-67-,用例规约组成,用例名称 用例标识 涉及的角色 描述 用例的规格说明 前置条件 PreConditions 后置条件 PostConditions 正常事件流 Flow of events 备选事件流 Alternate flow 其它 非功能需求、设计约束、尚存在的问题,-68-,前置、后置条件-1,前置条件约束在用例开始前系统的状态 把它们看做是看门人，它阻止角色触发该用例直到满足所有条件 说明在用例触发之前什么必须为真 后置条件约束

23、用例执行后系统的状态 用例执行后什么必须为真 对于有多个事件流的用例，则应该有多个后置条件,-69-,前置、后置条件-2,某些用例依赖于其他用例 一个用例在离开系统时，可能是另一个用例的前置条件（例如：“登录”和“管理系统”） 有助于识别漏掉的用例 如果一个用例的前置条件不能有执行其他用例满足，可能意味着丢失了用例（例如：“管理订单”却没有“登录”用例）,-70-,用例交互四部曲-事件流,1. 动 作,4. 回 应,2.改变,3.验证,系 统,写：可观测的、体现客户利益的文字,-71-,事件流描述要点,1.只书写“可观测”的 2.使用主动语句 3.句子必须以角色或系统作为主语 4.不要涉及界面

24、细节 5.分支和循环,-72-,要点1：只写“可观测”的,系统通过ADO建立数据库连接，传送SQL查询语句，从“商品表”查询商品的详细信息 系统按照查询条件搜索商品的详细信息,-73-,要点2：主动语句,用户输入搜索条件，页面显示系统搜索的结果 出纳员 系统,-74-,要点3：以角色或系统作主语,角色 系统 出纳员接收顾客的付款顾客的付款数可能高于商品总额 出纳员录入顾客所付的现金总额 系统显示出应找还给顾客的余额，打印付款收据,-75-,要点4：不涉及界面细节,会员从下拉框中选择类别 会员在相应文本框中输入查询条件 会员点击“确定”按钮,-76-,要点5：分支和循环,分支：放到扩展路径 角色

25、的选择 另一条成功线路 系统进行验证 循环：直接描述,-77-,用例规约：记录时间,UC01：“Record Time”用例文档 用例名称：Record Time（记录时间） 用例标识：UC01 涉及的角色：雇员、系统管理员 描述：雇员利用“Record Time”用例来登记他们的工时 系统管理员用这个用例为任何雇员登记时间 前置条件：用户必须已经登录到这个系统 后置条件：系统将雇员的工时正确的记录到数据库中,-78-,用例规约：记录时间(续),正常事件流（Basic Flow）： 雇员查看当前时间之前输入的数据； 雇员从已有的支付号码中选择一个，这些收费代码是按客户和项目组织的； 雇员从当前

26、的时间段选择一个日期； 雇员输入以正整数表示的工时； 系统在视图中显示这个数据，并在以后的视图中看到这个数据。 备选事件流（Alternative Flow）1：雇员更改他的时间 雇员查看当前时间之前输入的数据； 雇员选择一个已有的条目； 雇员改变工时； 在视图中更新这个信息，并在以后的视图中都可以看到。,-79-,用例规约：记录时间(续),非功能需求：无 设计约束：无 部署约束：用户可以从客户端或雇员的家中访问到“Record Time”用例，如果是从客户端访问，则要考虑到客户端的防火墙 未解决的问题 雇员是否可以在以前的考勤卡上输入和更改时间 雇员是否可以在以后的考勤卡上输入和更改时间，例

27、如，在休假之前？,ATM取款用例描述,80,用例编号:001用例名:ATM取款用例描述:储户使用信用卡，在ATM机上取款角色：储户前置条件：ATM机器处于正常准备状态后置条件：若成功，则储户取出钱，帐户上扣除钱；若失败，储户没有取到钱，帐户上钱数不变。基本路径1. 储户插卡；2. ATM机提示输入用户口令；,ATM取款用例描述,81,3.储户输入口令；4.ATM机口令验证通过，提示输入钱数；5.储户输入钱数；6.ATM机进行钱数有效性检查，提示操作成功，吐出卡和钱；7.储户取走卡和钱；8.ATM机屏幕恢复为初始状态。扩展点4a. ATM机验证用户口令不通过4a1.ATM机给出提示信息，并吐出信

28、用卡；4a2.储户取出卡；,ATM取款用例描述,82,4a3. ATM机屏幕恢复为初始状态.6a. ATM验证用户输入钱数超过30006a1. ATM机给出提示信息，并吐出信用卡；6a2. 储户取出卡；6a3. ATM机屏幕恢复为初始状态.。变异点无补充说明,-83-,活动图-简述用例流程,-84-,活动图Activity Diagram,通过动作来组织，主要用于描述某一方法、机制或用例的内部行为 活动（Activities）, 动作（Actions）, 转移（Transitions）、决策（Decision）、同步条（Synchronizations） 业务对象（Business objec

29、ts） 起始状态（The start state）、终止状态（The end state）,-85-,活动图-推荐的使用场合,分析用例：能直观清晰地分析用例，了解应当采取哪些动作以及这些动作之间的依赖关系。一张完整的活动图是所有用例的集成图 理解牵涉多个用例的工作流：在难于区分不同用例而对整个系统的工作过程又十分清楚时，可以先构造活动图，然后用切片技术派生用例图 处理多线程应用：采用“分层抽象，逐步细化”的原则描述多线程,-86-,基于用例的需求分析过程,1. 获取原始需求 2. 开发一个可以理解的需求 2.1 识别角色 2.2 识别用例 2.3 构建用例图 3 详细、完整地描述需求 进行用例

30、阐述 4 重构用例模型(高级用例建模方法) 4.1 识别用例间的关系 4.2 对用例进行组织和分包,-87-,4.1 用例关系,Extend,Include,Generalization,-88-,通过关系整理文档,Extend 分离扩展路径 Include 提取公共步骤，便于复用 Generalization 同一业务目的的不同技术实现,-89-,扩展关系,基用例路径本身是完整的，可能是一条扩展路径 扩展路径步骤多 扩展路径内部还有扩展点扩展之扩展,90,扩展举例,-91-,扩展关系误用,-92-,识别扩展点思路,执行者的选择 系统验证 步骤失败 ,必须是系统能感知的,-93-,包含关系,某

31、些步骤在多个用例重复出现，且单独形成价值 用例步骤较多时，可用Include简化（慎用）,94,例子：,-95-,包含关系误用,-96-,泛化关系,同一业务目的不同技术实现： 一个用例可以特化另一个更普通用例（更普通用例泛化特殊用例） 用例间的泛化关系表明子用例包含父用例中定义的所有属性、行为序列和扩展点，并且参与父用例中所有的关系,-97-,用例关系：扩展 VS. 泛化,采用不同关系，文档结构不同,-98-,重构后的用例图：考勤卡系统,-99-,4.2 为什么要对用例进行分级,用例和开发周期 开发周期是围绕用例的需求来组织的 一个开发周期要被指派一个到多个用例，如果完全版本的用例在一个开发周

32、期中处理起来太复杂的话，那就采用简化版本的用例,开发周期,开发周期,开发周期,用例A -简化版本,用例A -完整版本,用例B,用例C,-100-,用例分级原则,用例分级的一个基本原则 高级别的用例是那些对系统核心体系结构影响最大的用例 提高用例级别的特性： a. 对体系结构设计有重要影响的用例，如在领域层中增加多个类的用例或者需要持久化的用例 b. 不需要花费很多努力就可以从中获得重要信息和线索的那些用例 c. 含有开发风险、时间紧迫或功能复杂的用例 d. 涉及到重要技术研究或者新技术和高风险的用例 e. 代表主要的在线业务流程的用例 f. 能产生直接经济效益或者降低成本的用例,-101-,用

33、例分级实施策略,可以使用一个简单的但是有些不精确的分级方法，如将用例划分成高、中、低三个等级,-102-,用例的组织,对用例进行分包 让用例图能够更为清晰地表现出系统的业务逻辑关系和层次 对系统进行模块的分割，这将影响到今后的开发和系统的最终表现形式 常见的分包方式 按角色分包 按主题分包 按开发团队分包 按发布情况分包,可以先按主题分包，主题内再按开发团队和发布情况分包,-103-,补充需求规约 Supplementary Specification,补充需求规约Supplementary Specification 非功能需求(URPS) 可用性（Usability） 可靠性（Reliab

34、ility） 性能（Performance） 可支持性（Supportability） 设计约束 用Oracle数据库平台，用PB开发 软件必须符合ISO标准 本质上不是需求，只是从商业、行政、技术上的约束 词汇表Glossary 描述数据,-104-,题外话：何时适用用例建模,用例是从角色角度捕获系统功能，当系统只有一个或者没有角色时，显然它们不是非常有效的 用例捕获功能需求，因此它们对于系统的非功能需求不是有效 当遇到下述情况时，用例是需求捕获的最好选择 系统由功能需求所主导 系统具有很多类型的用户，系统对他们提供不同的功能 系统具有很多接口 当遇到下述情况时，用例是一个糟糕的选择： 系统

35、有非功能需求所主导（如：Google） 系统具有很少的用户 系统具有很少的接口（非内部功能） 如：嵌入式系统、算法复杂但接口少的系统等,105,需求分析中的用例建模步骤,创建用例图模型有4项任务：找出系统中的角色和用例。 区分用例的优先次序。 细化每个用例。 建立用例图模型结构。,106,1.识别角色,例： 对一个成绩管理系统进行需求分析，可识别出如下角色及其需求。 学生（student）：浏览系统记录的成绩。 授课教师(teacher)：使用系统为学生记录成绩、更新成绩、浏览成绩，并可通过计算机发布报告卡。 管理人员（administrator）：负责创建报告卡，并浏览检查报告卡。,107,

36、1.识别角色,基于这些角色及其需求，通过回答前面的问题，可以建立如下用例： 记录成绩（Record grades） 更新成绩（update grades） 生成报告卡（generate report cards） 检查报告卡（check report cards) 分发报告卡（distribute report cards ） 浏览成绩（view grades),108,Record grades,Update grades,Generate report cards,Check report cards,Distribute report cards,View grades,109,2、区分

37、用例优先次序,这项任务通常是由系统分析人员完成，他们对哪一项任务最关键，哪一项任务最艰巨有最好的全局认识。他们还可以确定出哪个用例可以为其他用例所重用。在上例中，可以轻松地提出以下优先次序列表： 记录成绩 测览成绩 更新成绩 生成报告卡 检查报告卡 分发报告卡某些用例必须在其他用例之前完成，因为它们之间要相互依赖。例如，在系统更新成绩之前，必须记录成绩。因此很明 显，Record Grades是最重要的用例。,110,3、细化用例的描述,在用例图中的用例通常只是简单地给出了系统应提供什么服务，并没有展示出如何提供服务，如服务的具体功能、处理流程、场景、出错情况以及异常情况等信息。这就需要对用例

38、进行更详尽的描述。用例的描述常采用文字列表形式，也可采用UML图形描述，如交互图、活动图等。这里给出用例的文字列表形式，有关图形描述见后面章节说明。,111,例 记录成绩用例的描述,记录成绩,112,4、构建用例图模型,将已确定并细化的角色和用例放入用例图。此时，再借助关联（包含）和泛化的关系给出用例之间的结构模型。,113,3.6 需求分析用例建模案例,以“企业综合信息管理系统”为例，介绍需求分析阶段的业务和系统用例建模的步骤。 3.6.1 客户需求分析 1业务组织结构（综述）“企业综合信息管理系统”的用户是企业各级管理部门的工作人员、公司经理和系统操作人员。该系统主要提供“财务管理”、“人

39、力资源管理”、“生产调度管理”、“进销存管理”、“设备安全管理”、和“行政事务管理”等方面的服务。,114,2具体功能要求 本案例只对其中的“进销存管理子系统”进行详细的需求分析用例建模。（1）销售管理1）制定销售计划2）与客户签订销售合同3）检查合同履约率4）生产调度管理部门组织生产5）库存管理部门对产品进行入库、出库处理6）财务管理部门收取客户货款7）售后服务,115,（2）采购管理 1）制定原材料（零部件）采购计划 2）与客户签订采购合同 3）检查合同履约率 4）库存管理部门对原材料进行入库验收、存储 5）财务管理部门支付货款 （3）库存管理 1）产品入库管理 2）原材料（零部件）入库管

40、理 3）原材料（零部件）出库管理 4）产品出库管理 5）库存管理 6）采购管理部门组织采购 7）生产调度管理部门安排生产 8）财务管理部门对库存物资进行核算,116,3需求补充说明 （1）数据保存 采购合同：每个合同执行期可能多达几个月，合同需要长期保留。 销售合同：每个合同执行期可能多达几个月，合同需要长期保留。 历年履约合同：履约后的合同需要长期（几十年）保留，以备查使用。 库存货物清单：库存货物量随出、入库有所消长，长期保存。 货物损毁报表：长期保留，以备查使用。 入库单：长期保留，以备查核算使用。 出库单：长期保留，以备查核算使用。 库存货物资产核对表：长期保留，以备查使用。,117,

41、（2）系统的用户 客户、仓库管理员、销售人员、采购人员、公司经理、财务管理系统、生产调度管理系统。（3）系统运行用户界面 销售合同管理用户界面： 采购合同管理用户界面： 仓库货物清单管理用户界面：（4）系统运行的软件、硬件环境1）系统运行的软件环境2）系统运行的硬件环境,118,3.6.2 确定系统范围和系统边界 1进销存管理子系统的业务范围 2进销存管理子系统的系统边界3.6.3 确定执行者“进销存管理子系统”有5个人执行者和2个系统执行者，即“采购人员”、“销售人员”、“仓库管理员”、“客户”、“公司经理”、“生产调度管理子系统”和“财务管理子系统”。,119,3.6.4 确定用例 （1）

42、“企业综合信息管理系统”中的用例（一层） 财务管理； 人力资源管理； 生产调度管理； 进销存管理； 设备安全管理； 行政事务管理。 （2）“进销存管理子系统”中的用例（第二层） 销售管理； 采购管理； 库存管理。 （3）“销售管理子系统”中的用例（第三层） 制定产品销售计划； 签订销售合同； 督促客户付款； 监督产品发货； 检查合同履约； 提供售后服务。,120,（4）“采购管理子系统”中的用例（第三层）制定采购计划；签订采购合同；货物入库检验；支付货款；检查合同履约。 （5）“库存管理子系统”中的用例（第三层）入库管理；出库管理；库存管理。,121,3.6.5 分层绘制用例图 1最高层用例图

43、,122,2第2层用例图,123,3第3层用例图,124,4第4层用例图,125,126,3.6.6 描述用例 1“增加销售合同”用例 用例编号：04010101（共有4层用例图结构，每层用2位数字表 示， 采用8位编号。） 用例名： 增加销售合同 执行者: 人执行者：合同管理员、客户、公司经理。系统执行者：“财务管理子系统”和“生产调度管理子系统”。 目 的: 合同管理员将与客户签订的销售合同的详细内容录入管理系统，用于对销售合同进行统计、查询、检查是否履约等，监控正在履约的合同。 类 型： 端点、主要的、基本的 级 别： 一级,127,过程描述： （1）合同管理员输入标识码（ID），系统识

44、别标识码的有效性； （2）初始化一个新销售合同，设置各种处室标志； （3）输入一个新的具有唯一性的合同编号； （4）将与客户签订的销售合同的详细内容录入管理系统； （5）退出系统。 与其它用例的关联：过程描述（1）中包含身份验证用例；（4）中包含编号自动生成用例。 异常事件流处理： （1）标识码有效性检查失败：系统检测标识码有效性失败，允许重新输入。 （2）编号也可以由合同管理员手动输入，系统自动进行唯一性检查。出现错误，允许重新输入。2“修改合同”用例 ,128,建模要点,构建结构良好的用例： 1）为系统和部分系统中单个的、可标识和合理的原子行为命名； 2）将公共的行为抽取出来，放到一个被包

45、含用例中，再将它include进来； 3）对于变化部分，将其抽取出来，放到一个扩展用例（用extent连接）中； 4）清晰地描述事件流，使得读者能够轻而易举地理解 构建结构良好的用例图：摆放元素时，应该避免交叉线的出现 ；对于语义上接近的行为和角色，最好使它们在物理上也更加接近； 根据系统实际情况控制粒度,129,例子,有一个爱书之人，家里各类书籍已过千册，平时又时常有朋友外借，因此需要一个个人图书理系统。该系统应该能够将书籍的基本信息按计机类、非计算机类分别建档，实现按书名、作类别、出版社等关键字的组合查询功能。在使用系统录入新书籍时系统会自动按规则生成书号，以修改信息，但不能够删除记录。该

46、系统还应该够对书籍的外借情况进行记录，可对外借情况列打印。另外，还希望能够对书籍的购买金额、册按特定时限进行统计。,130,用例图的绘制流程,131,记录需求特性表,132,识别角色,已有的上下文关系图（表示系统范围）及其他相关模型：它们描述了系统与外部系统的边界，从这些图中可以寻找出与系统有交互关系的外部实体。 项目相关人员分析：对项目的相关人员进行分析，就能够决定出哪些人将会与系统进行交互。 书面的规格说明和其它项目文档（如会谈备忘录等） 需求研讨会和联合应用开发会议的记录：这些会议的角色通常是很重要的，因为他们在组织中所代表的角色就是可能与系统发生交互的角色。 当前过程和系统的培训指南及

47、用户手册：这些东西中经常会有潜在角色。,133,合并需求获得用例,134,错误-不能用include,135,优化,136,建模要点,构建结构良好的用例： 1）为系统和部分系统中单个的、可标识和合理的原子行为命名； 2）将公共的行为抽取出来，放到一个被包含用例中，再将它include进来； 3）对于变化部分，将其抽取出来，放到一个扩展用例（用extent连接）中； 4）清晰地描述事件流，使得读者能够轻而易举地理解 构建结构良好的用例图：摆放元素时，应该避免交叉线的出现 ；对于语义上接近的行为和角色，最好使它们在物理上也更加接近； 根据系统实际情况控制粒度,137,作业,网上选课系统：管理员通过

48、系统管理界面进入，建立本学期要开的各门课程，将课程信息保存在数据库中，并可以对课程进行改动和删除。学生通过浏览器根据学号和密码进入选课界面，在这里学生可以查询已选课程信息并选课，教师可以选择所上课程并提交成绩。 管理员负责维护各项信息。这些操作结果存入数据库中。请用UML画出其用例图，并写出详细的用例述。,138,139,现有一医院病房监护系统，病症监视器安置在每个病房，将病人的病症信号实时传送到中央监视系统进行分析处理。在中心值班室里，值班护士使用中央监视系统对病员的情况进行监控，根据医生的要求随时打印病人的病情报告，定期更新病历，当病症出现异常时，系统会立即自动报警, 并实时打印病人的病情

49、报告，立及更新病历。要求根据现场情景，对医院病房监护系统进行需求分析， 建立系统的Use case model。,140,请对系统需求进行分析！,经过初步的需求分析，得到系统功能要求： 1、监视病员的病症（血压、体温、脉搏等） 2、定时更新病历 3、病员出现异常情况时报警。 4、随机地产生某一病员的病情报告。,例2 医院病房监护系统,监视病情,更新病历,情景教学,141,二、简单的需求分析说明系统名称：医院病房监护系统根据分析系统主要实现以下功能：1、病症监视器可以将采集到的病症信号（组合），格式化后实时的传送到中央监护系统。2、中央监护系统将病人的病症信号开解后与标准的病症信号库里的病症信号的正常值进行比较，当病症出现异常时系统自动报警。3、当病症信号异常时，系统自动更新病历并打印病情报告。4、值班护士可以查看病情报告并进行打印。5、医生可以查看病情报告，要求打印病情报告，也可以查看或要求打印病历。6、系统定期自动更新病历。,