网站需求分析.pptVIP

??c. 包含(Include) 一个用例（基用例，基本用例）可以包含其他用例（包含用例）具有的行为，并把它所包含的用例行为作为自身用例的一部分，这被称为包含关系。 包含关系用来把一个较复杂用例所表示的功能分解成较小的步骤。 【箭头形式】：包含关系表示为虚线箭头加《inclusive》 【箭头方向】：箭头从基本用例指向包含用例。???? ?d. 扩展(Extend) 扩展关系是指用例功能的延伸，相当于为基础用例提供一个新的附加功能（或行为）。 【箭头形式】包含关系表示为虚线箭头加《extend》 【箭头方向】箭头从扩展用例指向基本用例。 扩展关系可以有控制条件，一般情况下，基本用例的执行不会涉及到扩展用例，只有满足用例的控制条件时，扩展用例才被执行，因此扩展关系处理事件流的异常或者可选事件。 同一个基本用例的几个扩展同时满足条件时可以在一起使用。 基本用例不知道扩展的任何细节，没有扩展用例，基本用例是完整的。 泛化、包含、扩展的区别： 比较用例之间的关系 条件性： 泛化中的子用例和包含中的被包含的用例会无条件发生 扩展中的延伸用例的发生是有条件的； 直接性： 泛化中的子用例和扩展中的延伸用例为参与者提供直接服务 包含中被包含的用例为参与者提供间接服务。 包含性： 泛化中的子用例及包含关系中的基础用例，包含父用例及包含用例的所有内容及其和其他用例或参与者之间的关系； 对扩展而言，延伸用例并不包含基础用例的内容，基础用例也不包含延伸用例的内容。 5、用例图绘制步骤： ⑴ 确定子系统边界：找出系统外部的参与者和外部系统，确定系统的边界和范围。 ⑵ 分析需求：确定每一个参与者所期望的系统行为 ⑶ 确定用例：把这些系统行为命名为用例 ⑷ 分析用例关系：使用泛化、包含、扩展等关系处理系统行为的公共或变更部分 ⑸ 具体化用例内容：编制每一个用例的描述 ⑹ 绘制用例图 ⑺ 区分基本事件流和异常情况的事件流，如有需要可以把表示异常情况的事件流作为单独的用例来处理 ⑻ 细化用例图，解决用例间的重复与冲突。 练习一： 某餐厅为顾客提供餐食和酒水，侍应生在顾客点餐后将菜单交厨房确认和制作，顾客消费后到收银台结账。 请为该餐厅的管理信息系统开发画出用例图。 用例绘制都有些什么常见问题 1. 不知如何入手? 功能角色分析。从系统中包含怎样的角色开始，逐步整理相关的功能。 在这个过程中，首先，系统划分?几个子系统?几个功能模块。然后，为每个功能模块绘制用例图。 2. 没有正确理解用例图的视角。 用例图的视角是用户 从这个视角，用户看到的系统是一项一项的功能，这些功能是客户能够理解的、具体的、对客户存在价值的功能。 举个简单的例子，一个员工档案信息系统，以往我们总爱将用例取名为“添加员工信息”、“更新员工信息”、“删除员工信息”，这就是典型的技术人员编写的用例。“添加员工信息”对于用户来讲应当是做什么呢——填写新员工资料；“更新员工信息”对于用户来讲又是做什么呢——更改员工资料；“删除员工信息”又是什么呢——员工注销。 3. 图形绘制杂乱无章。 绘制用例图要学会拆分，由粗到细地一个一个绘制。先整体的绘制，再划分成各个模块一个一个详细绘制，再进一步细化。 一个系统，特别是一个大型系统，提供给用户的功能是繁杂的。描述一个系统应当有许许多多的用例图。如果你想将所有的功能，不管粗的细的，都试图绘制在一个用例图中，几乎没人看得懂。 4. 用例是一个场景。 在现实世界中，我们常常面对的是一个个长而复杂的操作流程，但在软件世界里，我们要将它们拆分成一个个的用例，怎样拆分？一个用例必须有一个场景，也就是时间相近、地点单一的一系列操作。每个用例都有确定的场景，明确的目的和结果。 举例（见下页） 如图所示的用例图，“申辩申请”就是过错责任人填写了一张申辩申请单，最终的结果是将申辩申请单提交给考核管理员；“申辩受理”就是考核管理员接收了过错责任人的申辩申请单并予以受理，当然另一个结果是对其不予受理，该申请单被退回给过错责任人。 3.3.3 用例描述(Use Case Narrative) 用例图中很多细节信息都没有明确的表示出来，只是勾勒了一个大致的系统功能轮廓，更重要的是需要用例描述部分来说明。 用例描述的是一个系统做什么（what）的信息（即功能需求），并不说明怎么做（how），怎么做是设计模型的事。 （1）一般来说，用例描述采用自然语言描述参与者与系统进行交互时的行为。它一般包括以下内容： 用例的目标 用例是怎么启动的 参与者和用例之间的消息是如何传送的 用例中除了主路径，其他路径是什么 用例结束后的系统状态 其他需要描述的内容 （2）用例描述的格式 用例描述一般也是具有规范格式的（转下页）： 用例