武汉科技大学UML课程课件.ppt

第四章 UML核心元素 4.1 版型 4.2 参与者 4.3 用例 4.4 边界 4.5 业务实体 4.6 包 4.7 分析类 4.8 设计类 4.9 关系 4.10 组件 4.11 节点 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度，还要提醒用户注意防暑； 4.2.2 发现参与者 在发现参与者的过程中，可以询问一下问题以帮助确定参与者： 谁负责提供、使用或删除信息？ 谁将使用此功能？（谁是系统的主要用户？） 谁对某个特定功能感兴趣？ 在组织中的什么地方使用系统？ 谁负责支持和维护系统？ 系统有哪些外部资源？ 其他还有哪些系统将需要与系统进行交互？ 1、机票购买者通过登录网站购买机票，机票购买者就是actor 3、如果机票购买者通过呼叫中心的自动语音预订机票，那么呼叫中心就成了机票预订系统的一个actor 4.2.3 业务主角(business actor) 业务主角是参与者的一个版型。业务主角是与业务系统有着交互的人和事物，他们来确定业务范围。 业务主角针对的是业务人员。 建立业务模型、查找业务用例都必须使用业务主角。 识别业务主角的问题： 业务主角的名称是否是客户的业务术语？ 业务主角的职责是否在客户的岗位手册里有对应的定义？ 业务主角的业务用例是否都是客户的业务术语？ 客户是否对业务主角能顺利理解？ 4.2.4 业务工人(business worker) 有些人员参与了业务，但是被动参与的。应当被称为业务工人(business worker) 4.2.5 参与者与涉众的关系 涉众(stakeholder)，也称为干系人。涉众是与要建设的系统有利益相关的一切人和事，涉众的利益要求会影响到系统的建设。 并不是所有的涉众都是系统的参与者 参与者是涉众代表 4.2.6 参与者与用户的关系 用户(user)是指系统的使用者。 用户是