1、面向对象分析与设计 Object-Oriented Analysis & Design,-2-,学习路线图,核心过程,-3-,业务建模,Business Modeling,-5-,开发过程解析,业务建模：用软件建模方法描述业务流程；其目标是认识业务本质，该业务本质是后续用例建模的基础 用例建模：采用UML用例建模技术描述软件需求，该需求模型将为后续用例分析提供输入 用例分析：采用UML用例分析技术分析软件需求，建立软件系统的分析模型 架构设计：在系统的全局范围内，以分析模型为基础，设计系统的架构 构件设计：根据架构设计的成果，将分析模型细化，设计系统构件的实现细节 代码实现：将系统构件映射到目
2、标语言上,-6-,业务,业务是指某个组织或者组织单元 业务可以看作一种包含了人、机器、资源的“系统” 利用软件思想(用例思想、对象思想)描述业务的过程，就是业务建模 业务建模只是辅助环节 不是所有项目都需要 也不一定和软件开发相关,-7-,业务建模,业务建模的目的 理解将要实施的系统的组织结构和动态特性 理解当前在目标组织中的问题，并明确改进的潜力 确保客户、最终用户和开发人员对目标组织有统一的理解 获取用于支持目标组织的系统需求 业务建模关注 机构的核心价值 机构的边界 机构的参与者 机构中的工作流及如何优化,-8-,业务建模方法,研究对象 软件要改进的业务单元 研究目标 定义业务本质 研究
3、方法 用例观点：把业务看成对外提供价值的价值流,-9-,业务建模工件,业务用例模型(Business Use-Case Model) 业务用户表示为业务参与者(Business Actor) 业务过程表示为业务用例(Business Use-Case)和业务用例实现 业务对象模型(Business Object Model) 人们在组织中扮演的角色表示为业务工人(Business Worker) 组织管理或制造的“东西”表示为业务实体(Business Entity),-10-,业务建模流程,0. 建立业务用例模型 1. 识别业务参与者 2. 识别业务用例 3. 详述业务用例 4. 建立业务对
4、象模型,-11-,业务建模流程,0. 建立业务用例模型 1. 识别业务参与者 2. 识别业务用例 3. 详述业务用例 1. 建立业务对象模型,-12-,1.业务参与者(Business Actor),识别业务参与者 在业务之外，与业务进行交互的人或组织,-13-,区分业务工人(Business Worker),业务参与者在业务外面 业务工人在业务里面,-14-,区分业务实体(Business Entity),-15-,识别业务参与者思路,客户 供应商 合作伙伴 潜在客户 政府 组织中未建模部分 ,-16-,2.业务用例(Business Use Case),识别业务用例 业务为业务参与者提供的
5、价值 体现企业业务本质，是有意义的目标,-17-,业务用例与业务参与者,-18-,识别业务用例的方法,直接获得：从业务参与者的角度，从外部推导出来 拼装：从里面往外面看，内部业务流程的目标是什么,直接获得,拼装,-19-,从业务流程拼装业务用例,业务流程 1. 收款人在支票背后签名，写上身份证件号码，把支票和身份证件交给营业员 2. 营业员核对印章正确且证件有效 3. 营业员操作营业受理系统，办理支票兑现手续 4. 营业员把现金和证件交给交款人,-20-,识别业务用例-支持性事件,不要遗漏支撑性业务流程背后的业务用例 支持性事件 人员的发展与维护 业务内部IT的开发与维护 办公室的设立与维护
6、安全性 法律活动 例：公司为什么要举行足球比赛？,-21-,3.详述业务用例,业务用例是对业务流程的封装，在业务建模过程中需要逐一描述其内部细节，即详述业务用例 目的 详细说明业务用例的工作流程 说明业务用例的工作流程，以便于客户、用户和涉众理解,-22-,三种可选技术,文字,活动图,顺序图,-23-,选择合适的技术,只有文字 不生动，不便于和客户交流 只有活动图 难以表达所有细节 业务用例文档中插入活动图 活动图中插入文字(+注释+基本路径) 顺序图(需要涉及到业务对象模型),-24-,细说活动图,-25-,细说活动图(1),起点、终点 活动的一种特殊形式，各自只有一个 起点：只有离开的转移
7、 终点：只有进入的转移 存在从起点出发，到达终点的路径 活动和动作 有进有出 动宾结构 可以简单，可以复杂 分区 定义活动的负责者,-26-,细说活动图(2),控制流 向外转移的条件之和必须是完备集 向外转移的条件之间不能重叠 决策点 注意和流程图的区别 误把活动当决策 图中判断“技术可 行性”需要单独的 活动来完成,-27-,细说活动图(3),并发(concurrent) 同步条(synchronization bar)的分叉(fork)与合并(join) 有分必有合 有分必有进 有合必有出 并发同时,-28-,活动图中的对象流,指定活动操作的数据(对象)以及数据的流向(对象流) 业务对象(
8、business objects)、对象流(object flows) 指出对某些业务实体的操作，类似结构化中的数据流图 UML2中对象流 由原来的虚线 改为实线,-29-,活动图的分层,活动可以简单可以复杂，复杂的活动可以进一步细化：分层 顶层有起点终点，下层可以没有 出入平衡,-30-,4.业务对象模型,业务对象模型(Business Object Model) 勾勒出实现业务关系中的人、事物、设备、资源以及它们之间的关系；即业务工人和业务实体之间的静态关系 从另一个视角描述现实 使用UML类图描述 不要和待开发系统中的分析设计类相混淆,-31-,餐馆的业务对象模型,-32-,业务建模实践
9、：建模指南,业务模型不是UML标准直接支持的，但是通过UML的扩展机制可以很方便的建立业务模型 主要构造型(stereotype) 业务用例模型 参与者的构造型：业务参与者(Business Actor) 用例的构造型：业务用例(Business Use Case) 业务对象模型 类的构造型：业务工人(Business Worker)、业务实体(Business Entity),-33-,建模指南：模型的组织,利用“包”组织模型 用例视图中 “业务用例模型” 每个业务用例的 ”状态/活动模型” 逻辑视图中 “业务对象模型”,-34-,建模指南：使用构造型,业务用例模型是在UML的用例模型(用例
10、图)基础上添加构造型来实现的 业务对象模型是在UML的对象模型(类图)基础上添加构造型来实现的 利用已有元素添加构造型 Rose直接支持这些构造型,-35-,业务建模实践：实例分析,研究对象：某旅店 业务现状： 某旅店可对外开放50个双人间和20个单人间，房间费用视情况按季节调整，但周一到周五提供半价（周末全价）折扣 旅客可以直接入住房间(如果有空房)，也可提前预订；入住和预订都需要登记个人信息 旅客提前预订房间时，需提交一定的订金；入住时间24小时之外的旅客可以取消预订，并退回所有订金，24小时以内则不退还订金 退房时缴纳全部的住宿费用 服务员每月为经理提供房间的预订情况和入住情况的详细信息
11、,-36-,实例分析：业务用例模型,旅店的本质就是为旅客提供住宿服务，其它的只是为达到这个目标而采用的手段 (用例观点：把业务看成对外提供价值的价值流),-37-,实例分析：旅客住宿业务流程,-38-,实例分析：检查业务用例模型,该业务用例模型体现了整个旅店的业务需求吗？ 如何考虑这项业务：服务员每月为经理提供房间的预订情况和入住情况的详细信息？ 经理是什么，如何体现在业务建模过程中？ 是业务参与者还是业务工人？体现怎样的业务本质的差异？,-39-,实例分析：业务对象模型,-40-,从业务模型到系统模型,对于软件开发而言，业务建模只是辅助环节，并不是最终目标 软件工程师最终目标是要构造软件系统
12、 业务建模则是一种定义系统模型的辅助手段 从业务模型到系统模型 业务模型描述了目前的业务现状 系统模型才是软件开发的最终工件,-41-,业务模型为系统模型提供素材,为用例视图和逻辑视图提供输入 对于每个将被系统实现的业务用例，在用例视图中确定一个系统用例或用例包（或单独的子系统）来实现该业务 为需要支持自动化业务确定相应的用例 对于业务对象模型中的业务实体，可以在系统模型中定义对应的实体类 为系统构架提供一些重要的构架机制 在软件构架中定义专用层来实现复杂的业务逻辑,-42-,业务模型映射到系统模型,从业务改进点入手，结合系统远景，可以帮助获取系统模型 可能的对应关系(并非一一对应) 业务用例
13、 系统(子系统) 业务参与者 系统参与者 业务工人 系统参与者 业务工人的操作(活动) 系统用例 业务实体 实体类,用例建模,Use Case Modeling,-44-,内容安排,理解需求 从业务模型获取需求 建立用例模型 编写用例文档 重构用例模型 其它问题,-45-,内容安排,理解需求 从业务模型获取需求 建立用例模型 编写用例文档 重构用例模型 其它问题,-46-,需求建造“正确”的系统,需求：客户可接受的、系统必须满足的条件或具备的能力 RUP中的FURPS+软件质量准则 功能性（Functionality） 使用性（Usability） 可靠性（Reliability） 性能（Pe
14、rformance） 可支持性（Supportability） +,非功能性需求,需求工程的主要活动,定义需求 理解用户的需要，建立用户可理解的系统需求模型分析需求 根据需求模型，建立开发者无二义性解释的分析模型 需求管理,-47-,-48-,需求难在何处：石头问题,我要一块石头 差不多，但我要小一点的 很好，不过我要蓝色的 啊，没有那么小 咳，还是原来那个好了,小一点的蓝色大理石,难捕获，易变！,-49-,需求：也需要开发,客户/用户的要求/想法/期望,软件设计,软件产品,开发,编码和测试,验收,有价值的 软件需求,分析和设计,-50-,需求问题：对策,难捕获,易变,从用户视角看问题,合理的
15、结构,用例,-51-,内容安排,理解需求 从业务模型获取需求 用例建模流程 获取原始需求 构建初始用例模型 编写用例文档 重构用例模型,-52-,从业务模型获取需求,有业务模型 从业务用例模型中寻找系统改进点 结合系统远景，获取系统用例来表达需求 采用需求启发技术，从涉众获得,-53-,从业务模型获取需求,从业务用例模型中获取系统需求，来构建系统用例模型 1. 寻找业务改进点 2. 定义项目远景 3. 导出系统需求,-54-,1. 业务改进点,业务模型描述业务现状，这些现状： 有些可能一直运转的很好，不需要改进，也就没有必要作为软件需求来由系统实现 而另外可能更多的业务在运转过程中存在这样或那
16、样的问题，这些问题就成为业务待改进的改进点，也就很可能作为软件需求而存在,-55-,寻找业务改进点,从业务流程中获取改进点的思路： 信息的自动流转 演绎复杂业务逻辑 访问和操作业务对象 自动工作 ,-56-,2. 远景(Vision),系统改进点不等同于软件需求 用户根据自身的工作特点和支付能力决定哪些应该改进，哪些不需要改进 这就是用户的远景，它表明用户改进的目标，这也将成为项目的目标 业务模型描述了“现实是什么”，远景则描述“希望的改进” 远景表达了“为什么要开发这个系统” 在业务现状(业务模型)下，开发系统是为了达到什么目标？,-57-,定义项目远景,远景包含了对待开发系统的目标和约束
17、代表了项目涉及的所有人之间达成的第一个共识 是项目核心需求的概览 为更详细的技术需求提供了契约性的依据 指导团队实现具体的业务目标 远景的作用 最初，根据项目的远景目标来决定项目是否值得继续 在项目批准后，团队根据项目远景来指导后续的需求和设计,-58-,远景说明,远景可以作为一个单独的文档存在，而这其中最重要的部分就是关于远景目标的说明，它建立了一个项目涉及的所有人的共同目标 远景说明应该是精确、清晰和激励性的描述，以便激励所有的团队成员为达成该远景而努力。一个好的远景应该具有以下五个特点(SMART)： 具体的（Specific） 可测量的（Measurable） 可实现的（Achieva
18、ble） 相关的（Relevant） 基于时间的（Time-based）,-59-,3. 导出系统需求,从业务改进点入手，结合项目远景，导出系统需求： 对于每一个业务改进点，明确是否是为了达到远景目标的需要 如果是则作为软件需求而存在，并把相应地模型作为系统模型 如果不是则不作为需求而存在，可能作为一项潜在的需求考虑，也可能直接抛弃,-60-,实例分析：旅店系统开发背景,随着旅店声誉日益提高，住宿人员越来越多，旅客为了能够获得好的房间，均提前预订房间 然而，随着预订的增多、预订周期的拉长，前台服务员工作压力也日益增大，还经常出现工作的失误，使得已经预订好房间的旅客也不能按期入住，这给酒店的声誉
19、带来不好的影响 为此，旅店老板想到了计算机，希望能够通过计算机来自动管理这些预订业务，不过由于目前资金的问题，目前只开发一个单机版的系统，不提供网上业务；并且旅店方面的其它业务暂不考虑信息化问题 旅店老板委托某计算机公司开发该系统，并承诺如果系统运转良好的话，将会考虑进一步合作事宜,-61-,远景：旅店预订系统,A很荣幸地成为项目经理，并被要求在两个月之内发布该系统的第一个版本，同时还被要求要为后续的开发提供必备的接口 结合现状和老板的要求，考虑到的项目可扩展的要求，A首先进行了简单的业务建模 之后，A初步定义了项目的远景 方便、快捷、准确地为旅客预订房间 旅客可以方便的取消预订的房间 旅店经
20、理能够定期的获取预订的信息，根据这些信息可以及时调整房间的价格 及时、快速地计算房间费用、预订费用、取消预订后退款金额等信息 ?预留接口：可以为以后的网络版，以及其它业务系统的开发提供支持,-62-,结合远景，获取系统需求,-63-,业务模型映射到系统模型思路,从业务改进点入手，结合系统远景，可以帮助获取系统模型 可能的对应关系(并非一一对应) 业务用例 系统(子系统) 业务参与者 系统参与者 业务工人 系统参与者 业务工人的操作(活动) 系统用例 业务实体 实体类,-64-,内容安排,理解需求 从业务模型获取需求 建立用例模型 编写用例文档 重构用例模型 其它问题,-65-,1.需求从何而来
21、,需求只能来自涉众(stakeholders) 最终用户、客户 政府、法律、文化 开发人员、管理人员 竞争对手 但并不是直接从涉众中来 你们的需求是什么？,-66-,涉众无法直接提供需求,涉众无法陈述自己的需要 涉众说的是解决方案而不是需求 涉众难以构想新的工作方法 涉众的利益矛盾 涉众抵制变更 “最好也要有”过度的要求 需求引发需求,-67-,需求启发技术,需求工程师利用需求启发技术，从涉众中发掘需求 收集资料 现场观察 访谈 开会 原型 问卷调查 ,-68-,2 识别参与者(Actor),识别参与者 关键词：边界 参与者：在系统之外，透过系统边界与系统进行有意义交互的任何事物,-69-,参
22、与者要点分析,系统外 参与者不是系统的一部分，处于系统的外部 系统边界 参与者透过系统边界直接与系统交互，参与者的确定代表系统边界的确定 系统角色 参与者与使用系统的物理人和职务没有关系 需要从参与系统的角色(作用)来寻找参与者 与系统进行信息交互 系统需要关注其交互过程，即系统职责 任何事物 人、外系统、外部因素、时间,-70-,要点：与系统进行信息交互,-71-,要点：任何事物,-72-,任何事物：小人与圣小猪-1,-73-,小人与圣小猪-2,众所周知，用例图中的参与者用一个小人表示。但是这个小人具有一定的误导性，往往让初学者(包括客户)理解为一个真实的人。大多数UML 学习者都要花好长一
23、段时间来搞明白小人其实不一定代表的是人，而是很抽象的系统不可控的外部因素，比如说另一个系统。那么为什么不干脆用其它的符号来表示参与者呢？ 如果我开发一个猪圈自动供食供水系统，猪的前蹄触发一个开关系统就供食或供水。显然，这里的参与者 是小猪。那么在用例图里用小猪代替原来的小人不是更易于交流吗？,-74-,思考：参与者与系统边界？,某企业要求开发一个企业信息管理系统，并与原来已有的库存系统相连接 某企业要求开发一个企业信息管理系统，并把原来已有的库存管理系统加以改造，成为企业信息管理系统的一部分,-75-,识别参与者的思路,可以从以下要点来识别参与者 系统在哪些部门使用 谁向系统提供信息、使用和删
24、除信息。 谁与系统的需求有关联 谁使用系统的功能（用例） 谁对系统进行维护 与外部系统是否有关联 时间参与者：一种习惯用法，用于激活那些系统定期的、自动执行的用例,-76-,参与者的命名,对参与者赋予能更好地表达其角色(作用)的名称 不好的参与者命名的例子：用职务名称和个人姓名来命名 例如，张三、老李、校长、科长 若使用系统的人（职务名称）变化的话，就不是参与者了 好的参与者命名的例子：用能知道其角色的名称来命名 例如，学生、订单管理员、维护部门 即使使用系统的人改变，从系统来看，使用者的角色（作用）是相同的。,-77-,参与者之间的关系：泛化,参与者可以通过泛化关系来定义，在这种泛化关系中，
25、一个参与者的抽象描述可以被一个或多个具体的参与者所共享 如系统中经理可以参加雇员的所有用例,-78-,参与者地位,识别用例之前重要 有助于识别用例，宁多勿少 开始书写用例文档以后不重要 涉及的参与者太多 测试和部署阶段重要 需要从参与者的角度考虑,-79-,3 识别用例,关键词：价值 定义 用例实例是系统执行的一系列动作，这些动作将生成特定参与者可观测的结果值 一个用例定义一组用例实例（场景） 简洁：参与者使用系统达到某个目标,-80-,用例要点,可观测用例止于系统边界 结果值用例是有意义的目标 系统执行结果值由系统生成 由参与者观测业务语言、用户观点 一组用例实例用例的粒度,-81-,要点：
26、有意义的目标,-82-,要点：结果值由系统生成,系统需要处理的，由系统生成,-83-,要点：用户观点而非系统观点,用户观点,系统观点,-84-,用例的命名,参与者视角： （状语）动词+（定语+ ）宾语,-85-,要点：用例粒度-1,用例是一组用例实例的抽象；其内部要有路径，路径要有步骤 最常犯错误：粒度过细，陷入功能分解 通过执行用例，参与者完成想做的事情(最终的目的)，并为参与者产生价值 过细的粒度，一般都会导致技术语言的描述，而不再是业务语言,-86-,用例粒度-2,把步骤当用例把系统活动当用例,-87-,用例粒度-3,“四轮马车” C(Create) R(Read) U(Update)
27、D(Delete) 所有业务最终对会成为CRUD？ CRUD能为Actor提供价值？ CRUD掩盖业务，锐变成关系数据库的建模： “系统就是数据的增删改查” 关心数据的存储和维护，反而忽略了用户的目的,-88-,用例粒度-4,如果确实是CRUD？ 如果CRUD不涉及复杂的交互，一个用例“管理”即可 不管是C、R、U、D，都是为了完成“管理”目标 甚至很多种的基本数据管理都可以用一个用例表示,-89-,用例粒度-5,灵活处理CRUD,可以把包含复杂交互的路径独立出去形成用例,-90-,找出用例的思路,用例要考虑如下要点来寻找。 参与者的工作是什么 参与者的角色(作用)是什么 参与者是否生成、参照
28、、删除系统信息 参与者是否需要把外部变更通知给系统 系统是否需要把内部事情通知给参与者 是否存在进行系统维护的用例 用例数量的参考基准 1个系统中存在十几个用例(或更少) 1个用例中有多个用例实例(场景),-91-,UML2.4中的常见的14种图,UML2.4-图 Diagrams,类图 Class Diagrams,对象图 Object Diagrams,构件图 Component Diagrams,部署图 Deployment Diagrams,用例图 Use Case Diagrams,顺序图 Sequence Diagrams,通信图 Communication Diagrams,状态
29、机图 State Machine Diagrams,活动图 Activity Diagrams,静态模型 (系统结构),动态模型 (系统行为),包图 Package Diagrams,组合结构图 Composite Structure Diagrams,时间图 Timing Diagrams,交互纵览图 Interaction Overview Diagrams,外廓图 Profile Diagrams,画用例图的基本元素,附录2-1. UML元语,-94-,用例图元语,返回用例图,-95-,活动图元语,返回活动图,-96-,类图、对象图、包图元语,返回静态结构图,组合结构图元语,-97-,返
30、回组合结构图,-98-,顺序图元语,返回顺序图,-99-,通信图元语,返回通信图,-100-,交互纵览图元语,返回交互纵览图,时间图元语,-101-,返回时间图,-102-,状态机图元语,返回状态机图,-103-,构件图元语,返回构件图,-104-,部署图元语,返回部署图,-105-,外廓图,返回外廓图,-106-,4 构建用例图,用例图：表达参与者与用例关系图形,-107-,内容安排,从业务模型获取需求 建立用例模型 编写用例文档 重构用例模型 其它问题,-108-,撰写用例文档,用例文档：更进一步的精度 需求规格说明书的核心，而用例图作为用例文档的索引图 进一步的精度：有层次的文档 文档中
31、每一句话都有其价值,用例图是骨架，而用例文档则是其内在的肉,-109-,用例文档的组成,用例标识(UC)、名称、描述 涉及的参与者、涉及的用例 涉众利益 前置条件、后置条件 事件流 基本路径 备选路径 补充约束 字段列表、业务规则 非功能需求、设计约束 待解决问题 相关图(用例图、活动图、类图),用例文档参考模板,-111-,寻找涉众的思路,区分涉众与参与者 涉众是与当前用例存在利益关系的人或组织 参与者是启动或参与用例执行过程的人或外部事物 可能的涉众有： 当事人 上游下游 操作对象的主人 ,-112-,前置、后置条件,前置条件约束在用例开始前系统的状态 作为用例的入口限制，它阻止参与者触发
32、该用例直到满足所有条件 说明在用例触发之前什么必须为真 后置条件约束用例执行后系统的状态 用例执行后什么必须为真 对于存在各种分支事件流的用例，则可以指定多个后置条件把用例看作是参与者与系统交互的流程，前置条件和后置条件则是这个流程的入口和出口状态。如图,直线箭头表示基本事件流，曲线箭头代表各种备选事件流，注意前置条件和后置条件所处位置,-113-,定义前置、后置条件,前置、后置条件必须是系统能检测到的 前置条件必须是系统在用例开始前就能检测到的,-114-,应用前置、后置条件,某些用例依赖于其他用例 一个用例在离开系统时，可能是另一个用例的前置条件（例如：“登录”和“管理系统”） 有助于识别
33、漏掉的用例 如果一个用例的前置条件不能有执行其他用例满足，可能意味着丢失了用例（例如：“管理订单”却没有“登录”用例）,-115-,事件流描述-用例交互四部曲,1. 动 作,4. 响 应,2.验证,3.处理,系 统,重点写：1和4（可观测的、体现客户利益的文字）,用例的核心内容就是参与者和系统交互的过程，这个交互过程在用例文档中采用事件流的方式进行完整的表示。如图,-116-,事件流描述要点,事件流描述要使用户和开发人员互相理解用例的功能，要注意以下几点： 使用业务语言：使用用户平时所使用的语言进行描述 要明确参与者与系统所交互的信息 不使用例如、等这样的不清晰的表达 不要过多地考虑界面细节
34、不要描述计算机内部的处理，要描述从系统外部所看到的活动 除了基本流程，还要描述替代流程 要明确描述用例的开始和结束,-117-,例1：使用业务语言,技术语言：无法与用户沟通 系统通过JDBC建立数据库连接，传送SQL查询语句，从“商品表”查询商品的详细信息 业务语言(用户语言) 系统按照查询条件搜索商品的详细信息,-118-,例2：描述参与者与系统交互过程,以参与者或系统作为主语描述 参与者 系统 示例 出纳员接收顾客的付款顾客的付款数可能高于商品总额 出纳员录入顾客所付的现金总额 系统显示出应找还给顾客的余额，打印付款收据,-119-,例3：不细化界面细节,过细的界面细节描述 会员从下拉框中
35、选择类别 会员在相应文本框中输入查询条件 会员点击“确定”按钮,-120-,例4：分支和循环的描述,分支：放到备选路径中 参与者的选择 另一条成功线路 系统进行验证 循环：直接描述,-121-,用例文档中的补充约束,用例重点在于描述功能需求，而其它方面的补充约束采用两种处理策略： 与特定用例相关的补充约束，作为该用例文档中一部分来描述 一些全局性的补充约束，单独形成一份独立的文档，如“补充需求规约”文档 补充约束 字段列表 业务规则 非功能需求 设计约束,-122-,实例分析：撰写用例文档,用例文档参考模板 旅店预订系统用例文档 “ UC01-预订房间”用例文档,-123-,内容安排,从业务模
36、型获取需求 建立用例模型 编写用例文档 重构用例模型 其它问题,重构用例模型,对于一些复杂的系统，用例可能很多，所以可以利用用例建模高级技术重构用例模型 用例关系 通过用例关系将复杂的用例进行适当的分解，以便于提高需求的复用性和可扩展性等，从而使用例模型的结构更合理 用例分级 可以根据用例的重要程度进行分级，以便后续迭代计划的制定，高级别的用例优先考虑 用例分包 将相关的用例打包，通过分包的方式可以将用例图分层表示，以用于大规模系统的用例建模,-124-,-125-,用例关系,扩展,包含,泛化,-126-,通过关系整理文档,Extend(扩展) 通过扩展用例对基用例增加附加的行为 Includ
37、e(包含) 基用例中复用被包含用例的行为 提取公共步骤，便于复用 Generalization(泛化) 派生用例继承泛化用例的行为并添加新行为,-127-,用例关系：扩展,扩展：某个用例在特定情况下，包含其他用例(扩展用例)的行为，表示功能被扩展 扩展使用带有的虚线表示。此时，箭头由扩展的用例指向原用例，通过扩展点指明在原用例中的扩展位置,-128-,用例关系：包含,包含：表示某个用例中包含了其他用例的行为 包含用带有的虚线来表示。此时，箭头由原有的用例指向被包含部分的用例,-129-,扩展 VS. 包含-1,包含：由用例A连向用例B，表示用例A中使用了用例B中的行为或功能 包含关系的提出一般
38、是基于用例行为复用的考虑，这也意味着被包含的用例往往被多个基用例引用 扩展：由用例B连向用例A，表示用例A描述了一项基本需求，而用例B则描述了该基本需求的特殊情况，即一种扩展 扩展用例的提出是为了将基用例的一些特殊情况分离出来，在保持基用例本身相对完整的情况下（即一般情况都能处理）来处理这些特殊行为,-130-,用例关系：泛化,泛化：表示子用例继承了父用例 用例间的泛化关系表明子用例继承父用例中定义的所有属性、行为序列和扩展点，并且参与父用例中所有的关系,-131-,用例分包,对用例进行分包 让用例图能够更为清晰地表现出系统的业务逻辑关系和层次 对系统进行模块的分割，这将影响到今后的开发和系统
39、的最终表现形式 常见的分包方式 按参与者分包 按主题分包 按开发团队分包 按发布情况分包,先按主题分包，主题内再按开发团队和发布情况分包,-132-,利用分包机制组织用例模型,-133-,用例分级,用例和迭代开发 迭代开发中开发周期的定义是围绕用例来组织的 一个迭代周期要被指派一个到多个用例，如果完全版本的用例在一个迭代周期中处理起来太复杂的话，那就采用简化版本的用例,迭代周期,迭代周期,迭代周期,用例A -简化版本,用例A -完整版本,用例B,用例C,-134-,用例分级实施策略-1,可以使用一个简单的但是有些不精确的分类方法，如将用例划分成高、中、低三个等级,-135-,用例分级原则,用例
40、分级的一个基本原则 高级别用例是那些对系统核心架构影响最大的用例 提高用例级别的特性： a. 对架构设计有重要影响的用例，如在领域层中增加多个类的用例或者需要持久化的用例 b. 不需要花费很多努力就可以从中获得重要信息和线索的那些用例 c. 含有开发风险、时间紧迫或功能复杂的用例 d. 涉及到重要技术研究或者新技术和高风险的用例 e. 代表主要的在线业务流程的用例 f. 能产生直接经济效益或者降低成本的用例,-136-,用例分级实施策略-2,依照上述的影响用例级别的特性给用例打分（特性也可能带有权值）,-137-,内容安排,从业务模型获取需求 建立用例模型 编写用例文档 重构用例模型 其它问题,用例建模中常见的问题,用例不是功能分解 用例图不是流程图 用例关系的误用,-138-,-139-,何时适用用例建模,用例是从参与者角度捕获系统功能，当系统只有一个或者没有参与者时，显然不是非常有效的 用例捕获功能需求，因此对于系统的非功能需求不是有效 当遇到下述情况时，用例是需求捕获的最好选择 系统由功能需求所主导 系统具有很多类型的用户，系统对他们提供不同的功能 系统具有很多接口 当遇到下述情况时，用例是一个糟糕的选择： 系统由非功能需求所主导（如：google） 系统具有很少的用户 系统具有很少的接口（非内部功能） 如：嵌入式系统、算法复杂但接口少的系统等,
