UML-CHP02_用例图解析.ppt

面向对象建模第2章　需求分析与USECASE模型 提纲 2.1　软件需求的概念 什么是软件需求 需求分析的困难 2.2　用例建模 基本元素及关系 场景 反模式 2.3 本章小结 软件需求定义 软件需求分析的困难 (1)客户说不清楚需求 有些客户对需求只有朦胧的感觉，当然说不清楚具体的需求。 农夫和耕牛的故事 有些客户心里非常清楚想要什么，但却说不明白。 我的鞋是什么样的？ “不懂装懂”或者“半懂充内行”的客户令人恐惧 软件需求的复杂性 (2)需求自身经常变动 软件需求的复杂性 (2)需求自身经常变动 用例图(UseCase Diagram) 用例是从系统的外部对系统进行黑盒视图描述的一种组织方法。 用例是抽象使用系统的一种方式，用户通过用例与系统交互。用例图主要的作用有三个： 用例图 如何识别参与者? 在系统之外，透过系统边界与系统进行有意义交互的任何事物都是参与者． 对于一般规模的软件系统，参与者不会太多，一般有这样几种类型的参与者： 与系统交互的用户 与系统交互的外部系统 与系统交互的外部硬件 特别注意：有时候时间触发器也可以看成是参与者 如何识别用例？ ＲＵＰ（Jacobson）：用例实例是在系统中执行的一系列动作，这些动作将生成特定参与者可见的价值结果。一个用例定义一组用例实例。 通俗地，用例是参与者利用系统所要达到的目标． 用例的要点 价值结果 用例的结果形成有意义的目标 执行者可见 采用业务语言，从用户观点描述 一组用例实例 用例的实例也称为场景：是执行者使用系统的一个特定情节或用例的一条执行路径。例如： 通过输入电话号码拨打电话的场景 通过查打电话号码簿拨打电话的场景 通过查打电话号码簿拨打电话,电话打到一半电话欠费的场景 建立用例模型的参考原则 用例是短文 用例可以是一个场景，包括动作和交互 用例可以是一组场景，描述不同场景下的行为。这种书写格式可以在任何时候描述有变化的行为，例如黑盒需求，业务流程，系统设计说明。 用例里不要有系统设计 用例里不要有界面设计 用例里不要有测试 用例应该描述行为需求 用例的主场景最好不要超过9步 用例的最大价值不在于主场景，而在于备选行为。 用例建模的步骤 确定系统的范围和边界 确定执行者 确定用例 对用例进行描述 定义用例之间的关系 审核用例模型 用例的文字描述应包括以下内容 用例的目的（功能）； 该用例在什么情况下被哪个参与者启动执行； 用例与参与者之间交互哪些消息来通知对方作出决定； 交互的主消息流及因此被使用或修改的实体； 用例中可供选择的异常事件流； 用例的结束标志：给参与者返回一个可识别的值． 举例： 　　用例名称：学生选课　　　　执行者：学生 　　目　　的：完成一次学生选课的完整过程． 　　类型：主要的，基本的 　　级别：一级 过程描述： 学生输入学号/密码，系统识别账户的有效性； 对学生进行注册识别； 浏览本学期预开课程； 选择学生自己要上的课程并确认； 退出系统，系统给出所选课程列表及相应学分合计 异常事件流： 账户有效性检查失败，允许学生重新输入（最多３次机会）． 注册识别失败，没有注册（未交学费）的学生不能选课． 选择课程确认失败，所选几门课程在时间上发生冲突，系统提示重选． 用例图 用例间关系-include 包含用例的行为插入到基本用例中的一个位置。 当遵循基本用例说明的用例实例到达基本用例中定义了包含关系的位置，它就将改而遵循包含用例的说明。一旦执行完包含用例，用例实例就将在基本用例中它先前停止的地方重新开始。 用例的包含关系的要点 1.包含用例本身是不完整的，它必须拥有基本用例以保证完整性。 2.包含用例本身并不知道自己何时或是否被包含。因此，它不能依赖任何包含它的用例。 3.被包含的用例一定可以被另外的用例包含(即共用性和独立性) 4.从工程角度上，包含关系用于系统分析时共性功能的合并、抽取。 5.包含关系通常在用例建模后期而不是前期被发现。 描述包含关系 应在基本用例的行为序列中定义要插入包含用例的位置。 要定义该位置，可以引用基本用例事件流中的特定步骤或分支流。 用例扩展关系的概念 一个用例的实例可能增加了一些附加的行为，这些附加的行为在另一个用例中定义，扩展定义了这两个用例之间的关系。 基本用例可以单独存在，但是在一定的条件下，它的行为可以被另一个用例的行为扩展。 当一个用例有多个可选系统行为时，可以用扩展关系对其进行扩展，使得基本用例的不同子流程能在不同的情形下以扩展用例的形式被激活。 通过这种方式，可以把可选行为从必须行为中分离出来。 用例间关系-extends 扩展用例可以有基本事件流和备选事件流。 用例实例通过扩展到底会采取哪条路径，这不仅取决于在执行之执行扩展前发生的事件，而且还取决于