基于UML的软件设计和建模（2）.pptVIP

周秉锋 北京大学计算机科学技术研究所 bfzhou@icst.pku.edu.cn 基于UML的软件设计和建模(2) 上海交通大学 电子信息与电气工程学院 2006.10 Agenda 软件开发流程简介 需求捕获工作流简介 软件分析工作流简介 统一开发工程(RUP)基本流程 四次迭代 初始 精化 构建 产品化 RUP核心工作流 需求捕获工作流 分析工作流 设计工作流 实现工作流 测试工作流 Agenda 软件开发流程简介 需求捕获工作流简介 分析工作流简介 需求分析的主要任务 获取需求 明确功能性需求 明确非功能性需求 需求按优先级分类 将需求转化为用例模型 找到参与者与用例 用例细化 结构化用例模型 获取需求 需求是所有软件开发项目的基础 需求分析—根据用户对产品的功能的期望, 提取出产品外部功能的描述。 需求分为两类: 1). 功能需求: 系统应该提供什么样的功能 2). 非功能需求: 系统的某种特别性质或者限制 举例: ATM系统 功能需求: ATM系统可以检查插入的ATM卡的合法性 验证用户输入的密码正确与否 用户可以查询对应帐户余额 用户可以取款，取款限额不超过帐户余额 非功能需求 用 C++实现 与银行数据库通信时采用256位密钥加密 验证ATM卡的时间不超过3秒钟 验证密码的时间不超过3秒钟 用例建模 用例建模是需求工程的一种形式，用于引出并文档化需求 用例建模流程: - 找到系统边界 system boundary - 明确参与者actors - 明确用例 use cases: A. 明确用例明细; B. 建立场景scenarios. 用例图的组成元素 四种元素: 参与者 Actors: 使用系统的人或事物 用例 Use case: 一组系统行为 - 关系 Relationships: 参与者与用例之间的 关联、泛化和实现关系 - 系统边界System boundary: 区分系统内部和外部 外部实体与系统交互时扮演的角色 可以是用户，也可以是与这个系统交互的另外一个系统 注意：参与者总是在系统之外的 如何找到参与者 actors 考虑谁或者什么使用这个系统，并且他们在交互过程中扮演一个什么样的角色 可以问自己这样一些问题: 谁或者什么使用这个系统? 他们在交互过程中扮演什么角色? 谁安装这个系统? 谁启动或者关闭这个系统? 谁维护这个系统? 有其他系统与这个系统交互么? 谁或什么从这个系统取得或者提供信息? 这些事情是不是在某个确定时间发生的? …… 需要注意的几点: 参与者总是在系统之外的—也在你的控制之外 参与者直接与系统交互——用于定义系统边界 参与者代表用户或事物与系统交互过程中扮演的角色，而不是某一个人或者特定的事物 同一个人或者事物可能在某一时刻或在不同时刻扮演多个角色 每个参与者要有不同的名字，而且简明扼要 每个参与者需要有一个简单描述. 像类的表示一样，参与者也可以有属性或是事件 时间作为参与者 当在建模的时候发现系统某一事件是在特定时刻发生的，而不是被人触发的 可以引入一个参与者叫做Time 举例: 数据库系统每天晚上12点自动备份 什么是用例 用例描述了当系统作用者和软件系统进行交互时，软件系统所执行的一系列的动作序列。 这些动作序列包含 正常使用的各种动作序列， 对非正常使用时软件系统的动作序列的描述 注意 用例总是由参与者引发的 用例总是从参与者的角度描述的 什么是用例(续) 用例视图中用例的设置，就代表了软件系统的功能的划分。 为了得到得合理而方便的软件系统的功能设置，必须仔细考虑每个用例代表的动态行为的内容，使得每个用例都能产生一个有价值的结果。 在通过用例考虑软件系统的功能划分时，应使得功能的分布较为均衡、易于理解和使用 如何来找用例 最佳方法: 从每个参与者开始，考虑每个参与者是如何与系统交互的 可以考虑如下问题: 这个参与者要求系统提供什么功能？ 这个系统存储或者获取信息么？如果是的话，谁触发这个行为？ 系统状态变化时，要通知某个参与者么？ 有没有外部事件影响系统？ 什么事物产生这个影响？ 用例的组织和用例图 在UML里, 用例图是表达用例和系统作用者及其之间关系的的载体 用例图可包含 用例 系统作用者 它们之间的关系 这些关系可以是 关联关系(某种联系，e.g. 参与，影响，使用) 依赖关系(include, extend) 实现关系(一般--特殊) 泛化关系(参与者泛化、用例泛化) 用例明细 用例明细Use case specification 每个用例都应该有它的名字和明细specification. 用例明细包括: - 前置条件 Preconditions - 事件流 Flow of events