1、面向对象分析设计 Object-Oriented Analysis & Design,谭火彬,第04章 用例建模,Use Case Modeling,-3-,学习路线图,-4-,内容安排,理解需求 需求获取 用例建模流程 获取原始需求 构建初始用例模型 定义用例规约 重构用例模型,-5-,内容安排,理解需求 需求获取 用例建模流程 获取原始需求 构建初始用例模型 编写用例规约 重构用例模型,-6-,需求建造“正确”的系统,需求:系统必须满足的条件或具备的能力 Robert Grady软件质量准则“FURPS+” 功能性(Functionality) 使用性(Usability) 可靠性(Rel
2、iability) 性能(Performance) 可支持性(Supportability),非功能性需求,-7-,需求难在何处:石头问题,我要一块石头 差不多,但我要小一点的 很好,不过我要蓝色的 啊,没有那么小 咳,还是原来那个好了,小一点的蓝色大理石,难捕获,易变!,-8-,需求:也需要开发,客户/用户的要求/想法/期望,软件设计,软件产品,开发,编码和测试,验收,有价值的 软件需求,分析和设计,-9-,需求问题:对策,难捕获,易变,从用户视角看问题,合理的结构,用例,-10-,以用例为中心组织需求,用例,可用性,可靠性,网络协议,业务规则,硬件接口,界面约束,性能,-11-,用例的昨天
3、,Use Cases Yesterday, Today and Tomorrow(Ivar Jacobson, The Rational Edge, 2003.3) 萌芽期(1967-1986) Ivar Jacobson在爱立信,把各种不同类型的电话呼叫情况称为traffic case,而完成所有呼叫则需要交换机具备相应的功能function或特征feature 1986年,提出术语use case 1987年,OOPSLA86采用Jacobson论文,用例诞生 成熟期(1987-1992) Objectory AB公司,以用例内容为核心的Objectory Process(对象工厂过程)
4、发展期(1992-),-12-,内容安排,理解需求 需求获取 用例建模流程 获取原始需求 构建初始用例模型 编写用例规约 重构用例模型,-13-,需求获取,有业务模型 从业务用例模型中寻找系统改进点 结合系统远景,获取系统用例来表达需求 采用需求启发技术,从涉众获得,-14-,从业务模型获取需求,从业务用例模型中发掘系统需求,来构建系统用例模型 1. 寻找业务改进点 2. 定义项目远景 3. 导出系统需求,-15-,1. 业务改进点,业务模型描述业务现状,这些现状: 有些可能一直运转的很好,不需要改进,也就没有必要作为软件需求来由系统实现 而另外可能更多的业务在运转过程中存在这样或那样的问题,
5、这些问题就成为业务待改进的改进点,也就很可能作为软件需求而存在,-16-,寻找业务改进点,从业务流程中获取改进点 信息的自动流转 演绎复杂业务逻辑 访问和操作业务对象 自动工作 ,-17-,改进点1:信息自动流转,-18-,改进点2:演绎复杂业务逻辑,-19-,改进点3:访问和操作业务对象,-20-,改进点4:自动工作,-21-,2. 远景(Vision),系统改进点不等同于软件需求 用户根据自身的工作特点和支付能力决定哪些应该改进,哪些不需要改进 这就是用户的远景,它表明用户改进的目标,这也将成为项目的目标 业务模型描述了“现实是什么”,远景则描述“希望的改进” 远景表达了“为什么要开发这个
6、系统” 在目前的现实(业务模型)下,开发系统是为了达到什么目标?,-22-,定义项目远景,远景包含了对待开发系统的目标和约束 代表了项目涉及的所有人之间达成的第一个共识 是项目核心需求的概览 为更详细的技术需求提供了契约性的依据 指导团队实现具体的业务目标 远景的作用 最初,根据项目的远景目标来决定项目是否值得继续 在项目批准后,团队根据项目远景来指导后续的需求和设计,-23-,远景说明,远景可以作为一个单独的文档存在,而这其中最重要的部分就是关于远景目标的说明,它建立了一个项目涉及的所有人的共同目标 远景说明应该是精确、清晰和激励性的描述,以便激励所有的团队成员为达成该远景而努力。一个好的远
7、景应该具有以下五个特点(SMART): 具体的(Specific) 可测量的(Measurable) 可实现的(Achievable) 相关的(Relevant) 基于时间的(Time-based),-24-,3. 导出系统需求,从业务改进点入手,结合项目远景,导出系统需求: 对于每一个业务改进点,明确是否是为了达到远景目标的需要 如果是则作为软件需求而存在,并把相应地模型作为系统模型 如果不是则不作为需求而存在,可能作为一项潜在的需求考虑,也可能直接抛弃,-25-,实例分析:旅店系统开发背景,随着旅店声誉日益提高,住宿人员越来越多,旅客为了能够获得好的房间,均提前预订房间 然而,随着预订的增
8、多、预订周期的拉长,前台服务员工作压力也日益增大,还经常出现工作的失误,使得已经预订好房间的旅客也不能按期入住,这给酒店的声誉带来不好的影响 为此,旅店老板想到了计算机,希望能够通过计算机来自动管理这些预订业务,不过由于目前资金的问题,目前只开发一个单机版的系统,不提供网上业务;并且旅店方面的其它业务暂不考虑信息化问题 旅店老板委托某计算机公司开发该系统,并承诺如果系统运转良好的话,将会考虑进一步合作事宜,-26-,远景:旅店预订系统,A很荣幸地成为项目经理,并被要求在两个月之内发布该系统的第一个版本,同时还被要求要为后续的开发提供必备的接口 结合现状和老板的要求,考虑到的项目可扩展的要求,A
9、首先进行了简单的业务建模 之后,A初步定义了项目的远景 方便、快捷、准确地为旅客预订房间 旅客可以方便的取消预订的房间 旅店经理能够定期的获取预订的信息,根据这些信息可以及时调整房间的价格 及时、快速地计算房间费用、预订费用、取消预订后退款金额等信息 ?预留接口:可以为以后的网络版,以及其它业务系统的开发提供支持,-27-,结合远景,获取系统需求,-28-,业务模型映射到系统模型思路,从业务改进点入手,结合系统远景,可以帮助获取系统模型 可能的对应关系(并非一一对应) 业务用例 系统(子系统) 业务参与者 系统参与者 业务工人 系统参与者 业务工人的操作(活动) 系统用例 业务实体 实体类,-
10、29-,内容安排,理解需求 需求获取 用例建模流程 获取原始需求 构建初始用例模型 定义用例规约 重构用例模型,-30-,用例建模流程,1. 获取原始需求 2. 开发一个可以理解的需求 2.1 识别参与者 2.2 识别用例 2.3 构建用例模型 3 详细、完整地描述需求 定义用例规约 4 重构用例模型 4.1 识别用例间的关系 4.2 对用例进行组织和分包,-31-,用例建模流程,1. 获取原始需求 2. 开发一个可以理解的需求 2.1 识别参与者 2.2 识别用例 2.3 构建用例模型 3 详细、完整地描述需求 定义用例规约 4 重构用例模型 4.1 识别用例间的关系 4.2 对用例进行组织
11、和分包,-32-,1.需求从何而来,需求只能来自涉众(stakeholders) 最终用户、客户 政府、法律、文化 开发人员、管理人员 竞争对手 但并不是直接从涉众中来 你们的需求是什么?,-33-,涉众无法直接提供需求,涉众无法陈述自己的需要 涉众说的是解决方案而不是需求 涉众难以构想新的工作方法 涉众的利益矛盾 涉众抵制变更 “最好也要有”过度的要求 需求引发需求,-34-,需求启发技术,需求工程师利用需求启发技术,从涉众中发掘需求 实地观察 访谈 开会 问卷调查 原型制作 研究文档 研究竞争对手 ,-35-,启发技术比较,-36-,用例建模流程,1. 获取原始需求 2. 开发一个可以理解
12、的需求 2.1 识别参与者 2.2 识别用例 2.3 构建用例模型 3 详细、完整地描述需求 定义用例规约 4 重构用例模型 4.1 识别用例间的关系 4.2 对用例进行组织和分包,-37-,2.1 识别参与者(Actor),识别参与者 关键词:边界 参与者:在系统之外,透过系统边界与系统进行有意义交互的任何事物,-38-,参与者要点,系统外 参与者代表在系统边界之外的真实事物,并不是系统的成分 系统边界 参与者透过系统边界直接与系统交互,参与者的确定代表系统边界的确定 有意义的交互 系统需要关注其交互过程,即系统职责 任何事物 人、外系统、外部因素、时间,-39-,要点:有意义的交互,-40
13、-,要点:任何事物,-41-,任何事物:小人与圣小猪-1,-42-,小人与圣小猪-2,众所周知,use case 图里的actor 用一个小人表示。但是这个小人极具误导性,往往让初学者(包括客户)理解为一个真实的人。大多数UML 学习者都要花好长一段时间来搞明白小人其实不一定代表的是人,而是很抽象的系统不可控的外部因素,比如说另一个系统。那么为什么不干脆用其它的符号来表示Actor 呢? 如果我开发一个猪圈自动供食供水系统,猪的前蹄触发一个开关系统就供食或供水。显然,这里的Actor 是小猪。那么在use case 图里用小猪代替原来的小人不是更易于交流吗?,-43-,思考:参与者与系统边界?
14、,某企业要求开发一个企业信息管理系统,并与原来已有的库存系统相连接 某企业要求开发一个企业信息管理系统,并把原来已有的库存管理系统加以改造,成为企业信息管理系统的一部分,-44-,思考:识别参与者?,寻呼台系统:用户如果预定了天气预报,系统每天定时给他发天气消息;如果当天气温高于35度,还要提醒用户注意防暑;,在这个叙述里,谁是寻呼台系统的Actor?用户?气温?时间?,-45-,识别参与者思路,谁使用系统的主要功能 谁改变系统的数据 谁从系统获取信息 谁需要系统的支持以完成日常工作任务 谁负责日常维护、管理并保证系统正常运行 系统需要应付(处理)那些硬设备 系统需要和那些外部系统交互 谁(或
15、什么)对系统运行产生的结果(值)感兴趣 时间、气温等内部外部条件 ,-46-,参与者地位,识别用例之前重要 有助于识别用例,宁多勿少 开始书写用例文档以后不重要 涉及的参与者太多 测试和部署阶段重要 需要从参与者的角度考虑,-47-,参与者的泛化:责任重叠,参与者可以通过泛化关系来定义,在这种泛化关系中,一个参与者的抽象描述可以被一个或多个具体的参与者所共享 如系统中经理可以参加雇员的所有用例,-48-,泛化关系的误用,-49-,2.2 识别用例,关键词:价值 定义 用例实例是系统执行的一系列动作,这些动作将生成特定参与者可观测的结果值 一个用例定义一组用例实例(场景) 简洁:参与者使用系统达
16、到某个目标,-50-,用例要点,可观测用例止于系统边界 结果值用例是有意义的目标 系统执行结果值由系统生成 由参与者观测业务语言、用户观点 一组用例实例用例的粒度,-51-,要点:用例止于系统边界,描述交互,而不是内在的系统活动,-52-,要点:有意义的目标,-53-,要点:结果值由系统生成,系统需要处理的,由系统生成,-54-,要点:业务语言而非技术语言,用户词汇,而不是技术词汇 如:发票,商品,洗衣机 而不是:记录,字段,COM,C+等,-55-,用户观点,系统观点,-56-,用例 VS. 功能,呼叫某人 接听电话 发送短信 记住电话号码 ,传输/接收 电源/基站 输入输出(显示、键盘)
17、电话簿管理 ,用户观点,系统观点,-57-,用例的命名,参与者视角: (状语)动词+(定语+ )宾语,-58-,要点:用例粒度-1,用例要有路径,路径要有步骤;而这一切都是可观测的 最常犯错误:粒度过细,陷入功能分解 过细的粒度,一般都会导致技术语言的描述,而不再是业务语言,-59-,用例粒度-2,把步骤当用例把系统活动当用例,-60-,用例粒度-3,“四轮马车” C(Create) R(Read) U(Update) D(Delete) 所有业务最终对会成为CRUD? CRUD能为Actor提供价值? CRUD掩盖业务,锐变成关系数据库的建模: “系统就是数据的增删改查” 关心数据的存储和维
18、护,反而忽略了用户的目的,-61-,用例粒度-4,如果确实是CRUD? 如果CRUD不涉及复杂的交互,一个用例“管理”即可 不管是C、R、U、D,都是为了完成“管理”目标 甚至很多种的基本数据管理都可以用一个用例表示,-62-,用例粒度-5,灵活处理CRUD,可以把包含复杂交互的路径独立出去形成用例,-63-,思考:识别用例-1,Email客户端(如:outlook express),A在北京发邮件给上海的B,系统提醒B你有“新邮件”,B收邮件,用例是一个完整的交互 用例之间没有顺序的关系,-64-,思考:识别用例-2,-65-,实例分析:学生选课系统,-66-,实例分析:旅店预订系统,-67
19、-,用例建模流程,1. 获取原始需求 2. 开发一个可以理解的需求 2.1 识别参与者 2.2 识别用例 2.3 构建用例模型 3 详细、完整地描述需求 用例规约 4 重构用例模型 4.1 识别用例间的关系 4.2 对用例进行组织和分包,-68-,书写用例文档:用例规约,用例规约:更进一步的精度 用例文档的核心,而用例图作为用例文档的总图 进一步的精度:有层次的文档 文档中每一句话都有其价值,用例图是骨架,而用例规约则是其内在的肉,-69-,有层次的需求组织形式,用例(取款) 路径(正常取款) 步骤(系统验证取款金额合法) 补充约束(取款金额必须为50元的倍数),低精度,稳定,高精度,不稳定,
20、-70-,谁来写用例文档,最完美:业务人员接受训练,写出优美的用例文档 最现实:业务人员提供素材,开发人员写用例文档 最糟糕:业务人员不管,完全由开发人员杜撰,-71-,用例规约的组成,用例标识(UC)、名称 描述 涉及的参与者、涉及的用例 涉众利益 前置条件、后置条件 事件流 基本路径 备选路径、异常路径 补充约束 字段列表、业务规则 非功能需求、设计约束 待解决问题 相关图(用例图、活动图、类图),-72-,涉众利益,同样是“取线” 为什么家里的抽屉不用密码,取款机要用? 为什么取了钱以后要“系统扣除帐户金额” 还有一些因素没有考虑,-73-,从涉众利益角度定义用例,Cockburn:用例
21、是涉众之间达成的契约,以参与者为达成特定目标和系统交互的方式演绎,-74-,用例平衡涉众之间的利益,用例平衡涉众之间的利益 涉众是受系统影响的,有自己主张的人或组织,可能的涉众有: 最终用户、客户、政府、法律 开发人员、管理人员、竞争对手、 对于用户在ATM取钱的用例 用户:希望方便 银行:希望安全 法律:保护财产,-75-,涉众利益的冲突,用例相当于参与者在台上表演,而最重要的是台下的观众(涉众)的利益 编写用例规约的过程就是描述如何满足涉众之间的利益,达到涉众利益的平衡 涉众有轻重缓急,-76-,寻找涉众的思路,区分涉众与参与者 可能的涉众有: 当事人 上游下游 操作对象的主人 ,-77-
22、,前置、后置条件,前置条件约束在用例开始前系统的状态 把它们看做是看门人,它阻止参与者触发该用例直到满足所有条件 说明在用例触发之前什么必须为真 后置条件约束用例执行后系统的状态 用例执行后什么必须为真 对于有多个事件流的用例,则应该有多个后置条件,-78-,定义前置、后置条件,前置、后置条件必须是系统能检测到的 前置条件必须是系统在用例开始前就能检测到的,-79-,应用前置、后置条件,某些用例依赖于其他用例 一个用例在离开系统时,可能是另一个用例的前置条件(例如:“登录”和“管理系统”) 有助于识别漏掉的用例 如果一个用例的前置条件不能有执行其他用例满足,可能意味着丢失了用例(例如:“管理订
23、单”却没有“登录”用例),-80-,用例交互四部曲-事件流,1. 动 作,4. 回 应,2.改变,3.验证,系 统,写:可观测的、体现客户利益的文字,-81-,事件流描述要点,1.只书写“可观测”的(说人话) 2.使用主动语句 3.句子必须以参与者或系统作为主语 4.不要涉及界面细节 5.分支和循环,-82-,要点1-只写“可观测”的,系统通过ADO建立数据库连接,传送SQL查询语句,从“商品表”查询商品的详细信息 系统按照查询条件搜索商品的详细信息,-83-,要点2-主动语句,欧文从贝克汉姆处得到传球,守门员 贝克汉姆传球给欧文,欧文射门,守门员扑救,-84-,要点3-以参与者或系统作主语,
24、参与者 系统 出纳员接收顾客的付款顾客的付款数可能高于商品总额 出纳员录入顾客所付的现金总额 系统显示出应找还给顾客的余额,打印付款收据,-85-,要点4-不涉及界面细节,会员从下拉框中选择类别 会员在相应文本框中输入查询条件 会员点击“确定”按钮,-86-,要点5-分支和循环,分支:放到扩展路径 参与者的选择 另一条成功线路 系统进行验证 循环:直接描述,-87-,用例文档中的补充约束,用例重点在于描述功能需求,而其它方面的补充约束: 可以在用例文档中分别描述 也可以在“补充需求规约”中单独描述,并于相关的用例文档建立关联 补充约束 字段列表 业务规则 非功能需求 设计约束,-88-,补充约
25、束:字段列表,描述与用例相关的数据需求 不同于数据模型只是一部分,但可以用E/R图或业务对象图作为辅助说明 不等于数据字典容易过早把时间花在细节上,早期只关注数据本身,不关注实现细节 示例(可按数据字典语法,也可简单描述) 注册信息=用户名+密码+email+电话* 房间的状态可能有:空闲、已预订、占用 ,-89-,补充约束:业务规则,描述业务逻辑和操作规则 事实:设备是资产的一种 推理:如果过了计划中的交互日期,货物还没有送到,即为“未按时送货” 约束:合同总金额不能超出买方的信用额度 表达业务规则 文字说明 决策表 OCL(对象约束语言) ,-90-,补充约束:非功能需求,一开始,功能需求
26、决胜;类似产品多了,非功能需求决胜 四类非功能需求 可用性 可靠性 性能 可支持性,-91-,补充约束:设计约束,本质上不是需求,只是从商业、行政、技术上的约束 用Oracle数据库平台,用PB开发 软件必须符合ISO标准 ,-92-,实例分析:编写用例文档,用例规约文档参考模板 旅店预订系统用例文档 “UC01-预订房间”用例规约 “UC02-取消预订”用例规约 学生选课系统用例文档 “UC01-学生选课”用例规约,-93-,用例建模流程,1. 获取原始需求 2. 开发一个可以理解的需求 2.1 识别参与者 2.2 识别用例 2.3 构建用例模型 3 详细、完整地描述需求 定义用例规约 4
27、重构用例模型 4.1 识别用例间的关系 4.2 对用例进行组织和分包,-94-,4.1 用例关系,Extend,Include,Generalization,-95-,通过关系整理文档,Extend 分离扩展路径 Include 提取公共步骤,便于复用 Generalization 同一业务目的的不同技术实现,-96-,扩展关系,基用例路径本身是完整的,可能是一条扩展路径 扩展路径步骤多 扩展路径内部还有扩展点扩展之扩展 扩展路径未定或容易变化分离以“冻结”基用例,-97-,扩展关系误用,-98-,识别扩展点思路,参与者的选择 系统验证 步骤失败 ,必须是系统能感知的,-99-,包含关系,某些
28、步骤在多个用例重复出现,且单独形成价值 用例步骤较多时,可用Include简化(慎用),-100-,包含关系误用,-101-,扩展 VS. 包含,老大知道老二,老二知道老大,什么时候该我上场呢?不知道!,出现这种情况,就该我上场了!,-102-,泛化关系,同一业务目的不同技术实现: 一个用例可以特化另一个更普通用例(更普通用例泛化特殊用例) UML 1.5: 用例间的泛化关系表明子用例继承父用例中定义的所有属性、行为序列和扩展点,并且参与父用例中所有的关系,-103-,泛化的危害,一个售货员可以终止任何交易,除了那些需要特殊的售货员(高级代理)终止的超过了一定限制的交易,-104-,用例关系:
29、扩展 VS. 泛化,采用不同关系,文档结构不同,-105-,旅店预订系统重构后的用例模型,-106-,4.2为什么要对用例进行分类,用例和开发周期 开发周期是围绕用例的需求来组织的 一个开发周期要被指派一个到多个用例,如果完全版本的用例在一个开发周期中处理起来太复杂的话,那就采用简化版本的用例,开发周期,开发周期,开发周期,用例A -简化版本,用例A -完整版本,用例B,用例C,-107-,用例分类原则,用例分类的一个基本原则 高级别的用例是那些对系统核心体系结构影响最大的用例 提高用例级别的特性: a. 对体系结构设计有重要影响的用例,如在领域层中增加多个类的用例或者需要持久化的用例 b.
30、不需要花费很多努力就可以从中获得重要信息和线索的那些用例 c. 含有开发风险、时间紧迫或功能复杂的用例 d. 涉及到重要技术研究或者新技术和高风险的用例 e. 代表主要的在线业务流程的用例 f. 能产生直接经济效益或者降低成本的用例,-108-,用例分类实施策略-1,可以使用一个简单的但是有些不精确的分类方法,如将用例划分成高、中、低三个等级,-109-,用例分类实施策略-2,依照上述的影响用例级别的特性给用例打分(用例也可能带有权值,-110-,用例的组织,对用例进行分包 让用例图能够更为清晰地表现出系统的业务逻辑关系和层次 对系统进行模块的分割,这将影响到今后的开发和系统的最终表现形式 常
31、见的分包方式 按参与者分包 按主题分包 按开发团队分包 按发布情况分包,先按主题分包,主题内再按开发团队和发布情况分包,-111-,分包:组织模型,用例分包的目的 让系统的用例图能够更为清晰的表现出系统的业务逻辑关系和层次 对系统进行模块的分割,这种分割将影响到系统今后的开发、系统的最终表现形式,-112-,利用分包机制组织用例模型,-113-,“申请”包的子视图,-114-,另外一种模型的组织方式,通过用例的抽象级别来组织模型,通过定义不同层次的用例来细化用例 抽象用例 系统用例 具体用例,-115-,题外话:何时适用用例建模,用例是从参与者角度捕获系统功能,当系统只有一个或者没有参与者时,
32、显然不是非常有效的 用例捕获功能需求,因此对于系统的非功能需求不是有效 当遇到下述情况时,用例是需求捕获的最好选择 系统由功能需求所主导 系统具有很多类型的用户,系统对他们提供不同的功能 系统具有很多接口 当遇到下述情况时,用例是一个糟糕的选择: 系统由非功能需求所主导(如:google) 系统具有很少的用户 系统具有很少的接口(非内部功能) 如:嵌入式系统、算法复杂但接口少的系统等,-116-,用例和OO,“发明”于OO的环境(Ivar Jacobson) 从外部Actor的角度描述系统功能(和对象的消息类似) 不暴露内部结构 OO设计的最好开始,是OO技术进入第二代的标志,-117-,下一
33、步?,需求,用例,面向对象 分析设计,结构化 分析设计,其它方法,自己的 土方法,系统,-118-,作业1:用例建模,总分:20分 参阅给定的考勤系统问题陈述(网站的文档中心下载),完成下面所要求的内容 完成“考勤系统”的系统用例图,注意用例的命名和用例间的关系的使用,并简单描述每个执行者和用例的含义(10分) 选择一个体现系统核心业务的系统用例,完成用例规约,如果该用例有“扩展”、“包含”或“泛化”的子用例,则至少还需要写出一个子用例的规约(10分),-119-,提交要求,以一个Word文件的形式提交(用例图贴到文档的适当位置) 文件以您的学号姓名的方式命名,如“GS0721100谭火彬.d
34、oc” 11月17日(下周六)之前提交,逾期会相应地扣分,希望大家合作 提交方式 Email方式:,邮件主题设为“uml第一次作业”,并设置“请求阅读收条” Web方式:文档中心面向对象设计作业01.用例建模,谢谢,附录4-1. 用例建模检查点,(评估用例模型的标准),-122-,用例模型检查点,用例模型的简介部分简明清晰地概述此系统目的和功能 用例模型清楚地说明此系统的行为;通过复审该模型即可很容易地理解系统执行的活动 所有的用例已确定;这些用例共同说明所有的必要行为 所有的功能性需求都至少映射到一个用例 特定用例必须满足所有非功能性需求已映射到这些用例 该用例模型不包含多余的行为;所有的用
35、例都可回溯到某个功能性需求来证明其合理性 用例之间的所有关系都是必需的(即,所有的包含关系、扩展关系和泛化关系都存在合理依据) 如果模型较大和/或模型各部分的职责比较分散,就需要适当地使用用例包 交叉包依赖关系已被减少或去除,防止发生模型元素所有权冲突 包装需要直观并且便于理解模型,-123-,参与者检查点,是否您已找到所有的参与者 每个参与者是否至少涉及到一个用例 能否列出至少两名可以作为特定参与者的人员 是否有参与者担任与系统相关的相似角色?如果有,将他们合并到一个参与者中 是否有两个参与者担任与用例相关的同一角色?如果有,利用参与者泛化关系来为他们的共享行为建立模型 特定的参与者是否将以
36、几种(完全不同的)方式使用系统?如果是这样,也许应该有多个参与者 参与者是否有直观名称和描述性名称?用户和客户是否都能理解这些名称?参与者的名称务必要与其角色相符。否则,应对其进行更改,-124-,用例检查点,每个具体用例是否至少涉及一个参与者 用例之间是否相互独立 用例是否有非常相似的行为或事件流 事件流的一部分是否已被构建为另一个用例的模型 事件流的某一部分是否已经成为另一个用例的组成部分 是否应该将一个用例的事件流插入另一个用例的事件流中 用例的名称是否具有唯一性、直观性和解释性 客户和用户是否都了解用例的名称和说明 用例是否满足明显支配其性能的所有需求 参与者和用例之间的关联关系是否符合用户的期望,-125-,用例检查点,是否明确说明用例的事件流开始及结束的方式和时间 可能存在仅在未符合某一特定条件时才被激活的行为 是否有过于复杂的用例 用例是否包含完全不同的事件流 是否精确建立业务用例中的分支流的模型 是否清楚地说明执行用例的对象 是否还清楚地说明用例的目的 是否清楚地说明主角的交互和交换的信息 简要概述是否清晰地描述了用例的概况,