Chapter07-需求的OO描述方法.ppt

Chapter 7 需求的面向对象描述方法 哈尔滨工业大学 国家示范性软件学院 主讲：范国祥 2008.04 本章主要内容 UML与对象管理组织 面向对象的需求 类图 系统活动：OO的用例/场景视图 对象交互：协作图与顺序图 对象行为：状态、状态转换和状态图 本章目标 开发用例图 开发用例场景 开发顺序图 开发协作图 开发状态图 解释OO的模型图如何协同工作来提供系统功能需求 7.1 统一建模语言 - UML 的发展历史 7.1 统一建模语言 - 为 UML 做出贡献的人们 7.1 统一建模语言 - UML 工具 信息系统的OO建模流程 7.4.1 用例与参与者 用例 由系统为使用该系统的用户提供的一个单一的系统功能 参与者 由系统用户扮演的角色（也可以是其他外部实体） 参与者总在系统的自动控制边界之外 注意：如果参与者是一个人的话，则一定是亲自与系统 进行交互的人 多个参与者，多个用例 类比：从哈尔滨去北京的过程可以有多种“场景” 坐飞机 – 订票、去机场、登机、… … 坐火车 – 买票、去车站、检票、… … 驾车 - … … RMO系统：“产生新订单”用例中至少包含2个场景：（1）客户打电话通过办事员下订单 （2）客户通过上网下Web订单 描述场景的模型： （1）语言描述模型 （2）活动图模型 是概括有关参与者和用例信息的一个图形化模型 为了分析用例，将系统作为一个整体来看待 从事件列表中识别所有主要的应用 识别新系统必须支持的功能 组织用例，形成用例图 用例图的组成 用例图包含 6 个元素 参与者（Actor） 用例（Use Case） 关联关系（Association） 包含关系（Include） 扩展关系（Extend） 泛化关系（Generalization） 参与者 对参与者建模的过程中需要注意的问题 参与者对系统而言总是外部的 参与者表示人和事物与系统发生交互时所扮演的角色，而不是特定的人或特定的事物 一个人或事物在与系统发生交互时，可以扮演多个角色 用例 识别用例的方法 方法一： 从分析系统的参与者开始，考虑每个参与者是 如何使用系统的 方法二： 使用事件列表，每个事件都至少对应一个用例 用例间的关系 关联关系（Association） 表示参与者与用例之间的关系 不同的参与者可以访问相同的用例 用例间的关系 包含关系（include） 一个用例可以简单地包含其他用例具有的行为，并把它所包含的行为作为自身行为的一部分 包含关系把几个用例的公共部分抽取成一个单独的被包含用例被包含用例称为提供者用例，包含用例称为客户用例 用例间的关系 扩展关系（extend） 扩展用例被定义为基础用例的增量扩展 扩展关系是把新的行为加入到已有的用例中去 扩展用例是被基础用例有条件地使用 用例间的关系 泛化关系（Generalization） 如果系统中一个或多个用例是某一个一般用例的特殊化用例时，就应该使用用例的泛化关系 用例实例 RMO订单输入子系统用例图 用例图只是简单地标识出系统的用途 用例图不能识别系统的输入、输出及其内部的信息 交互图的目标是识别并说明系统的信息流以及对象之间的交互关系 交互图有2种：顺序图，协作图 时序图是强调消息时间顺序的交互图 时序图描述了对象之间传送消息的时间顺序，用来表示用例中的行为顺序 时序图的组成 时序图包含了 4 个元素 对象（Object） 生命线（Lifeline） 消息（Message） 激活（Activation） 时序图的组成 对象 时序图中对象的符号和对象图中对象所用的符号一样 将对象置于时序图的顶部意味着在交互开始的时候对象就已经存在了，如果对象的位置不在顶部，那么表示对象是在交互的过程中被创建的 时序图的组成 生命线 生命线是一条垂直的虚线，表示时序图中的对象在一段时间内的存在。每个对象的底部中心的位置都带有生命线 生命线是一个时间线，从时序图的顶部一直延伸到底部，所用的时间取决于交互持续的时间 时序图的组成 消息 消息定义的是对象之间某种形式的通信，它可以激发某个操作、唤起信号或导致目标对象的创建或撤销 消息是两个对象之间的单路通信，从发送方到接收方的控制信息流 消息可以用于在对象间传递参数 消息可以是信号，也可以是调用 时序图的组成 激活 激活（Activation）表示该对象被占用以完成某个任务，去激活（Deactivation）指的则是对象处于空闲状态、在等待消息 在 UML 的时序图中，为了表示对象是激活的，可以将该对象的生命线拓宽成为矩形。其中的矩形称为激活条或控制期，对象就是在激活条的顶部被激活的，对象在完成自己的