[理学]第3章用例和用例图.pptVIP

第3章 用例和用例图 3.1 用例图 3.2 参与者 3.3 用例 3.4 用例间的关系 3.5 用例视图 3.6 事件流及脚本 3.7 用例的描述 3.8 实例——-图书馆管理系统中的用例图 3.1 用例图 使用场合： 用例图显示谁将是相关的用户、用户希望系统提供什么服务以及用户需要为系统提供的服务。 用于表现系统根据需求所提供的功能 用例图最常用来描述系统以及子系统。 3.1 用例图 用例图包含6元素： 参与者（Actor） 用例（Use Case） 用例间关系（Association） 脚本（Scenario） 描述（Description） 系统 3.1 用例图 3.2 参与者 参与者指系统外部的、需要使用系统或与系统交互的一个实体。 参与用例的执行过程。 通过向系统输入或请求系统输入某些事件来触发系统的执行。 每个参与者可以参与一个或多个用例。 一个用例可以由多个参与者使用 3.2 参与者 参与者的种类： 系统用户（人） 与所建造系统交互的其他系统（外部系统） 设备 图形表示： 确定参与者 参与者的识别 谁将使用系统的主要功能？ 谁将需要系统的支持来完成他们的日常任务？ 谁必须维护、管理和确保系统正常工作？ 谁将给系统提供信息、使用信息和删除信息？ 系统需要处理哪些硬件设备？ 系统使用了外部资源吗？ 系统需要与其他什么系统交互吗？ 谁或者什么对系统产生的结果感兴趣？ 一个人同时使用几种不同的规则吗？ 几个人使用相同的规则吗？ 系统使用遗留下来的应用吗？ 参与者间的关系 在用例图中，使用泛化关系来描述多个参与者之间的公共行为。 示例： 子参与者继承父参与者的行为和含义，并能增加自己特有的行为和含义 子参与者可以出现在父参与者能出现的任何位置上 3.3 用例 定义： 对一组动作序列的描述，系统通过执行这一组动作序列为参与者产生一个可观察的结果 3.3 用例 用例特征： 用例从使用系统的角度描述系统中的信息，是从系统的外部查看系统的功能，不考虑系统内部的具体实现 说明了一个参与者与系统执行的一个相关事务序列 用例描述了用户提出的一些可见需求，对应一个具体的用户目标 用例是对系统行为的动态描述，属于UML的动态建模部分 提供了一种与最终用户和领域专家进行沟通的方法 提供了一种测试系统的方法 3.3 用例 图形表示 用椭圆形表示，用例的名字显示在图标的下面 例1，字处理程序 例2，银行业务系统 3.3 用例 注意： 不要把所有需求都以用例的形式表示出来，只把重要的、交互过程复杂的用例找出来 用例不是系统的全部需求，全部需求包括：系统的目的和范围；系统中的术语表；用例；系统采用的技术；开发过程中的参加人员、业务规则、系统运行所依赖的条件等；法律、政治、组织机构等 用例是与实现无关的关于系统功能的描述。是一种功能分解的技术，并没有使用面向对象思想。 3.3 用例 协作 是对由共同工作的类、接口和别的元素所组成的群体的命名，这组群体提供合作的行为。 协作的内部由两部分组成： 结构部分：类等建模元素 行为部分：建模元素如何协调工作 图形表示 识别用例 用例识别识别用例最好的方法就是从分析系统的参与者开始，考虑每个参与者是如何使用系统的。 参与者要向系统请求什么功能？ 每个参与者的特定任务是什么？ 参与者需要读取、创建、撤消、修改、或存储系统的某些信息吗？ 是否任何一个参与者都要向系统通知有关突发性的、外部的改变？或者必须通知参与者关于系统中的发生的事件？ 这些事件代表了哪些功能？ 识别用例 用例识别 系统需要哪些输入/输出？ 这些输入输出来自哪里或者到哪里去？ 哪些用例支持或维护系统？ 是否所有功能需求都被用例使用了？ 系统当前实现的主要问题是什么？ 3.4 用例间的关系 关系反应了参与者和用例之间、用例和用例之间以及参与者和参与者之间的相互作用。 1 关联关系 2 包含关系 3 扩展关系 4 泛化关系 关联关系 表示参与者用例之间进行通信。信息可以双向流动。 关系方向显示的不是信息的流动方向，而是谁启动信息。 表示 工具箱： 模型图中： 关联命名 一个动词或者一个动词短语，用于指明关系的类型或者目的。 关联关系 用例图的两种类型关联： 1、单向关联 2、双向关联 包含关系 将若干用例的相同动作，提取出来单独构成一个用例。这个用例可以重用 描述的是基本用例需要某种类型的行为，而包含用例定义了该行为，那么在用例的执行过程中，就可以调用已经定义好的用例。 特点：由基本用例决定是否调用，包含用例对调用对象一无所知，且不参与其中的选择判断。 图形表示