业务建模及用例建模

面向对象分析与设计

Object-OrientedAnalysis&Design-2-学习路线图OOUMLOOPDP…Case-Study…学习路线图……

……

……

……12345678910核心过程-3-业务建模BusinessModeling-5-开发过程解析业务建模：用软件建模方法描述业务流程；其目标是认识业务本质，该业务本质是后续用例建模的基础用例建模：采用UML用例建模技术描述软件需求，该需求模型将为后续用例分析提供输入用例分析：采用UML用例分析技术分析软件需求，建立软件系统的分析模型架构设计：在系统的全局范围内，以分析模型为基础，设计系统的架构构件设计：根据架构设计的成果，将分析模型细化，设计系统构件的实现细节代码实现：将系统构件映射到目标语言上-6-业务业务是指某个组织或者组织单元业务可以看作一种包含了人、机器、资源的“系统”利用软件思想(用例思想、对象思想)描述业务的过程，就是业务建模业务建模只是辅助环节不是所有项目都需要也不一定和软件开发相关-7-业务建模业务建模的目的理解将要实施的系统的组织结构和动态特性理解当前在目标组织中的问题，并明确改进的潜力确保客户、最终用户和开发人员对目标组织有统一的理解获取用于支持目标组织的系统需求业务建模关注机构的核心价值机构的边界机构的参与者机构中的工作流及如何优化-8-业务建模方法研究对象软件要改进的业务单元研究目标定义业务本质研究方法用例观点：把业务看成对外提供价值的价值流-9-业务建模工件业务用例模型(BusinessUse-CaseModel)业务用户表示为业务参与者(BusinessActor)业务过程表示为业务用例(BusinessUse-Case)和业务用例实现业务对象模型(BusinessObjectModel)人们在组织中扮演的角色表示为业务工人(BusinessWorker)组织管理或制造的“东西”表示为业务实体(BusinessEntity)-10-业务建模流程0.建立业务用例模型1.识别业务参与者2.识别业务用例3.详述业务用例4.建立业务对象模型-11-业务务建建模模流流程程0.建立立业务务用用例例模模型型1.识别别业业务务参参与与者者2.识别别业业务务用用例例3.详述述业业务务用用例例1.建立立业务务对对象象模模型型-12-1.业务务参参与与者者(BusinessActor)识别别业业务务参参与与者者在业务务之之外外，与与业业务务进进行行交互互的人人或或组组织织-13-区分分业业务务工工人人(BusinessWorker)业务务参参与与者者在在业业务务外外面面业务务工工人人在在业业务务里里面面-14-区分分业业务务实实体体(BusinessEntity)-15-识别别业业务务参参与与者者思思路路客户户供应应商商合作作伙伙伴伴潜在在客客户户政府府组织织中中未未建建模模部部分分………-16-2.业务务用用例例(BusinessUseCase)识别别业业务务用用例例业务务为为业业务务参参与与者者提提供供的的价值值体现现企企业业业业务务本本质质，，是是有意意义义的目目标标-17-业务务用用例例与与业业务务参参与与者者-18-识别别业业务务用用例例的的方方法法直接接获获得得：：从从业业务务参参与与者者的的角角度度，，从从外外部部推推导导出出来来拼装装：：从从里里面面往往外外面面看看，，内内部部业业务务流流程程的的目目标标是是什什么么直接接获获得得拼装装-19-从业业务务流流程程拼拼装装业业务务用用例例业务务流流程程1.收款款人人在在支支票票背背后后签签名名，，写写上上身身份份证证件件号号码码，，把把支支票票和和身身份份证证件件交交给给营营业业员员2.营业业员员核核对对印印章章正正确确且且证证件件有有效效3.营业业员员操操作作营营业业受受理理系系统统，，办办理理支支票票兑兑现现手手续续4.营业业员员把把现现金金和和证证件件交交给给交交款款人人-20-识别别业业务务用用例例-支支持持性性事事件件不要要遗遗漏漏支支撑撑性性业业务务流流程程背背后后的的业业务务用用例例支持持性性事事件件人员员的的发发展展与与维维护护业务务内内部部IT的开开发发与与维维护护办公公室室的的设设立立与与维维护护安全全性性法律律活活动动例：：公公司司为为什什么么要要举举行行足足球球比比赛赛？？-21-3.详述述业务用用例业务用例例是对业业务流程程的封装装，在业业务建模模过程中中需要逐逐一描述述其内部部细节，，即详述述业务用用例目的详细说明明业务用用例的工工作流程程说明业务务用例的的工作流流程，以以便于客客户、用用户和涉涉众理解解-22-三种可选选技术文字活动图顺序图-23-选择合适适的技术术只有文字字不生动，，不便于于和客户户交流只有活动动图难以表达达所有细细节业务用例例文档中中插入活活动图活动图中中插入文文字(+注释+基本路径径)顺序图(需要涉及及到业务务对象模模型)-24-细说活动动图-25-细说活动动图(1)起点、终终点活动的一一种特殊殊形式，，各自只只有一个个起点：只只有离开开的转移移终点：只只有进入入的转移移存在从起起点出发发，到达达终点的的路径活动和动动作有进有出出动宾结构构可以简单单，可以以复杂分区定义活动动的负责责者-26-细说活动动图(2)控制流向外转移移的条件件之和必必须是完完备集向外转移移的条件件之间不不能重叠叠决策点注意和流流程图的的区别误把活动动当决策策图中判断断“技术术可行性”需需要单独独的活动来完完成-27-细说活动动图(3)并发(concurrent)同步条(synchronizationbar)的分叉(fork)与合并(join)有分必有有合有分必有有进有合必有有出并发≠同时-28-活动图中中的对象象流指定活动动操作的的数据(对象)以及数据据的流向向(对象流)业务对象象(businessobjects)、对象流流(objectflows)指出对某某些业务务实体的的操作，，类似结结构化中中的数据据流图UML2中对象流流

由原原来的虚虚线改改为实线线-29-活动图的的分层活动可以以简单可可以复杂杂，复杂杂的活动动可以进进一步细细化：分分层顶层有起起点终点点，下层层可以没没有出入平衡衡-30-4.业务务对象模模型业务对象象模型(BusinessObjectModel)勾勒出实实现业务务关系中中的人、、事物、、设备、、资源以以及它们们之间的的关系；；即业务务工人和和业务实实体之间间的静态态关系从另一个个视角描描述现实实使用UML类图描述述不要和待待开发系系统中的的分析设设计类相相混淆-31-餐馆的业业务对象象模型-32-业务建模模实践：：建模指指南业务模型型不是UML标准直接接支持的的，但是是通过UML的扩展机机制可以以很方便便的建立立业务模模型主要构造造型(stereotype)业务用例例模型参与者的的构造型型：业务务参与者者(BusinessActor)用例的构构造型：：业务用用例(BusinessUseCase)业务对象象模型类的构造造型：业业务工人人(BusinessWorker)、业务实实体(BusinessEntity)-33-建模指南南：模型型的组织织利用“包包”组织织模型用例视图图中“业务用用例模型型”每个业务务用例的的”状态/活动模型型”逻辑视图图中“业务对对象模型型”-34-建模指南南：使用用构造型型业务用例例模型是是在UML的用例模模型(用例图)基础上添添加构造造型来实实现的业务对象象模型是是在UML的对象模模型(类图)基础上添添加构造造型来实实现的利用已有有元素添添加构造造型Rose直接支持持这些构构造型-35-业务建模模实践：：实例分分析研究对象象：某旅旅店业务现状状：某旅店可可对外开开放50个双人间间和20个单人间间，房间间费用视视情况按按季节调调整，但但周一到到周五提提供半价价（周末末全价））折扣旅客可以以直接入入住房间间(如果有空空房)，也可提提前预订订；入住住和预订订都需要要登记个个人信息息旅客提前前预订房房间时，，需提交交一定的的订金；；入住时时间24小时之外外的旅客客可以取取消预订订，并退退回所有有订金，，24小时以内内则不退退还订金金退房时缴缴纳全部部的住宿宿费用服务员每每月为经经理提供供房间的的预订情情况和入入住情况况的详细细信息-36-实例分分析：：业务务用例例模型型旅店的的本质质就是是为旅旅客提提供住住宿服服务，，其它它的只只是为为达到到这个个目标标而采采用的的手段段(用例观观点：：把业业务看看成对对外提提供价价值的的价值值流)-37-实例分分析：：旅客客住宿宿业务务流程程-38-实例分分析：：检查查业务务用例例模型型该业务务用例例模型型体现现了整整个旅旅店的的业务务需求求吗？？如何考考虑这这项业业务：：服务务员每每月为为经理理提供供房间间的预预订情情况和和入住住情况况的详详细信信息？？经理是是什么么，如如何体体现在在业务务建模模过程程中？？是业务务参与与者还还是业业务工工人？？体现现怎样样的业业务本本质的的差异异？-39-实例分分析：：业务务对象象模型型-40-从业务务模型型到系系统模模型对于软软件开开发而而言，，业务务建模模只是是辅助助环节节，并并不是是最终终目标标软件工工程师师最终终目标标是要要构造造软件件系统统业务建建模则则是一一种定定义系系统模模型的的辅助助手段段从业务务模型型到系系统模模型业务模模型描描述了了目前前的业业务现现状系统模模型才才是软软件开开发的的最终终工件件-41-业务模模型为为系统统模型型提供供素材材为用例例视图图和逻逻辑视视图提提供输输入对于每每个将将被系系统实实现的的业务务用例例，在在用例例视图图中确确定一一个系系统用用例或或用例例包（（或单单独的的子系系统））来实实现该该业务务为需要要支持持自动动化业业务确确定相相应的的用例例对于业业务对对象模模型中中的业业务实实体，，可以以在系系统模模型中中定义义对应应的实实体类类为系统统构架架提供供一些些重要要的构构架机机制在软件件构架架中定定义专专用层层来实实现复复杂的的业务务逻辑辑-42-业务模模型映映射到到系统统模型型从业务改改进点点入手，，结合合系统统远景，可以以帮助助获取取系统统模型型可能的的对应应关系系(并非一一一对对应)业务用用例系统(子系统统)业务参参与者者系统参参与者者业务工工人系统参参与者者业务工工人的的操作作(活动)系统用用例业务实实体实体类类用例建建模UseCaseModeling-44-内容安安排理解需需求从业务务模型型获取取需求求建立用用例模模型编写用用例文文档重构用用例模模型其它问问题-45-内容安安排理解需需求从业务务模型型获取取需求求建立用用例模模型编写用用例文文档重构用用例模模型其它问问题-46-需求——建造造“正正确””的系系统需求：：客户户可接接受的的、系系统必必须满满足的的条件件或具具备的的能力力RUP中的FURPS+软件质质量准准则功能性性（Functionality）使用性性（Usability）可靠性性（Reliability）性能（（Performance）可支持持性（（Supportability）+非功能能性需需求需求工工程的的主要要活动动定义需需求理解用用户的的需要要，建建立用用户可可理解解的系系统需需求模模型分分析需需求根据需需求模模型，，建立立开发发者无无二义义性解解释的的分析析模型型需求管管理-47--48-需求难难在何何处：：石头头问题题我要一一块石石头……差不多多，但但我要要小一一点的的…很好，，不过过我要要蓝色色的……啊，没没有那那么小小…咳，还还是原原来那那个好好了……小一点点的蓝蓝色大大理石石难捕获获，易易变！！-49-需求：：也需需要开开发客户/用户的的要求求/想法/期望软件设设计软件产产品开发编码和和测试试验收有价值值的软软件件需求求分析和和设计计-50-需求问题：：对策难捕获易变从用户视角角看问题合理的结构构用例-51-内容安排理解需求从业务模型型获取需求求用例建模流流程获取原始需需求构建初始用用例模型编写用例文文档重构用例模模型-52-从业务模型型获取需求求有业务模型型从业务用例例模型中寻寻找系统改改进点结合系统远景，获取系统统用例来表表达需求采用需求启启发技术，，从涉众获获得-53-从业务模型型获取需求求从业务用例例模型中获获取系统需需求，来构构建系统用用例模型1.寻找业务改改进点2.定义项目远远景3.导出系统需需求-54-1.业务务改进点业务模型描描述业务现现状，这些些现状：有些可能一一直运转的的很好，不不需要改进进，也就没没有必要作作为软件需需求来由系系统实现而另外可能能更多的业业务在运转转过程中存存在这样或或那样的问问题，这些些问题就成成为业务待待改进的改改进点，也也就很可能能作为软件件需求而存存在-55-寻找业务改改进点从业务流程程中获取改改进点的思思路：信息的自动动流转演绎复杂业业务逻辑访问和操作作业务对象象自动工作……-56-2.远景景(Vision)系统改进点点不等同于于软件需求求用户根据自自身的工作作特点和支支付能力决决定哪些应应该改进，，哪些不需需要改进这就是用户户的远景，，它表明用用户改进的的目标，这这也将成为为项目的目目标业务模型描描述了“现现实是什么么”，远景景则描述““希望的改改进”远景表达了了“为什么么要开发这这个系统””在业务现状状(业务模型)下，开发系系统是为了了达到什么么目标？-57-定义项目远远景远景包含了了对待开发发系统的目目标和约束束代表了项目目涉及的所所有人之间间达成的第第一个共识识是项目核心心需求的概概览为更详细的的技术需求求提供了契契约性的依依据指导团队实实现具体的的业务目标标远景的作用用最初，根据据项目的远远景目标来来决定项目目是否值得得继续在项目批准准后，团队队根据项目目远景来指指导后续的的需求和设设计-58-远景说明远景可以作作为一个单单独的文档档存在，而而这其中最最重要的部部分就是关关于远景目目标的说明明，它建立立了一个项项目涉及的的所有人的的共同目标标远景说明应应该是精确确、清晰和和激励性的的描述，以以便激励所所有的团队队成员为达达成该远景景而努力。。一个好的的远景应该该具有以下下五个特点点(SMART)：具体的（Specific）可测量的（（Measurable）可实现的（（Achievable）相关的（Relevant）基于时间的的（Time-based）-59-3.导出出系统需求求从业务改进进点入手，，结合项目目远景，导导出系统需需求：对于每一个个业务改进进点，明确确是否是为为了达到远远景目标的的需要如果是则作作为软件需需求而存在在，并把相相应地模型型作为系统统模型如果不是则则不作为需需求而存在在，可能作作为一项潜潜在的需求求考虑，也也可能直接接抛弃-60-实例分析：：旅店系统统开发背景景随着旅店声声誉日益提提高，住宿宿人员越来来越多，旅旅客为了能能够获得好好的房间，，均提前预预订房间然而，随着着预订的增增多、预订订周期的拉拉长，前台台服务员工工作压力也也日益增大大，还经常常出现工作作的失误，，使得已经经预订好房房间的旅客客也不能按按期入住，，这给酒店店的声誉带带来不好的的影响为此，旅店店老板想到到了计算机机，希望能能够通过计计算机来自自动管理这这些预订业业务，不过过由于目前前资金的问问题，目前前只开发一一个单机版版的系统，，不提供网网上业务；；并且旅店店方面的其其它业务暂暂不考虑信信息化问题题旅店老板委委托某计算算机公司开开发该系统统，并承诺诺如果系统统运转良好好的话，将将会考虑进进一步合作作事宜-61-远景：旅店店预订系统统A很荣幸地成成为项目经经理，并被被要求在两两个月之内内发布该系系统的第一一个版本，，同时还被被要求要为为后续的开开发提供必必备的接口口结合现状和和老板的要要求，考虑虑到的项目目可扩展的的要求，A首先进行了了简单的业业务建模之后，A初步定义了了项目的远远景方便、快捷捷、准确地地为旅客预预订房间旅客可以方方便的取消消预订的房房间旅店经理能能够定期的的获取预订订的信息，，根据这些些信息可以以及时调整整房间的价价格及时、快速速地计算房房间费用、、预订费用用、取消预预订后退款款金额等信信息?预留接口：：可以为以以后的网络络版，以及及其它业务务系统的开开发提供支支持-62-结合远景，，获取系统统需求-63-业务模型映映射到系统统模型思路路从业务改进点点入手，结合合系统远景，可以帮助助获取系统统模型可能的对应应关系(并非一一对对应)业务用例系统(子系统)业务参与者者系统参与者者业务工人系统参与者者业务工人的的操作(活动)系统用例业务实体实体类-64-内容安排理解需求从业务模型型获取需求求建立用例模模型编写用例文文档重构用例模模型其它问题-65-1.需求从从何而来需求只能来来自涉众(stakeholders)最终用户、、客户政府、法律律、文化开发人员、、管理人员员竞争对手…但并不是直直接从涉众众中来你们的需求求是什么？？-66-涉众无法直直接提供需需求涉众无法陈陈述自己的的需要涉众说的是是解决方案案而不是需需求涉众难以构构想新的工工作方法涉众的利益益矛盾涉众抵制变变更“最好也要要有”—过过度的要求求需求引发需需求-67-需求启发技技术需求工程师师利用需求求启发技术术，从涉众众中发掘需需求收集资料现场观察访谈开会原型问卷调查…-68-2识别参参与者(Actor)识别参与者者关键词：边界参与者：在在系统之外，透过系统边界与系统进行行有意义交互互的任何事物-69-参与者要点点分析系统外参与者不是是系统的一一部分，处处于系统的的外部系统边界参与者透过过系统边界界直接与系统交互互，参与者者的确定代代表系统边界的确定系统角色参与者与使使用系统的的物理人和和职务没有有关系需要从参与与系统的角角色(作用)来寻找参与与者与系统进行行信息交互互系统需要关关注其交互互过程，即即系统职责责任何事物人、外系统统、外部因因素、时间间-70-要点：与系系统进行信信息交互-71-要点：任何何事物-72-任何事物：：小人与圣圣小猪-1-73-小人与圣小小猪-2众所周知，，用例图中中的参与者者用一个小小人表示。。但是这个个小人具有有一定的误误导性，往往往让初学学者(包括客户)理解为一个个真实的人人。大多数数UML学习者都要要花好长一一段时间来来搞明白小小人其实不不一定代表表的是人，，而是很抽抽象的系统统不可控的的外部因素素，比如说说另一个系系统。那么么为什么不不干脆用其其它的符号号来表示参参与者呢？？如果我开发发一个猪圈圈自动供食食供水系统统，猪的前前蹄触发一一个开关系系统就供食食或供水。。显然，这这里的参与与者是小小猪。那么么在用例图图里用小猪猪代替原来来的小人不不是更易于于交流吗？？-74-思考：参与与者与系统统边界？某企业要求求开发一个个企业信息息管理系统统，并与原原来已有的的库存系统统相连接某企业要求求开发一个个企业信息息管理系统统，并把原原来已有的的库存管理理系统加以以改造，成成为企业信信息管理系系统的一部部分-75-识别参与者者的思路可以从以下下要点来识识别参与者者系统在哪些些部门使用用谁向系统提提供信息、、使用和删删除信息。。谁与系统的的需求有关关联谁使用系统统的功能（（用例）谁对系统进进行维护与外部系统统是否有关关联时间参与者者：一种习习惯用法，，用于激活活那些系统统定期的、、自动执行行的用例-76-参与者的命命名对参与者赋赋予能更好好地表达其其角色(作用)的名称不好的参与与者命名的的例子：用用职务名称称和个人姓姓名来命名名例如，张三三、老李、、校长、科科长…若使用系统统的人（职职务名称））变化的话话，就不是是参与者了了好的参与者者命名的例例子：用能能知道其角角色的名称称来命名例如，学生生、订单管管理员、维维护部门…即使使用系系统的人改改变，从系系统来看，，使用者的的角色（作作用）是相相同的。-77-参与者之间间的关系：：泛化参与者可以以通过泛化关系来定义，在在这种泛化化关系中，，一个参与与者的抽象象描述可以以被一个或或多个具体体的参与者者所共享如系统中经经理可以参参加雇员的的所有用例例-78-参与者地位位识别用例之之前—重要有助于识别别用例，宁宁多勿少开始书写用用例文档以以后—不重要涉及的参与与者太多测试和部署署阶段—重要需要从参与与者的角度度考虑-79-3识别用用例关键词：价价值定义用例实例是是系统执行的一系列动作作，这些动作作将生成特特定参与者可观观测的结果值一个用例定定义一组用例实实例（场景景）简洁：参与与者使用系统达到某个目目标-80-用例要点可观测→用例止于系系统边界结果值→用例是有意意义的目标标系统执行→结果值由系系统生成由参与者观观测→业务语言、、用户观点点一组用例实实例→用例的粒度度-81-要点：有意意义的目标标-82-要点：结果果值由系统统生成系统需要处处理的，由由系统生成成-83-要点：用户户观点而非非系统观点点用户观点系统观点-84-用例的命名名参与者视角角：（状语）动动词+（定语+）宾语-85-要点：用例例粒度-1用例是一组组用例实例例的抽象；；其内部要要有路径，，路径要有有步骤最常犯错误误：粒度过过细，陷入入功能分解解通过执行用用例，参与与者完成想想做的事情情(最终的目的的)，并为参与与者产生价价值过细的粒度度，一般都都会导致技技术语言的的描述，而而不再是业业务语言-86-用例粒度-2把步骤当用例例把系统活动当当用例-87-用例粒度-3“四轮马车””C(Create)R(Read)

U(Update)

D(Delete)所有业务最终终对会成为CRUD？CRUD能为Actor提供价值？CRUD掩盖业务，锐变成关系数数据库的建模模：“系统就是数数据的增删改改查”关心数据的存存储和维护，，反而忽略了了用户的目的的-88-用例粒度-4如果确实是CRUD？如果CRUD不涉及复杂的的交互，一个个用例“管理理××”即可不管是C、R、U、D，都是为了完完成“管理””目标甚至很多种的的基本数据管管理都可以用用一个用例表表示-89-用例粒度-5灵活处理CRUD可以把包含复复杂交互的路路径独立出去去形成用例-90-找出用例的思思路用例要考虑如如下要点来寻寻找。参与者的工作作是什么参与者的角色色(作用)是什么参与者是否生生成、参照、、删除系统信信息参与者是否需需要把外部变变更通知给系系统系统是否需要要把内部事情情通知给参与与者是否存在进行行系统维护的的用例用例数量的参参考基准1个系统中存在在十几个用例例(或更少)1个用例中有多多个用例实例例(场景)-91-UML2.4中的常见的的14种图UML2.4-图Diagrams类图ClassDiagrams对象图ObjectDiagrams构件图ComponentDiagrams部署图DeploymentDiagrams用例图UseCaseDiagrams顺序图SequenceDiagrams通信图CommunicationDiagrams状态机图StateMachineDiagrams活动图ActivityDiagrams静态模型(系统结构)动态模型(系统行为)包图PackageDiagrams组合结构图CompositeStructureDiagrams时间图TimingDiagrams交互纵览图InteractionOverviewDiagrams外廓图ProfileDiagrams画用例图的基基本元素附录2-1.UML元元语-94-用例图元语返回用例图-95-活动图元语返回活动图-96-类图、对象图图、包图元语语返回静态结构构图组合结构图元元语-97-返回组合结构构图-98-顺序图元语返回顺序图-99-通信图元语返回通信图-100-交互纵览图元元语返回交互纵览览图时间图元语-101-返回时间图-102-状态机图元语语返回状态机图图-103-构件图元语返回构件图-104-部署图元语返回部署图-105-外廓图返回外廓图-106-4构建用例例图用例图：表达达参与者与用用例关系图形形-107-内容安排从业务模型获获取需求建立用例模型型编写用例文档档重构用例模型型其它问题-108-撰写用例文档档用例文档：更更进一步的精精度需求规格说明明书的核心，，而用例图作作为用例文档档的索引图进一步的精度度：有层次的文档文档中每一句句话都有其价价值用例图是骨架架，而用例文文档则是其内内在的肉-109-用例文档的组组成用例标识(UC)、名称、描述述涉及的参与者者、涉及的用用例涉众利益前置条件、后后置条件事件流基本路径备选路径补充约束字段列表、业业务规则非功能需求、、设计约束待解决问题相关图(用例图、活动动图、类图)用例文档参考考模板用例名用例名称，与用例图中的名称保持一致简要描述用简单的几句话说明用例本身以及使用它的原因参与者与该用例相关的参与者，应与用例图保持一致涉众与该用例相关的其他用户或部门，该用例的执行会对这些用户产生影响相关用例与该用例存在关系的用例，对于不同的关系可采用不同的表示方式前置条件执行该用例之前必须满足的条件后置条件在该用例执行之后，系统所达到的状态基本事件流描述用例在最通常情况下所发生的事件流的执行步骤，采用编号的方式表示发生的先后顺序；对于复杂的事件流还可以采用子流的方式分解为多个事件流进行表述备选事件流描述用例基本流程可能出现的分支事件或异常事件补充约束描述与该用例相关的约束，包括数据需求、业务规则、非功能需求、设计约束等待解决问题说明该用例日前还未明确的相关问题相关图与该用例相关的其他图形，可以是标准的UML图，如活动图、类图等，也可以是其他格式的图形。-111-寻找涉众的思思路区分涉众与参参与者涉众是与当前前用例存在利利益关系的人人或组织参与者是启动动或参与用例例执行过程的的人或外部事事物可能的涉众有有：当事人上游下游操作对象的主主人…-112-前置、后置条条件前置条件约束束在用例开始始前系统的状状态作为用例的入入口限制，它它阻止参与者者触发该用例例直到满足所所有条件说明在用例触触发之前什么么必须为真后置条件约束束用例执行后后系统的状态态用例执行后什什么必须为真真对于存在各种种分支事件流流的用例，则则可以指定多多个后置条件件把用例看作是是参与者与系系统交互的流流程，前置条条件和后置条条件则是这个个流程的入口口和出口状态态。如图直线箭头表示示基本事件流流，曲线箭头头代表各种备备选事件流，，注意前置条条件和后置条条件所处位置置-113-定义前置、后后置条件前置、后置条条件必须是系系统能检测到到的前置条件必须须是系统在用用例开始前就就能检测到的的-114-应用前置、后后置条件某些用例依赖赖于其他用例例一个用例在离离开系统时，，可能是另一一个用例的前前置条件（例例如：“登录录”和“管理理系统”）有助于识别漏漏掉的用例如果一个用例例的前置条件件不能有执行行其他用例满满足，可能意意味着丢失了了用例（例如如：“管理订订单”却没有有“登录”用用例）-115-事件流描述-用例交互四四部曲1.动作4.响应2.验证3.处理系统重点写：1和4（可观测的、、体现客户利利益的文字））用例的核心内内容就是参与与者和系统交交互的过程，，这个交互过过程在用例文文档中采用事事件流的方式式进行完整的的表示。如图图-116-事件流描述要要点事件件流流描描述述要要使使用用户户和和开开发发人人员员互互相相理理解解用用例例的的功功能能，，要要注注意意以以下下几几点点：：使用用业业务务语语言言：：使使用用用用户户平平时时所所使使用用的的语语言言进进行行描描述述要明明确确参参与与者者与与系系统统所所交交互互的的信信息息不使使用用[例如如]、[等]这样样的的不不清清晰晰的的表表达达不要要过过多多地地考考虑虑界界面面细细节节不要要描描述述计计算算机机内内部部的的处处理理，，要要描描述述从从系系统统外外部部所所看看到到的的活活动动除了了基基本本流流程程，，还还要要描描述述替替代代流流程程要明明确确描描述述用用例例的的开开始始和和结结束束-117-例1：：使使用用业业务务语语言言技术术语语言言：：无无法法与与用用户户沟沟通通系统统通通过过JDBC建立立数数据据库库连连接接，，传传送送SQL查询询语语句句，，从从““商商品品表表””查查询询商商品品的的详详细细信信息息…业务务语语言言(用户户语语言言)系统统按按照照查查询询条条件件搜搜索索商商品品的的详详细细信信息息-118-例2：描描述述参参与与者者与与系系统统交交互互过过程程以参与与者者或系系统统作作为为主主语语描描述述参与与者者………系统统………示例例出纳纳员员接接收收顾顾客客的的付付款款—顾客客的的付付款款数数可可能能高高于于商商品品总总额额出纳纳员员录录入入顾顾客客所所付付的的现现金金总总额额系统统显显示示出出应应找找还还给给顾顾客客的的余余额额，，打打印印付付款款收收据据-119-例3：不不细细化化界界面面细细节节过细细的的界面面细细节节描述述会员员从从下下拉拉框框中中选选择择类类别别会员员在在相相应应文文本本框框中中输输入入查查询询条条件件会员员点点击击““确确定定””按按钮钮-120-例4：：分分支支和和循循环环的的描描述述分支支：：放放到到备备选选路路径径中中参与与者者的的选选择择另一一条条成成功功线线路路系统统进进行行验验证证………循环环：：直直接接描描述述-121-用例例文文档档中中的的补补充充约约束束用例例重重点点在在于于描描述述功功能能需需求求，，而而其其它它方方面面的的补补充充约约束束采采用用两两种种处处理理策策略略：：与特特定定用用例例相相关关的的补补充充约约束束，，作作为为该该用用例例文文档档中中一一部部分分来来描描述述一些些全全局局性性的的补补充充约约束束，，单单独独形形成成一一份份独独立立的的文文档档，，如如““补补充充需需求求规规约约””文文档档补充充约约束束字段段列列表表业务务规规则则非功功能能需需求求设计计约约束束-122-实例例分分析析：：撰撰写写用用例例文文档档用例例文文档档参参考考模模板板旅店店预预订订系系统统用用例例文文档档“UC01-预订订房房间间””用用例例文文档档-123-内容容安安排排从业务模模型获取取需求建立用例例模型编写用例例文档重构用例例模型其它问题题重构用例例模型对于一些些复杂的的系统，，用例可可能很多多，所以以可以利利用用例例建模高高级技术术重构用用例模型型用例关系系通过用例例关系将将复杂的的用例进进行适当当的分解解，以便便于提高高需求的的复用性性和可扩扩展性等等，从而而使用例例模型的的结构更更合理用例分级级可以根据据用例的的重要程程度进行行分级，，以便后后续迭代代计划的的制定，，高级别别的用例例优先考考虑用例分包包将相关的的用例打打包，通通过分包包的方式式可以将将用例图图分层表表示，以以用于大大规模系系统的用用例建模模-124--125-用例关系系<<include>><<extend>>扩展包含泛化-126-通过关系系整理文文档Extend(扩展)通过扩展展用例对对基用例例增加附附加的行行为Include(包含)基用例中中复用被被包含用用例的行行为提取公共共步骤，，便于复复用Generalization(泛化)派生用例例继承泛泛化用例例的行为为并添加加新行为为-127-用例关系系：扩展展扩展：某某个用例例在特定定情况下下，包含含其他用用例(扩展用例例)的行为，，表示功功能被扩扩展扩展使用用带有<<extend>>的虚线表表示。此此时，箭箭头由扩扩展的用用例指向向原用例例，通过过扩展点点指明在在原用例例中的扩扩展位置置-128-用例关系系：包含含包含：表表示某个个用例中中包含了了其他用用例的行行为包含用带带有<<include>>的虚线来来表示。。此时，，箭头由由原有的的用例指指向被包包含部分分的用例例-129-扩展VS.包包含-1包含：由由用例A连向用例例B，表示用用例A中使用了了用例B中的行为为或功能能包含关系系的提出出一般是是基于用用例行为为复用的的考虑，，这也意意味着被被包含的的用例往往往被多多个基用用例引用用扩展：由由用例B连向用例例A，表示用用例A描述了一一项基本本需求，，而用例例B则描述了了该基本本需求的的特殊情情况，即即一种扩扩展扩展用例例的提出出是为了了将基用用例的一一些特殊殊情况分分离出来来，在保保持基用用例本身身相对完完整的情情况下（（即一般般情况都都能处理理）来处处理这些些特殊行行为-130-用例关系系：泛化化泛化：表示子用用例继承承了父用用例用例间的的泛化关关系表明明子用例例继承父父用例中中定义的的所有属属性、行行为序列列和扩展展点，并并且参与与父用例例中所有有的关系系-131-用例分包包对用例进进行分包包让用例图图能够更更为清晰晰地表现现出系统统的业务务逻辑关关系和层层次对系统进进行模块块的分割割，这将将影响到到今后的的开发和和系统的的最终表表现形式式常见的分分包方式式按参与者者分包按主题分分包按开发团团队分包包按发布情情况分包包先按主题题分包，，主题内内再按开开发团队队和发布布情况分分包-132-利用分包包机制组组织用例例模型-133-用例分级级用例和迭迭代开发发迭代开发发中开发发周期的的定义是是围绕用用例来组组织的一个迭代代周期要要被指派派一个到到多个用用例，如如果完全全版本的的用例在在一个迭迭代周期期中处理理起来太太复杂的的话，那那就采用用简化版版本的用用例迭代周期期迭代周期期迭代周期期用例A-简化版本本用例A-完整版本本用例B用例C-134-用例分级级实施策策略-1可以使用用一个简简单的但但是有些些不精确确的分类类方法，，如将用用例划分分成高、、中、低低三个等等级-135-用例分级级原则用例分级级的一个个基本原原则高级别用用例是那那些对系系统核心心架构影影响最大大的用例例提高用例例级别的的特性：：a.对架构设设计有重重要影响响的用例例，如在在领域层层中增加加多个类类的用例例或者需需要持久久化的用用例b.不需要花花费很多多努力就就可以从从中获得得重要信信息和线线索的那那些用例例c.含有开发发风险、、时间紧紧迫或功功能复杂杂的用例例d.涉及到重重要技术术研究或或者新技技术和高高风险的的用例e.代表主要要的在线线业务流流程的用用例f.能产生直直接经济济效益或或者降低低成本的的用例-136-用例分级级实施策策略-2依照上述述的影响响用例级级别的特特性给用用例打分分（特性性也可能能带有权权值）-137-内容安排排从业务模模型获取取需求建立用例例模型编写用例文文档重构用例模模型其它问题用例建模中中常见的问问题用例不是功功能分解用例图不是是流程图用例关系的的误用-138--139-何时适用用用例建模用例是从参参与者角度度捕获系统统功能，当当系统只有有一个或者者没有参与与者时，显显然不是非非常有效的的用例捕获功功能需求，，因此对于于系统的非非功能需求求不是有效效当遇到下述述情况时，，用例是需需求捕获的的最好选择择系统由功能能需求所主主导系统具有很很多类型的的用户，系系统对他们们提供不同同的功能系统具有很很多接口当遇到下述述情况时，，用例是一一个糟糕的的选择：系统由非功功能需求所所主导（如如：google）系统具有很很少的用户户系统具有很很少的接口口（非内部部功能）如：嵌入式式系统、算算法复杂但但接口少的的系统等谢谢1月-2304:03:3904:0304:031月-231月-2304:0304:0304:03:391月-231月-2304:03:392023/1/54:03:399、静静夜夜四四无无邻邻，，荒荒居居旧旧业业贫贫。。。。1月月-231月月-23Thursday,January5,202310、雨中黄黄叶树，，灯下白白头人。。。04:03:3904:03:3904:031/5/20234:03:39A