第8章 面向对象分析3.pptVIP

面向对象分析（3） 使用“用例”来表达系统的功能 8.4 用例模型 分辨信息系统的边界 什么是用例 用例的概念、目的 识别参与者 识别用例 绘制用例图 如何描述用例 用例分解，确定用例关系 8.4.1 用例的概念 用例创始人雅各布森Ivar Jacobson认为： 用例（use case）是对于一组动作序列的描述，系统执行这些动作会对特定的参与者（actor）产生可观测的、有价值的结果。 阿里斯代尔·科克伯恩Alistair Cockburn： 强调用例是各种系统受益人（stakeholder）之间的一种行为契约（contract）。行为包括对象的活动、动作和对象之间的交互等。建立契约的目的是为了达成某种目标，因此每一个用例实际上都应代表一个用户目标，根据三个目标层次（概要层、用户目标层、子功能层）将用例进行分层，从而有效把握用例的粒度。 用例的意义 用例是对系统需求（主要是功能需求）的规范化的描述。 用例图及用例的事件流描述集中体现了系统责任， 通过用例建立交互图。交互图就是用例的具体实现，即系统中的对象以及对象间协作是如何完成一个用例的全部过程。 用例驱动的开发过程，从用例模型到分析模型和设计模型之间有一致性和可追踪性。 用例建模的内容 基于用例的需求获取过程： 1. 获取原始需求 2. 开发一个可以理解的需求 识别参与者 识别用例 构建用例图 3 详细、完整地描述需求 书写用例规格说明 4 重构用例模型 识别用例间的关系 对用例进行组织和分包 1、识别参与者 参与者是系统之外与系统进行交互的任何事物。 使用系统的个人 谁负责提供、使用或删除信息？ 谁将使用某项功能？ 系统所连接的外部硬件。 例如，控制建筑物中温度的通风系统不断地从传感器获取温度信息，传感器就是一个参与者。 与该系统进行通信的其他信息系统。 例如为自动柜员机系统建模时，中央银行系统就是它的一个参与者。信用卡系统是销售系统中的一个参与者 区分参与者和外部实体 只有在执行系统功能时与信息系统进行实时交互的人员才能被当作参与者 外部实体是指数据的来源和去向，提供数据的人员不一定会执行系统功能 新生入学手工填写个人信息，然后由教务人员统一将数据登记到学籍系统中，教务人员是参与者。 如果学生直接通过Web方式提交个人信息，则认为学生是参与者。 区分主要参与者和次要参与者 主要参与者（primary actor）是从系统中直接获得可度量价值的用户。 次要参与者（secondary actor）的需求驱动了用例所表示的行为或功能，在用例中起辅助支持作用 用例分析的重点是要找到主要参与者。 比如，在图书馆的借/还书用例中，首先要考虑谁直接使用这一功能，谁频繁地和系统进行交互？图书管理人员是直接操作者，他们的需求和变化对于用例的影响最大。因此，图书管理员是主要参与者。 参与者举例 参与者的表示 在UML中，参与者使用小人符号： 参与者的泛化 在某些情况下，参与者的角色可以有共性，或者说一般性，一种角色可以拥有另一种角色的全部行为。 比如在超市系统中，值班经理完全可以充当收银员这一角色，此外，值班经理还可以有退货、更改事务等权利。 2、识别用例 用例就是功能性需求。 每个用例至少和一个参与者相关，用例名称要体现参与者希望系统提供的功能。 用例的UML图形表示 区分用例和用例完成的步骤 不能混淆用例和用例所包含的步骤。 比如“借出图书”功能要经过验证读者信息、检查超出可借数量、保存借书记录、修改图书状态等步骤 在系统中这些步骤通常不作为单独的功能提供给参与者使用，它们只是一个用例所包含的事件流，或者是用例的子功能。 与结构化分析中提到的事件概念相同。 区分业务用例和系统用例 当针对整个业务领域建模时，需要使用业务用例 比如图书馆系统有一项重要工作就是“整理书架”，图书都要放回到固定的位置上 信息系统作为整个业务系统的一部分，只负责实现系统的部分功能，即有信息处理的那部分功能。 用例举例1 客户提出申请要求贷款，申请中包括期限、金额、用途和本人基本情况。银行收到申请后，置于“申请档案”中，以申请号标识。 某公司内部工作岗位的提供：不论何时，只要一有职位空缺，该地区的人力资源部领导就会通知该地区的所有员工并给其他地区的HR领导发送消息，邀请员工们提出申请。然后，其他地区HR领导将招聘信息贴在公告板上。所有对此感兴趣的员工都可以将申请发送到职位空缺的地区的HR领导那里。 用例举例2 在门诊挂号处只能挂当天的号，挂出的号可以退。 病人拿到挂号单后，到相应的科室进行就诊。医生根据挂号的顺序号，依次给病人看病开处方。 病人拿处方去收款处交费，并拿到发票。 病人拿已经收费的处方去药房拿药。 该系统潜在的参与者和用例有哪些？ 图书馆系统的用例图 8.4.2 用例的描述 用例