第四章 UML核心元素,4.1 版型 4.2 参与者 4.3 用例 4.4 边界 4.5 业务实体 4.6 包 4.7 分析类 4.8 设计类 4.9 关系 4.10 组件 4.11 节点,版型(stereotype),有些书也称类型、构造型——对UML中元素基础定义的扩展 UML中每一种元模型很多版型 如，用例有“业务用例”、“业务用例实现”等 类，“接口”、“边界类”、“实体类”,4.2 参与者(actor),一幅用例图包含的模型元素有系统、参与者、用例及用例之间的关系等四个基本组成部分 系统 系统被看作是一个提供用例的黑盒子 代表系统的方框的边线表示系统的边界，用于划定系统的功能范围，定义了系统所具有的功能 描述该系统功能的用例置于方框内 代表外部实体的行为者置于方框外,用例图示例,,系统边界,4.2.1 基本概念,参与者(actor)是系统的直接外部用户—直接与系统通信的一个对象或一组对象每个参与者都表示以某种方式对系统起作用的那些对象 参与者可以是人、设备和其他系统—任何与系统直接交互的事物 参与者有一个明确的目标 建模参与者有助于定义系统，识别系统内部及其边界上的对象 注意：用例总是由行为者启动的。
参与者表示使用系统的对象（？） 参与者作为外部用户与系统发生交互 参与者与系统交互作用结果-用例 没有参加任何用例的参与者是无意义的 每个参与者定义了一个角色的集合 用角色（一类）名称命名参与者，避免用张三等人名比如教师，学生，会计，审计者） 不同的参与者充当的角色不一样；有的接受用户提供的数据，有的为用例提供某种服务，有的完成系统的管理……,参与者随着项目的进展，参与者会发生变化 分析阶段：图书管理员与借出图书用例交互，借出某种图书（自然语言方式） 设计阶段：参与者变成图书管理员这个角色和这个角色使用的接口，用例变成处理对象的之间关系或与系统其他部分交互的接口 参与者可分为主要参与者与次要参与者 主要参与者：使用系统较频繁、业务量比较大的用户，使用系统的主要功能 次要参与者：使用系统的次要功能-完成系统维护等一般功能 例：主要参与者负责图书的日常借阅任务，次要参与者完成图书管理系统的维护,一个用例可以被一个多个参与者使用 修改密码 一个参与者可以与多个用例交互 参与者在系统中扮演的主要角色： 系统启动者：系统的外部实体，为完成某项任务而启动系统如ATM机提款用户 系统服务者：系统的外部实体，响应系统的请求，为系统提供服务。
如银行内部系统为ATM机提供用户的存款信息 系统接受者：接收来自系统的信息如ATM机提款用户,4.2.1.1 参与者位于边界之外(I),场景：小王到银行去开户，向大厅经理询问了办理手续，填写了表单，交给柜台职员，拿到了银行存折 谁是actor，小王、大厅经理、柜台职员？ 通过回答下面两个问题来确定： 谁对系统有着明确的目标和要求并且主动发出动作？ 系统是为谁服务的？,4.2.1.1参与者位于边界之外(II),小王是参与者(actor)，大厅经理和柜台职员是什么？ 他们可以被称为业务工人(business worker),4.2.1.2 参与者可以非人,Saint Pig 如果我开发一个猪圈自动供食供水系统，猪的前蹄触发一个开关系统就供食或供水 这里的Actor 是小猪思考：识别参与者？,寻呼台系统：用户如果预定了天气预报，系统每天定时给他发天气消息；如果当天气温高于45度，还要提醒用户注意防暑；,在这个叙述里，谁是寻呼台系统的Actor？,用户,气温,时间都是Actor,4.2.2 发现参与者,在发现参与者的过程中，可以询问一下问题以帮助确定参与者： 谁负责提供、使用或删除信息？ 谁将使用此功能？（谁是系统的主要用户？） 谁对某个特定功能感兴趣？ 在组织中的什么地方使用系统？ 谁负责支持和维护系统？ 系统有哪些外部资源？ 其他还有哪些系统将需要与系统进行交互？,1、机票购买者通过登录网站购买机票，机票购买者就是actor,2、机票购买者通过呼叫中心，由人工座席操作订票系统购买机票;人工座席是actor,3、如果机票购买者通过呼叫中心的自动语音预订机票，那么呼叫中心就成了机票预订系统的一个actor,4、如果扩大边界，让呼叫中心成为机票预订系统的一个子系统，机票购买者通过人工座席、自动语音及网站预订机票，那么机票购买者是actor，人工座席成了业务工人,4.2.3 业务主角(business actor),业务主角是参与者的一个版型。
业务主角是与业务系统有着交互的人和事物，他们来确定业务范围 业务主角针对的是业务人员 建立业务模型、查找业务用例都必须使用业务主角 识别业务主角的问题： 业务主角的名称是否是客户的业务术语？ 业务主角的职责是否在客户的岗位手册里有对应的定义？ 业务主角的业务用例是否都是客户的业务术语？ 客户是否对业务主角能顺利理解？,4.2.4 业务工人(business worker),有些人员参与了业务，但是被动参与的应当被称为业务工人(business worker),识别业务工人的问题： 他是主动向系统发出动作的吗？ 他有完整的业务目标吗？ 系统是为他服务的吗？ 如果三个问题的答案是否定的，那一定是业务工人,4.2.5 参与者与涉众的关系,涉众(stakeholder)，也称为干系人涉众是与要建设的系统有利益相关的一切人和事，涉众的利益要求会影响到系统的建设 并不是所有的涉众都是系统的参与者 参与者是涉众代表,4.2.6 参与者与用户的关系,用户(user)是指系统的使用者 用户是参与者的代表、实例或代理4.2.7 参与者与角色的关系,角色(role)是参与者的职责 一个用户可以代理多个参与者，一个用户可以拥有多个职责，即可以被指定多个角色。
4.2.8 参与者的核心地位,参与者是涉众代表，他代表涉众对象对系统的利益要求，向系统提出建设要求；参与者通过代理给其他用户或将自身实例化成用户来实用系统；参与者的职责可以用角色来归纳 系统是以参与者的观点来决定的4.2.9 检查点,是否已找到所有的参与者？ 每个参与者是否至少涉及一个用例？ 能否列出至少两名可以作为特定参与者的人员？ 是否有参与者与系统相关的相似角色？ 是否有两个参与者与用例相关的同一角色？ 特定的参与者是否将以几种方式实用系统？ 参与者是否有直观名称和描述性名称？,4.3 用例(Use case),,,登记成绩,4.3.1 基本概念,用例是系统执行的连续操作，用户使用系统来完成某个过程时出现，是外部可见的系统功能单元 用例定义了一组用例实例，其中每个实例都是系统所执行的一系列操作，这些操作生成特定主角可以观测的值 一个用例是与参与者交互的，并且给参与者提供可观测的有意义的结果的一系列活动的集合 一个场景是用例的实例 用例的作用：捕捉功能方面的需求,4.3.1 基本概念,完整的用例定义由参与者、前置条件、场景、后置条件构成用电饭煲做或木桶做饭，两种不同的场景 前置条件，启动用例要有前提-米（巧妇难为无米之炊） 后置条件，用例执行完之后有结果-饭,4.3.2 用例的特征,用例的特征： 用例是相对独立的（完整达到参与者的目的） 用例的执行结果对参与者来说是可观测的和有意义的 用例必然以动宾短语形式出现的：统计报表 用例由一个参与者发起 一个用例就是一个需求单元、分析单元、设计单元、开发单元、测试单元，甚至部署单元。
作用：保证用例能够正确捕捉功能性的需求，也是判断用例是否准确的依据用例要点,可观测→用例止于系统边界 结果值→用例是有意义的目标 系统执行→结果值由系统生成 由参与者观测→业务语言、用户观点 一组用例实例→用例的粒度,要点：用例止于系统边界,,,,,,描述交互，而不是内在的系统活动,要点：有意义的目标,由参与者发起,,要点：业务语言而非技术语言,用户词汇，而不是技术词汇 如：发票，商品，洗衣机 而不是：记录，字段，COM，C++等,要点：用户观点而非系统观点,用户观点,系统观点,用例 VS. 功能,呼叫某人 接听 发送短信 记住号码 ……,传输/接收 电源/基站 输入输出（显示、键盘） 簿管理 ……,用户观点,系统观点,用例的命名,执行者视角： （状语）动词+（定语+ ）宾语,4.3.3 用例粒度,用例的粒度以每个用例能够说明一件完整的事情为宜用例的粒度大小不是从用例包含的步骤多少来判断的开发工作量一周左右时间 ATM机的取钱场景：取钱、读卡、验证账号、打印回执单等 用例的数量： 50人年的大型项目，选择更大的粒度，粒度过小可能会出现几百个用例，用例过多的问题，后果需求过于细碎，而无法控制 10人月的小项目，如果用例的粒度过大，可能只有几个用例，后果需求过于模糊 经验：用例数量控制在10-50之间，否则要考虑用例粒度选择是否适当的问题,用例粒度的选择（如何粒度大小）,项目的不同阶段选择不同的粒度大小（经验） 在业务建模阶段，用例的粒度以每个用例能够说明一件完整的事情为宜，即描述一项完整的业务流程。
如取钱，报装，借书不要细化到，验证密码，填写申请单、查找书目等业务中的一个步骤 用例分析阶段（概念建模）：用例的粒度能描述一个完整的事件流为宜，可以理解为一个用例描述一项完整业务中的一个步骤比如报装可以分解为申请资料、受理业务、现场安装等多个概念用例 系统建模阶段，用例视角是针对计算机的用例粒度以能够描述操作者与计算机的一次完整交互为宜如填写申请单、审核申请单、派发任务单等 用例分析以参与者为中心，以完成参与者的目的,要点：用例粒度-1,用例要有路径，路径要有步骤；而这一切都是可观测的 最常犯错误：粒度过细，陷入功能分解 过细的粒度，一般都会导致技术语言的描述，而不再是业务语言,用例粒度-2,把步骤当用例把系统活动当用例,用例粒度-3,“四轮马车” C(Create) R(Read) U(Update) D(Delete) 所有业务最终对会成为CRUD？ CRUD能为Actor提供价值？ CRUD掩盖业务，锐变成关系数据库的建模： “系统就是数据的增删改查” 关心数据的存储和维护，反而忽略了用户的目的,用例粒度-4,如果确实是CRUD？ 如果CRUD不涉及复杂的交互，一个用例“管理××”即可 不管是C、R、U、D，都是为了完成“管理”目标 甚至很多种的基本数据管理都可以用一个用例表示,用例粒度-5,灵活处理CRUD,可以把包含复杂交互的路径独立出去形成用例,4.3.4 用例的获得,首先确定actor 接下来，开始对actor即业务代表进行访谈 您对系统有什么期望？ 您打算在这个系统里做些什么事情？ 您做这件事的目的是什么？ 您做完这件事希望有一个什么样的结果？,问题－寻找用例,简单地用纸和笔记录下业务代表的访谈结果，从结果中找出用例。
不要指望客户和你一样对用例了如指掌 不要期望客户能有条理有层次把对系统的期望表达出来 要从客户的杂乱无章的谈话中找出参与者的真实和有效的目标 不同的参与者的对同一目标可能会有不同的表达 主角对系统的期望不一定是一个有效的目标 不同参与者的目标可能会相互重复4.3.4 用例的获得--ATM,客户代表说：我希望这台ATM能支持跨行业务，我插入卡片输入密码后，可以让我选择是取钱还是存钱；为了方便，可以设置一些默认的存取金额按钮；我可以修改密码，也可以挂失；还有我希望可以缴纳费、水费、电费等费用；为了安全起见，ATM上应该有警示小心骗子的提示条，还有摄像头；如果输入三次密码错误，卡片应当被自动吞没4.3.4 用例的获得--ATM,支持跨行业务 插入卡片 输入密码 选择服务 取钱 存钱 挂失卡片 交纳费用 警示骗子 三次错误吞没卡片,×这是一个业务规则 ×这是一个过程步骤 ×这是一个过程步骤 ×这是一个过程步骤 √这是一个有效的完整目标 √这是一个有效的完整目标 √这是一个有效的完整目标 √这是一个有效的完整目标 ×超出有效的边界范围 ×这是一个业务规则,。