业务建模及用例建模.ppt

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