业务建模及用例建模课件.ppt

《业务建模及用例建模课件.ppt》由会员分享，可在线阅读，更多相关《业务建模及用例建模课件.ppt（139页珍藏版）》请在三一办公上搜索。

1、面向对象分析与设计Object-Oriented Analysis & Design,1,t课件,学习路线图,2,t课件,核心过程,3,t课件,业务建模,Business Modeling,4,t课件,开发过程解析,业务建模：用软件建模方法描述业务流程；其目标是认识业务本质，该业务本质是后续用例建模的基础用例建模：采用UML用例建模技术描述软件需求，该需求模型将为后续用例分析提供输入用例分析：采用UML用例分析技术分析软件需求，建立软件系统的分析模型架构设计：在系统的全局范围内，以分析模型为基础，设计系统的架构构件设计：根据架构设计的成果，将分析模型细化，设计系统构件的实现细节代码实现：将系统

2、构件映射到目标语言上,5,t课件,业务,业务是指某个组织或者组织单元业务可以看作一种包含了人、机器、资源的“系统”利用软件思想(用例思想、对象思想)描述业务的过程，就是业务建模业务建模只是辅助环节不是所有项目都需要也不一定和软件开发相关,6,t课件,业务建模,业务建模的目的理解将要实施的系统的组织结构和动态特性理解当前在目标组织中的问题，并明确改进的潜力确保客户、最终用户和开发人员对目标组织有统一的理解获取用于支持目标组织的系统需求业务建模关注机构的核心价值机构的边界机构的参与者机构中的工作流及如何优化,7,t课件,业务建模方法,研究对象软件要改进的业务单元研究目标定义业务本质研究方法用例观点

3、：把业务看成对外提供价值的价值流,8,t课件,业务建模工件,业务用例模型(Business Use-Case Model)业务用户表示为业务参与者(Business Actor)业务过程表示为业务用例(Business Use-Case)和业务用例实现业务对象模型(Business Object Model)人们在组织中扮演的角色表示为业务工人(Business Worker)组织管理或制造的“东西”表示为业务实体(Business Entity),9,t课件,业务建模流程,0. 建立业务用例模型1. 识别业务参与者2. 识别业务用例3. 详述业务用例4. 建立业务对象模型,10,t课件,业务

4、建模流程,0. 建立业务用例模型1. 识别业务参与者2. 识别业务用例3. 详述业务用例1. 建立业务对象模型,11,t课件,1.业务参与者(Business Actor),识别业务参与者在业务之外，与业务进行交互的人或组织,-12-,t课件,区分业务工人(Business Worker),业务参与者在业务外面业务工人在业务里面,-13-,t课件,区分业务实体(Business Entity),14,t课件,识别业务参与者思路,客户供应商合作伙伴潜在客户政府组织中未建模部分,-15-,t课件,2.业务用例(Business Use Case),识别业务用例业务为业务参与者提供的价值体现企业业务

5、本质，是有意义的目标,-16-,t课件,业务用例与业务参与者,17,t课件,识别业务用例的方法,直接获得：从业务参与者的角度，从外部推导出来拼装：从里面往外面看，内部业务流程的目标是什么,直接获得,拼装,-18-,t课件,从业务流程拼装业务用例,业务流程1. 收款人在支票背后签名，写上身份证件号码，把支票和身份证件交给营业员2. 营业员核对印章正确且证件有效3. 营业员操作营业受理系统，办理支票兑现手续4. 营业员把现金和证件交给交款人,19,t课件,识别业务用例-支持性事件,不要遗漏支撑性业务流程背后的业务用例支持性事件人员的发展与维护业务内部IT的开发与维护办公室的设立与维护安全性法律活动

6、例：公司为什么要举行足球比赛？,20,t课件,3.详述业务用例,业务用例是对业务流程的封装，在业务建模过程中需要逐一描述其内部细节，即详述业务用例目的详细说明业务用例的工作流程说明业务用例的工作流程，以便于客户、用户和涉众理解,21,t课件,三种可选技术,文字,活动图,顺序图,22,t课件,选择合适的技术,只有文字不生动，不便于和客户交流只有活动图难以表达所有细节业务用例文档中插入活动图活动图中插入文字(+注释+基本路径)顺序图(需要涉及到业务对象模型),23,t课件,细说活动图,24,t课件,细说活动图(1),起点、终点活动的一种特殊形式，各自只有一个起点：只有离开的转移终点：只有进入的转移

7、存在从起点出发，到达终点的路径活动和动作有进有出动宾结构可以简单，可以复杂分区定义活动的负责者,25,t课件,细说活动图(2),控制流向外转移的条件之和必须是完备集向外转移的条件之间不能重叠决策点注意和流程图的区别误把活动当决策图中判断“技术可行性”需要单独的活动来完成,26,t课件,细说活动图(3),并发(concurrent)同步条(synchronization bar)的分叉(fork)与合并(join)有分必有合有分必有进有合必有出并发同时,27,t课件,活动图中的对象流,指定活动操作的数据(对象)以及数据的流向(对象流)业务对象(business objects)、对象流(obje

8、ct flows) 指出对某些业务实体的操作，类似结构化中的数据流图UML2中对象流由原来的虚线改为实线,28,t课件,活动图的分层,活动可以简单可以复杂，复杂的活动可以进一步细化：分层顶层有起点终点，下层可以没有出入平衡,29,t课件,4.业务对象模型,业务对象模型(Business Object Model)勾勒出实现业务关系中的人、事物、设备、资源以及它们之间的关系；即业务工人和业务实体之间的静态关系从另一个视角描述现实使用UML类图描述不要和待开发系统中的分析设计类相混淆,30,t课件,餐馆的业务对象模型,31,t课件,业务建模实践：建模指南,业务模型不是UML标准直接支持的，但是通过

9、UML的扩展机制可以很方便的建立业务模型主要构造型(stereotype)业务用例模型参与者的构造型：业务参与者(Business Actor)用例的构造型：业务用例(Business Use Case)业务对象模型类的构造型：业务工人(Business Worker)、业务实体(Business Entity),32,t课件,建模指南：模型的组织,利用“包”组织模型用例视图中“业务用例模型”每个业务用例的”状态/活动模型”逻辑视图中“业务对象模型”,-33-,t课件,建模指南：使用构造型,业务用例模型是在UML的用例模型(用例图)基础上添加构造型来实现的业务对象模型是在UML的对象模型(类图

10、)基础上添加构造型来实现的利用已有元素添加构造型Rose直接支持这些构造型,34,t课件,业务建模实践：实例分析,研究对象：某旅店业务现状：某旅店可对外开放50个双人间和20个单人间，房间费用视情况按季节调整，但周一到周五提供半价（周末全价）折扣旅客可以直接入住房间(如果有空房)，也可提前预订；入住和预订都需要登记个人信息旅客提前预订房间时，需提交一定的订金；入住时间24小时之外的旅客可以取消预订，并退回所有订金，24小时以内则不退还订金退房时缴纳全部的住宿费用服务员每月为经理提供房间的预订情况和入住情况的详细信息,35,t课件,实例分析：业务用例模型,旅店的本质就是为旅客提供住宿服务，其它的

11、只是为达到这个目标而采用的手段(用例观点：把业务看成对外提供价值的价值流),36,t课件,实例分析：旅客住宿业务流程,37,t课件,实例分析：检查业务用例模型,该业务用例模型体现了整个旅店的业务需求吗？如何考虑这项业务：服务员每月为经理提供房间的预订情况和入住情况的详细信息？经理是什么，如何体现在业务建模过程中？是业务参与者还是业务工人？体现怎样的业务本质的差异？,38,t课件,实例分析：业务对象模型,39,t课件,从业务模型到系统模型,对于软件开发而言，业务建模只是辅助环节，并不是最终目标软件工程师最终目标是要构造软件系统业务建模则是一种定义系统模型的辅助手段从业务模型到系统模型业务模型描述

12、了目前的业务现状系统模型才是软件开发的最终工件,40,t课件,业务模型为系统模型提供素材,为用例视图和逻辑视图提供输入对于每个将被系统实现的业务用例，在用例视图中确定一个系统用例或用例包（或单独的子系统）来实现该业务为需要支持自动化业务确定相应的用例对于业务对象模型中的业务实体，可以在系统模型中定义对应的实体类为系统构架提供一些重要的构架机制在软件构架中定义专用层来实现复杂的业务逻辑,41,t课件,业务模型映射到系统模型,从业务改进点入手，结合系统远景，可以帮助获取系统模型可能的对应关系(并非一一对应)业务用例 系统(子系统)业务参与者 系统参与者业务工人 系统参与者业务工人的操作(活动) 系

13、统用例业务实体 实体类,42,t课件,用例建模,Use Case Modeling,43,t课件,内容安排,理解需求从业务模型获取需求建立用例模型编写用例文档重构用例模型其它问题,44,t课件,内容安排,理解需求从业务模型获取需求建立用例模型编写用例文档重构用例模型其它问题,45,t课件,需求建造“正确”的系统,需求：客户可接受的、系统必须满足的条件或具备的能力RUP中的FURPS+软件质量准则功能性（Functionality）使用性（Usability）可靠性（Reliability）性能（Performance）可支持性（Supportability）+,非功能性需求,46,t课件,需求

14、工程的主要活动,定义需求理解用户的需要，建立用户可理解的系统需求模型分析需求根据需求模型，建立开发者无二义性解释的分析模型需求管理,47,t课件,需求难在何处：石头问题,我要一块石头差不多，但我要小一点的很好，不过我要蓝色的啊，没有那么小咳，还是原来那个好了,小一点的蓝色大理石,难捕获，易变！,48,t课件,需求：也需要开发,客户/用户的要求/想法/期望,软件设计,软件产品,开发,编码和测试,验收,有价值的软件需求,分析和设计,49,t课件,需求问题：对策,难捕获,易变,从用户视角看问题,合理的结构,用例,50,t课件,内容安排,理解需求从业务模型获取需求用例建模流程获取原始需求构建初始用例模

15、型编写用例文档重构用例模型,51,t课件,从业务模型获取需求,有业务模型从业务用例模型中寻找系统改进点结合系统远景，获取系统用例来表达需求采用需求启发技术，从涉众获得,52,t课件,从业务模型获取需求,从业务用例模型中获取系统需求，来构建系统用例模型1. 寻找业务改进点2. 定义项目远景3. 导出系统需求,53,t课件,1. 业务改进点,业务模型描述业务现状，这些现状：有些可能一直运转的很好，不需要改进，也就没有必要作为软件需求来由系统实现而另外可能更多的业务在运转过程中存在这样或那样的问题，这些问题就成为业务待改进的改进点，也就很可能作为软件需求而存在,54,t课件,寻找业务改进点,从业务流

16、程中获取改进点的思路：信息的自动流转演绎复杂业务逻辑访问和操作业务对象自动工作,55,t课件,2. 远景(Vision),系统改进点不等同于软件需求用户根据自身的工作特点和支付能力决定哪些应该改进，哪些不需要改进这就是用户的远景，它表明用户改进的目标，这也将成为项目的目标业务模型描述了“现实是什么”，远景则描述“希望的改进” 远景表达了“为什么要开发这个系统”在业务现状(业务模型)下，开发系统是为了达到什么目标？,56,t课件,定义项目远景,远景包含了对待开发系统的目标和约束代表了项目涉及的所有人之间达成的第一个共识是项目核心需求的概览为更详细的技术需求提供了契约性的依据指导团队实现具体的业务

17、目标远景的作用最初，根据项目的远景目标来决定项目是否值得继续在项目批准后，团队根据项目远景来指导后续的需求和设计,57,t课件,远景说明,远景可以作为一个单独的文档存在，而这其中最重要的部分就是关于远景目标的说明，它建立了一个项目涉及的所有人的共同目标远景说明应该是精确、清晰和激励性的描述，以便激励所有的团队成员为达成该远景而努力。一个好的远景应该具有以下五个特点(SMART)：具体的（Specific）可测量的（Measurable）可实现的（Achievable）相关的（Relevant）基于时间的（Time-based）,58,t课件,3. 导出系统需求,从业务改进点入手，结合项目远景，

18、导出系统需求：对于每一个业务改进点，明确是否是为了达到远景目标的需要如果是则作为软件需求而存在，并把相应地模型作为系统模型如果不是则不作为需求而存在，可能作为一项潜在的需求考虑，也可能直接抛弃,59,t课件,实例分析：旅店系统开发背景,随着旅店声誉日益提高，住宿人员越来越多，旅客为了能够获得好的房间，均提前预订房间然而，随着预订的增多、预订周期的拉长，前台服务员工作压力也日益增大，还经常出现工作的失误，使得已经预订好房间的旅客也不能按期入住，这给酒店的声誉带来不好的影响为此，旅店老板想到了计算机，希望能够通过计算机来自动管理这些预订业务，不过由于目前资金的问题，目前只开发一个单机版的系统，不提

19、供网上业务；并且旅店方面的其它业务暂不考虑信息化问题旅店老板委托某计算机公司开发该系统，并承诺如果系统运转良好的话，将会考虑进一步合作事宜,60,t课件,远景：旅店预订系统,A很荣幸地成为项目经理，并被要求在两个月之内发布该系统的第一个版本，同时还被要求要为后续的开发提供必备的接口结合现状和老板的要求，考虑到的项目可扩展的要求，A首先进行了简单的业务建模之后，A初步定义了项目的远景方便、快捷、准确地为旅客预订房间旅客可以方便的取消预订的房间旅店经理能够定期的获取预订的信息，根据这些信息可以及时调整房间的价格及时、快速地计算房间费用、预订费用、取消预订后退款金额等信息?预留接口：可以为以后的网络

20、版，以及其它业务系统的开发提供支持,61,t课件,结合远景，获取系统需求,62,t课件,业务模型映射到系统模型思路,从业务改进点入手，结合系统远景，可以帮助获取系统模型可能的对应关系(并非一一对应)业务用例 系统(子系统)业务参与者 系统参与者业务工人 系统参与者业务工人的操作(活动) 系统用例业务实体 实体类,63,t课件,内容安排,理解需求从业务模型获取需求建立用例模型编写用例文档重构用例模型其它问题,64,t课件,1.需求从何而来,需求只能来自涉众(stakeholders)最终用户、客户政府、法律、文化开发人员、管理人员竞争对手但并不是直接从涉众中来你们的需求是什么？,65,t课件,涉

21、众无法直接提供需求,涉众无法陈述自己的需要涉众说的是解决方案而不是需求涉众难以构想新的工作方法涉众的利益矛盾涉众抵制变更“最好也要有”过度的要求需求引发需求,66,t课件,需求启发技术,需求工程师利用需求启发技术，从涉众中发掘需求收集资料现场观察访谈开会原型问卷调查,67,t课件,2 识别参与者(Actor),识别参与者关键词：边界参与者：在系统之外，透过系统边界与系统进行有意义交互的任何事物,68,t课件,参与者要点分析,系统外参与者不是系统的一部分，处于系统的外部系统边界参与者透过系统边界直接与系统交互，参与者的确定代表系统边界的确定系统角色参与者与使用系统的物理人和职务没有关系需要从参与

22、系统的角色(作用)来寻找参与者与系统进行信息交互系统需要关注其交互过程，即系统职责任何事物人、外系统、外部因素、时间,69,t课件,要点：与系统进行信息交互,70,t课件,要点：任何事物,71,t课件,任何事物：小人与圣小猪-1,72,t课件,小人与圣小猪-2,众所周知，用例图中的参与者用一个小人表示。但是这个小人具有一定的误导性，往往让初学者(包括客户)理解为一个真实的人。大多数UML 学习者都要花好长一段时间来搞明白小人其实不一定代表的是人，而是很抽象的系统不可控的外部因素，比如说另一个系统。那么为什么不干脆用其它的符号来表示参与者呢？如果我开发一个猪圈自动供食供水系统，猪的前蹄触发一个开

23、关系统就供食或供水。显然，这里的参与者 是小猪。那么在用例图里用小猪代替原来的小人不是更易于交流吗？,73,t课件,思考：参与者与系统边界？,某企业要求开发一个企业信息管理系统，并与原来已有的库存系统相连接某企业要求开发一个企业信息管理系统，并把原来已有的库存管理系统加以改造，成为企业信息管理系统的一部分,74,t课件,识别参与者的思路,可以从以下要点来识别参与者系统在哪些部门使用谁向系统提供信息、使用和删除信息。谁与系统的需求有关联谁使用系统的功能（用例）谁对系统进行维护与外部系统是否有关联时间参与者：一种习惯用法，用于激活那些系统定期的、自动执行的用例,75,t课件,参与者的命名,对参与者

24、赋予能更好地表达其角色(作用)的名称不好的参与者命名的例子：用职务名称和个人姓名来命名例如，张三、老李、校长、科长若使用系统的人（职务名称）变化的话，就不是参与者了好的参与者命名的例子：用能知道其角色的名称来命名例如，学生、订单管理员、维护部门即使使用系统的人改变，从系统来看，使用者的角色（作用）是相同的。,76,t课件,参与者之间的关系：泛化,参与者可以通过泛化关系来定义，在这种泛化关系中，一个参与者的抽象描述可以被一个或多个具体的参与者所共享如系统中经理可以参加雇员的所有用例,-77-,t课件,参与者地位,识别用例之前重要有助于识别用例，宁多勿少开始书写用例文档以后不重要涉及的参与者太多测

25、试和部署阶段重要需要从参与者的角度考虑,78,t课件,3 识别用例,关键词：价值定义用例实例是系统执行的一系列动作，这些动作将生成特定参与者可观测的结果值一个用例定义一组用例实例（场景）简洁：参与者使用系统达到某个目标,79,t课件,用例要点,可观测用例止于系统边界结果值用例是有意义的目标系统执行结果值由系统生成由参与者观测业务语言、用户观点一组用例实例用例的粒度,80,t课件,要点：有意义的目标,81,t课件,要点：结果值由系统生成,系统需要处理的，由系统生成,82,t课件,要点：用户观点而非系统观点,用户观点,系统观点,83,t课件,用例的命名,参与者视角：（状语）动词+（定语+ ）宾语,

26、-84-,t课件,要点：用例粒度-1,用例是一组用例实例的抽象；其内部要有路径，路径要有步骤最常犯错误：粒度过细，陷入功能分解通过执行用例，参与者完成想做的事情(最终的目的)，并为参与者产生价值过细的粒度，一般都会导致技术语言的描述，而不再是业务语言,85,t课件,用例粒度-2,把步骤当用例把系统活动当用例,86,t课件,用例粒度-3,“四轮马车”C(Create)R(Read)U(Update)D(Delete)所有业务最终对会成为CRUD？CRUD能为Actor提供价值？CRUD掩盖业务，锐变成关系数据库的建模：“系统就是数据的增删改查”关心数据的存储和维护，反而忽略了用户的目的,-87-

27、,t课件,用例粒度-4,如果确实是CRUD？如果CRUD不涉及复杂的交互，一个用例“管理”即可不管是C、R、U、D，都是为了完成“管理”目标甚至很多种的基本数据管理都可以用一个用例表示,88,t课件,用例粒度-5,灵活处理CRUD,可以把包含复杂交互的路径独立出去形成用例,89,t课件,找出用例的思路,用例要考虑如下要点来寻找。参与者的工作是什么参与者的角色(作用)是什么参与者是否生成、参照、删除系统信息参与者是否需要把外部变更通知给系统系统是否需要把内部事情通知给参与者是否存在进行系统维护的用例用例数量的参考基准1个系统中存在十几个用例(或更少)1个用例中有多个用例实例(场景),90,t课件

28、,UML2.4中的常见的14种图,UML2.4-图Diagrams,类图Class Diagrams,对象图Object Diagrams,构件图Component Diagrams,部署图Deployment Diagrams,用例图Use Case Diagrams,顺序图Sequence Diagrams,通信图Communication Diagrams,状态机图State Machine Diagrams,活动图Activity Diagrams,静态模型(系统结构),动态模型(系统行为),包图Package Diagrams,组合结构图Composite Structure Dia

29、grams,时间图Timing Diagrams,交互纵览图Interaction Overview Diagrams,外廓图Profile Diagrams,91,t课件,画用例图的基本元素,92,t课件,附录2-1. UML元语,93,t课件,用例图元语,返回用例图,94,t课件,活动图元语,返回活动图,95,t课件,类图、对象图、包图元语,返回静态结构图,96,t课件,组合结构图元语,返回组合结构图,97,t课件,顺序图元语,返回顺序图,98,t课件,通信图元语,返回通信图,99,t课件,交互纵览图元语,返回交互纵览图,100,t课件,时间图元语,返回时间图,101,t课件,状态机图元语

30、,返回状态机图,102,t课件,构件图元语,返回构件图,103,t课件,部署图元语,返回部署图,104,t课件,外廓图,返回外廓图,105,t课件,4 构建用例图,用例图：表达参与者与用例关系图形,106,t课件,内容安排,从业务模型获取需求建立用例模型编写用例文档重构用例模型其它问题,107,t课件,撰写用例文档,用例文档：更进一步的精度需求规格说明书的核心，而用例图作为用例文档的索引图进一步的精度：有层次的文档文档中每一句话都有其价值,用例图是骨架，而用例文档则是其内在的肉,108,t课件,用例文档的组成,用例标识(UC)、名称、描述涉及的参与者、涉及的用例涉众利益前置条件、后置条件事件流

31、基本路径备选路径补充约束字段列表、业务规则非功能需求、设计约束待解决问题相关图(用例图、活动图、类图),109,t课件,用例文档参考模板,110,t课件,寻找涉众的思路,区分涉众与参与者涉众是与当前用例存在利益关系的人或组织参与者是启动或参与用例执行过程的人或外部事物可能的涉众有：当事人上游下游操作对象的主人,111,t课件,前置、后置条件,前置条件约束在用例开始前系统的状态作为用例的入口限制，它阻止参与者触发该用例直到满足所有条件说明在用例触发之前什么必须为真后置条件约束用例执行后系统的状态用例执行后什么必须为真对于存在各种分支事件流的用例，则可以指定多个后置条件 把用例看作是参与者与系统交

32、互的流程，前置条件和后置条件则是这个流程的入口和出口状态。如图,直线箭头表示基本事件流，曲线箭头代表各种备选事件流，注意前置条件和后置条件所处位置,-112-,t课件,定义前置、后置条件,前置、后置条件必须是系统能检测到的前置条件必须是系统在用例开始前就能检测到的,113,t课件,应用前置、后置条件,某些用例依赖于其他用例一个用例在离开系统时，可能是另一个用例的前置条件（例如：“登录”和“管理系统”）有助于识别漏掉的用例如果一个用例的前置条件不能有执行其他用例满足，可能意味着丢失了用例（例如：“管理订单”却没有“登录”用例）,114,t课件,事件流描述-用例交互四部曲,1. 动 作,4. 响

33、应,2.验证,3.处理,系 统,重点写：1和4（可观测的、体现客户利益的文字）,用例的核心内容就是参与者和系统交互的过程，这个交互过程在用例文档中采用事件流的方式进行完整的表示。如图,115,t课件,事件流描述要点,事件流描述要使用户和开发人员互相理解用例的功能，要注意以下几点：使用业务语言：使用用户平时所使用的语言进行描述要明确参与者与系统所交互的信息不使用例如、等这样的不清晰的表达不要过多地考虑界面细节不要描述计算机内部的处理，要描述从系统外部所看到的活动除了基本流程，还要描述替代流程要明确描述用例的开始和结束,116,t课件,例1：使用业务语言,技术语言：无法与用户沟通系统通过JDBC建

34、立数据库连接，传送SQL查询语句，从“商品表”查询商品的详细信息业务语言(用户语言)系统按照查询条件搜索商品的详细信息,117,t课件,例2：描述参与者与系统交互过程,以参与者或系统作为主语描述参与者系统示例出纳员接收顾客的付款顾客的付款数可能高于商品总额出纳员录入顾客所付的现金总额系统显示出应找还给顾客的余额，打印付款收据,118,t课件,例3：不细化界面细节,过细的界面细节描述会员从下拉框中选择类别会员在相应文本框中输入查询条件会员点击“确定”按钮,119,t课件,例4：分支和循环的描述,分支：放到备选路径中参与者的选择另一条成功线路系统进行验证循环：直接描述,120,t课件,用例文档中的

35、补充约束,用例重点在于描述功能需求，而其它方面的补充约束采用两种处理策略：与特定用例相关的补充约束，作为该用例文档中一部分来描述一些全局性的补充约束，单独形成一份独立的文档，如“补充需求规约”文档补充约束字段列表业务规则非功能需求设计约束,121,t课件,实例分析：撰写用例文档,用例文档参考模板旅店预订系统用例文档“ UC01-预订房间”用例文档,122,t课件,内容安排,从业务模型获取需求建立用例模型编写用例文档重构用例模型其它问题,123,t课件,重构用例模型,对于一些复杂的系统，用例可能很多，所以可以利用用例建模高级技术重构用例模型用例关系通过用例关系将复杂的用例进行适当的分解，以便于提

36、高需求的复用性和可扩展性等，从而使用例模型的结构更合理用例分级可以根据用例的重要程度进行分级，以便后续迭代计划的制定，高级别的用例优先考虑用例分包将相关的用例打包，通过分包的方式可以将用例图分层表示，以用于大规模系统的用例建模,124,t课件,用例关系,扩展,包含,泛化,125,t课件,通过关系整理文档,Extend(扩展)通过扩展用例对基用例增加附加的行为Include(包含)基用例中复用被包含用例的行为提取公共步骤，便于复用Generalization(泛化)派生用例继承泛化用例的行为并添加新行为,126,t课件,用例关系：扩展,扩展：某个用例在特定情况下，包含其他用例(扩展用例)的行为，

37、表示功能被扩展扩展使用带有的虚线表示。此时，箭头由扩展的用例指向原用例，通过扩展点指明在原用例中的扩展位置,127,t课件,用例关系：包含,包含：表示某个用例中包含了其他用例的行为包含用带有的虚线来表示。此时，箭头由原有的用例指向被包含部分的用例,128,t课件,扩展 VS. 包含-1,包含：由用例A连向用例B，表示用例A中使用了用例B中的行为或功能包含关系的提出一般是基于用例行为复用的考虑，这也意味着被包含的用例往往被多个基用例引用扩展：由用例B连向用例A，表示用例A描述了一项基本需求，而用例B则描述了该基本需求的特殊情况，即一种扩展扩展用例的提出是为了将基用例的一些特殊情况分离出来，在保持

38、基用例本身相对完整的情况下（即一般情况都能处理）来处理这些特殊行为,129,t课件,用例关系：泛化,泛化：表示子用例继承了父用例用例间的泛化关系表明子用例继承父用例中定义的所有属性、行为序列和扩展点，并且参与父用例中所有的关系,130,t课件,用例分包,对用例进行分包让用例图能够更为清晰地表现出系统的业务逻辑关系和层次对系统进行模块的分割，这将影响到今后的开发和系统的最终表现形式常见的分包方式按参与者分包按主题分包按开发团队分包按发布情况分包,先按主题分包，主题内再按开发团队和发布情况分包,131,t课件,利用分包机制组织用例模型,132,t课件,用例分级,用例和迭代开发迭代开发中开发周期的定

39、义是围绕用例来组织的一个迭代周期要被指派一个到多个用例，如果完全版本的用例在一个迭代周期中处理起来太复杂的话，那就采用简化版本的用例,迭代周期,迭代周期,迭代周期,用例A-简化版本,用例A-完整版本,用例B,用例C,-133-,t课件,用例分级实施策略-1,可以使用一个简单的但是有些不精确的分类方法，如将用例划分成高、中、低三个等级,-134-,t课件,用例分级原则,用例分级的一个基本原则高级别用例是那些对系统核心架构影响最大的用例提高用例级别的特性：a. 对架构设计有重要影响的用例，如在领域层中增加多个类的用例或者需要持久化的用例b. 不需要花费很多努力就可以从中获得重要信息和线索的那些用例

40、c. 含有开发风险、时间紧迫或功能复杂的用例d. 涉及到重要技术研究或者新技术和高风险的用例e. 代表主要的在线业务流程的用例f. 能产生直接经济效益或者降低成本的用例,135,t课件,用例分级实施策略-2,依照上述的影响用例级别的特性给用例打分（特性也可能带有权值）,-136-,t课件,内容安排,从业务模型获取需求建立用例模型编写用例文档重构用例模型其它问题,137,t课件,用例建模中常见的问题,用例不是功能分解用例图不是流程图用例关系的误用,138,t课件,何时适用用例建模,用例是从参与者角度捕获系统功能，当系统只有一个或者没有参与者时，显然不是非常有效的用例捕获功能需求，因此对于系统的非功能需求不是有效当遇到下述情况时，用例是需求捕获的最好选择系统由功能需求所主导系统具有很多类型的用户，系统对他们提供不同的功能系统具有很多接口当遇到下述情况时，用例是一个糟糕的选择：系统由非功能需求所主导（如：google）系统具有很少的用户系统具有很少的接口（非内部功能）如：嵌入式系统、算法复杂但接口少的系统等,139,t课件,