面向对象第一次作业

1、谭火彬谭火彬Copyright College of Software, BUAA-2-学习路线图学习路线图OOOOUML : : Use Case ModelingCopyright College of Software, BUAA-4-内容安排内容安排理解需求理解需求需求获取需求获取用例建模流程用例建模流程u获取原始需求获取原始需求u构建初始用例模型构建初始用例模型u撰写用例文档撰写用例文档u重构用例模型重构用例模型Copyright College of Software, BUAA-5-内容安排内容安排需求获取需求获取用例建模流程用例建模流程u获取原始需求获取原始需求u构建初始用例模

2、型构建初始用例模型u编写用例文档编写用例文档u重构用例模型重构用例模型Copyright College of Software, BUAA-6-需求需求建造建造“正确正确”的系统的系统需求：系统必须满足的条件和具备的需求：系统必须满足的条件和具备的能力能力RUP中的中的FURPS+软件质量准则软件质量准则u功能性（功能性（Functionality）u使用性（使用性（Usability）u可靠性（可靠性（Reliability）u性能（性能（Performance）u可支持性（可支持性（Supportability）u+Copyright College of Software, BUAA需

3、求工程的主要活动需求工程的主要活动定义需求定义需求u理解用户的需要，建立用户可理解的系理解用户的需要，建立用户可理解的系统需求模型（第四章）统需求模型（第四章）分析需求分析需求u根据需求模型，建立开发者无二义性解根据需求模型，建立开发者无二义性解释的分析模型（第五章）释的分析模型（第五章）需求管理需求管理-7-Copyright College of Software, BUAA-8-需求难在何处：石头问题需求难在何处：石头问题我要一块石头我要一块石头差不多，但我要小一点的差不多，但我要小一点的很好，不过我要蓝色的很好，不过我要蓝色的啊，没有那么小啊，没有那么小咳，还是原来那个好了咳，还是原来

4、那个好了 Copyright College of Software, BUAA-9-需求：也需要开发需求：也需要开发客户客户/用户的要用户的要求求/想法想法/期望期望软件设计软件设计软件产品软件产品开发开发编码和测试编码和测试验收验收有价值的有价值的软件需求软件需求分析和设计分析和设计Copyright College of Software, BUAA-10-需求问题：对策需求问题：对策Copyright College of Software, BUAA-11-以用例为中心组织需求以用例为中心组织需求Copyright College of Software, BUAA-12-用例的昨天

5、用例的昨天Use Cases Yesterday, Today and Tomorrow（Ivar Jacobson, The Rational Edge, 2003.3）u萌芽期（萌芽期（1967-1986）Ivar Jacobson在爱立信，把各种不同类型的电在爱立信，把各种不同类型的电话呼叫情况称为话呼叫情况称为traffic case，而完成所有呼叫，而完成所有呼叫则需要交换机具备相应的功能则需要交换机具备相应的功能function或特征或特征feature1986年，提出术语年，提出术语use case1987年，年，OOPSLA86采用采用Jacobson论文，用论文，用例诞生例诞

6、生u成熟期（成熟期（1987-1992）Objectory AB公司，以用例内容为核心的公司，以用例内容为核心的Objectory Process（对象工厂过程）（对象工厂过程）u发展期（发展期（1992-）用例在面向对象方法中的应用，并成为用例在面向对象方法中的应用，并成为UML的一的一部分部分Copyright College of Software, BUAA-13-内容安排内容安排理解需求理解需求用例建模流程用例建模流程u获取原始需求获取原始需求u构建初始用例模型构建初始用例模型u编写用例文档编写用例文档u重构用例模型重构用例模型Copyright College of Softwar

7、e, BUAA-14-需求获取需求获取有业务模型有业务模型u从业务用例模型中寻找系统改进点从业务用例模型中寻找系统改进点u结合系统结合系统，获取系统用例来表达需，获取系统用例来表达需求求采用需求启发技术，从涉众获得采用需求启发技术，从涉众获得Copyright College of Software, BUAA-15-从业务模型获取需求从业务模型获取需求从业务用例模型中获取系统需求，来从业务用例模型中获取系统需求，来构建系统用例模型构建系统用例模型u1. 寻找业务改进点寻找业务改进点u2. 定义项目远景定义项目远景u3. 导出系统需求导出系统需求Copyright College of Sof

8、tware, BUAA-16-1. 业务改进点业务改进点业务模型描述业务现状，这些现状：业务模型描述业务现状，这些现状：u有些可能一直运转的很好，不需要改进，有些可能一直运转的很好，不需要改进，也就没有必要作为软件需求来由系统实也就没有必要作为软件需求来由系统实现现u而另外可能更多的业务在运转过程中存而另外可能更多的业务在运转过程中存在这样或那样的问题，这些问题就成为在这样或那样的问题，这些问题就成为业务待改进的改进点，也就很可能作为业务待改进的改进点，也就很可能作为软件需求而存在软件需求而存在Copyright College of Software, BUAA-17-寻找业务改进点寻找业务

9、改进点从业务流程中获取改进点的思路：从业务流程中获取改进点的思路：u信息的自动流转信息的自动流转u演绎复杂业务逻辑演绎复杂业务逻辑u访问和操作业务对象访问和操作业务对象u自动工作自动工作uCopyright College of Software, BUAA-18-改进点改进点1：信息自动流转：信息自动流转Copyright College of Software, BUAA-19-改进点改进点2：演绎复杂业务逻辑：演绎复杂业务逻辑Copyright College of Software, BUAA-20-改进点改进点3：访问和操作业务对象：访问和操作业务对象Copyright Colleg

10、e of Software, BUAA-21-改进点改进点4：自动工作：自动工作Copyright College of Software, BUAA-22-2. 远景远景(Vision)系统改进点不等同于软件需求系统改进点不等同于软件需求u用户根据自身的工作特点和支付能力决用户根据自身的工作特点和支付能力决定哪些应该改进，哪些不需要改进定哪些应该改进，哪些不需要改进u这就是用户的远景，它表明用户改进的这就是用户的远景，它表明用户改进的目标，这也将成为项目的目标目标，这也将成为项目的目标业务模型描述了业务模型描述了“现实是什么现实是什么”，远，远景则描述景则描述“希望的改进希望的改进” u远景

11、表达了远景表达了“为什么要开发这个系统为什么要开发这个系统”u在业务现状在业务现状(业务模型业务模型)下，开发系统是下，开发系统是为了达到什么目标？为了达到什么目标？Copyright College of Software, BUAA-23-定义项目远景定义项目远景远景包含了对待开发系统的目标和约束远景包含了对待开发系统的目标和约束u代表了项目涉及的所有人之间达成的第一个代表了项目涉及的所有人之间达成的第一个共识共识u是项目核心需求的概览是项目核心需求的概览u为更详细的技术需求提供了契约性的依据为更详细的技术需求提供了契约性的依据u指导团队实现具体的业务目标指导团队实现具体的业务目标远景的作

12、用远景的作用u最初，根据项目的远景目标来决定项目是否最初，根据项目的远景目标来决定项目是否值得继续值得继续u在项目批准后，团队根据项目远景来指导后在项目批准后，团队根据项目远景来指导后续的需求和设计续的需求和设计Copyright College of Software, BUAA-24-远景说明远景说明远景可以作为一个单独的文档存在，而这其中远景可以作为一个单独的文档存在，而这其中最重要的部分就是关于远景目标的说明，它建最重要的部分就是关于远景目标的说明，它建立了一个项目涉及的所有人的共同目标立了一个项目涉及的所有人的共同目标远景说明应该是精确、清晰和激励性的描述，远景说明应该是精确、清晰和

13、激励性的描述，以便激励所有的团队成员为达成该远景而努力。以便激励所有的团队成员为达成该远景而努力。一个好的远景应该具有以下五个特点一个好的远景应该具有以下五个特点(SMART)：u具体的（具体的（Specific）u可测量的（可测量的（Measurable）u可实现的（可实现的（Achievable）u相关的（相关的（Relevant）u基于时间的（基于时间的（Time-based）Copyright College of Software, BUAA-25-3. 导出系统需求导出系统需求从业务改进点入手，结合项目远景，从业务改进点入手，结合项目远景，导出系统需求：导出系统需求：u对于每一个业

14、务改进点，明确是否是为对于每一个业务改进点，明确是否是为了达到远景目标的需要了达到远景目标的需要u如果是则作为软件需求而存在，并把相如果是则作为软件需求而存在，并把相应地模型作为系统模型应地模型作为系统模型u如果不是则不作为需求而存在，可能作如果不是则不作为需求而存在，可能作为一项潜在的需求考虑，也可能直接抛为一项潜在的需求考虑，也可能直接抛弃弃 Copyright College of Software, BUAA-26-实例分析：旅店系统开发背景实例分析：旅店系统开发背景随着旅店声誉日益提高，住宿人员越来越多，随着旅店声誉日益提高，住宿人员越来越多，旅客为了能够获得好的房间，均提前预订房间

15、旅客为了能够获得好的房间，均提前预订房间然而，随着预订的增多、预订周期的拉长，前然而，随着预订的增多、预订周期的拉长，前台服务员工作压力也日益增大，还经常出现工台服务员工作压力也日益增大，还经常出现工作的失误，使得已经预订好房间的旅客也不能作的失误，使得已经预订好房间的旅客也不能按期入住，这给酒店的声誉带来不好的影响按期入住，这给酒店的声誉带来不好的影响为此，旅店老板想到了计算机，希望能够通过为此，旅店老板想到了计算机，希望能够通过计算机来自动管理这些预订业务，不过由于目计算机来自动管理这些预订业务，不过由于目前资金的问题，目前只开发一个单机版的系统，前资金的问题，目前只开发一个单机版的系统，

16、不提供网上业务；并且旅店方面的其它业务暂不提供网上业务；并且旅店方面的其它业务暂不考虑信息化问题不考虑信息化问题旅店老板委托某计算机公司开发该系统，并承旅店老板委托某计算机公司开发该系统，并承诺如果系统运转良好的话，将会考虑进一步合诺如果系统运转良好的话，将会考虑进一步合作事宜作事宜Copyright College of Software, BUAA-27-远景：旅店预订系统远景：旅店预订系统A很荣幸地成为项目经理，并被要求在两个月之很荣幸地成为项目经理，并被要求在两个月之内发布该系统的第一个版本，同时还被要求要内发布该系统的第一个版本，同时还被要求要为后续的开发提供必备的接口为后续的开发提

17、供必备的接口结合现状和老板的要求，考虑到的项目可扩展结合现状和老板的要求，考虑到的项目可扩展的要求，的要求，A首先进行了简单的业务建模首先进行了简单的业务建模之后，之后，A初步定义了项目的远景初步定义了项目的远景u方便、快捷、准确地为旅客预订房间方便、快捷、准确地为旅客预订房间u旅客可以方便的取消预订的房间旅客可以方便的取消预订的房间u旅店经理能够定期的获取预订的信息，根据这些信旅店经理能够定期的获取预订的信息，根据这些信息可以及时调整房间的价格息可以及时调整房间的价格u及时、快速地计算房间费用、预订费用、取消预订及时、快速地计算房间费用、预订费用、取消预订后退款金额等信息后退款金额等信息u?

18、预留接口：可以为以后的网络版，以及其它业务系预留接口：可以为以后的网络版，以及其它业务系统的开发提供支持统的开发提供支持Copyright College of Software, BUAA-28-结合远景，获取系统需求结合远景，获取系统需求Copyright College of Software, BUAA-29-业务模型映射到系统模型思路业务模型映射到系统模型思路从从入手，结合系统入手，结合系统，可以帮助获取系统模型可以帮助获取系统模型可能的对应关系可能的对应关系(并非一一对应并非一一对应)u业务用例业务用例 系统系统(子系统子系统)u业务参与者业务参与者 系统参与者系统参与者u业务工人

19、业务工人 系统参与者系统参与者u业务工人的操作业务工人的操作(活动活动) 系统用例系统用例u业务实体业务实体 实体类实体类Copyright College of Software, BUAA-30-内容安排内容安排理解需求理解需求需求获取需求获取u获取原始需求获取原始需求u构建初始用例模型构建初始用例模型u撰写用例文档撰写用例文档u重构用例模型重构用例模型Copyright College of Software, BUAA-31-用例建模流程用例建模流程1. 获取原始需求获取原始需求2. 开发一个可以理解的需求开发一个可以理解的需求u2.1 识别参与者识别参与者u2.2 识别用例识别用例u

20、2.3 构建用例图构建用例图3 详细、完整地描述需求详细、完整地描述需求u撰写用例文档撰写用例文档4 重构用例模型重构用例模型u4.1 识别用例间的关系识别用例间的关系u4.2 对用例进行分级和分包对用例进行分级和分包Copyright College of Software, BUAA-32-用例建模流程用例建模流程2. 开发一个可以理解的需求开发一个可以理解的需求u2.1 识别参与者识别参与者u2.2 识别用例识别用例u2.3 构建用例图构建用例图3 详细、完整地描述需求详细、完整地描述需求u撰写用例文档撰写用例文档4 重构用例模型重构用例模型u4.1 识别用例间的关系识别用例间的关系u4

21、.2 对用例进行分级和分包对用例进行分级和分包Copyright College of Software, BUAA-33-1.需求从何而来需求从何而来需求只能来自涉众需求只能来自涉众(stakeholders)u最终用户、客户最终用户、客户u政府、法律、文化政府、法律、文化u开发人员、管理人员开发人员、管理人员u竞争对手竞争对手u但并不是直接从涉众中来但并不是直接从涉众中来u你们的需求是什么？你们的需求是什么？Copyright College of Software, BUAA-34-涉众无法直接提供需求涉众无法直接提供需求涉众无法陈述自己的需要涉众无法陈述自己的需要涉众说的是解决方案而不

22、是需求涉众说的是解决方案而不是需求涉众难以构想新的工作方法涉众难以构想新的工作方法涉众的利益矛盾涉众的利益矛盾涉众抵制变更涉众抵制变更“最好也要有最好也要有”过度的要求过度的要求需求引发需求需求引发需求Copyright College of Software, BUAA-35-需求启发技术需求启发技术需求工程师利用需求启发技术，从涉众中需求工程师利用需求启发技术，从涉众中发掘需求发掘需求u研究文档研究文档u研究竞争对手研究竞争对手u实地观察实地观察u访谈访谈u开会开会u问卷调查问卷调查u原型制作原型制作uCopyright College of Software, BUAA-36-用例建模流

23、程用例建模流程1. 获取原始需求获取原始需求u2.1 识别参与者识别参与者u2.2 识别用例识别用例u2.3 构建用例图构建用例图3 详细、完整地描述需求详细、完整地描述需求u撰写用例文档撰写用例文档4 重构用例模型重构用例模型u4.1 识别用例间的关系识别用例间的关系u4.2 对用例进行分级和分包对用例进行分级和分包Copyright College of Software, BUAA-37-2.1 识别参与者识别参与者(Actor)识别参与者识别参与者u关键词：关键词：边界边界u参与者：在参与者：在系统之外系统之外，透过，透过系统边界系统边界与与系统进行系统进行有意义交互有意义交互的的任何

24、事物任何事物Copyright College of Software, BUAA-38-参与者要点分析参与者要点分析系统外系统外u参与者不是系统的一部分，处于系统的外部参与者不是系统的一部分，处于系统的外部系统边界系统边界u参与者透过系统边界参与者透过系统边界直接直接与系统交互，参与与系统交互，参与者的确定代表者的确定代表系统边界系统边界的确定的确定系统角色系统角色u参与者与使用系统的物理人和职务没有关系参与者与使用系统的物理人和职务没有关系u需要从参与系统的角色需要从参与系统的角色(作用作用)来寻找参与者来寻找参与者与系统进行信息交互与系统进行信息交互u系统需要关注其交互过程，即系统职责系

25、统需要关注其交互过程，即系统职责任何事物任何事物u人、外系统、外部因素、时间人、外系统、外部因素、时间Copyright College of Software, BUAA-39-要点：与系统进行信息交互要点：与系统进行信息交互Copyright College of Software, BUAA-40-要点：任何事物要点：任何事物Copyright College of Software, BUAA-41-任何事物：小人与圣小猪任何事物：小人与圣小猪-1Copyright College of Software, BUAA-42-小人与圣小猪小人与圣小猪-2众所周知，用例图中的参与者用一个小

26、人表示。众所周知，用例图中的参与者用一个小人表示。但是这个小人具有一定的误导性，往往让初学但是这个小人具有一定的误导性，往往让初学者者(包括客户包括客户)理解为一个真实的人。大多数理解为一个真实的人。大多数UML 学习者都要花好长一段时间来搞明白小人学习者都要花好长一段时间来搞明白小人其实不一定代表的是人，而是很抽象的系统不其实不一定代表的是人，而是很抽象的系统不可控的外部因素，比如说另一个系统。那么为可控的外部因素，比如说另一个系统。那么为什么不干脆用其它的符号来表示参与者呢？什么不干脆用其它的符号来表示参与者呢？如果我开发一个猪圈自动供食供水系统，猪的如果我开发一个猪圈自动供食供水系统，猪

27、的前蹄触发一个开关系统就供食或供水。显然，前蹄触发一个开关系统就供食或供水。显然，这里的参与者这里的参与者 是小猪。那么在用例图里用小猪是小猪。那么在用例图里用小猪代替原来的小人不是更易于交流吗？代替原来的小人不是更易于交流吗？Copyright College of Software, BUAA-43-思考：参与者与系统边界？思考：参与者与系统边界？某企业要求开发一个企业信息管理系某企业要求开发一个企业信息管理系统，并与原来已有的库存系统相连接统，并与原来已有的库存系统相连接某企业要求开发一个企业信息管理系某企业要求开发一个企业信息管理系统，并把原来已有的库存管理系统加统，并把原来已有的库存

28、管理系统加以改造，成为企业信息管理系统的一以改造，成为企业信息管理系统的一部分部分Copyright College of Software, BUAA-44-识别参与者的思路识别参与者的思路可以从以下要点来识别参与者可以从以下要点来识别参与者u系统在哪些部门使用系统在哪些部门使用u谁向系统提供信息、使用和删除信息。谁向系统提供信息、使用和删除信息。u谁与系统的需求有关联谁与系统的需求有关联u谁使用系统的功能（用例）谁使用系统的功能（用例）u谁对系统进行维护谁对系统进行维护u与外部系统是否有关联与外部系统是否有关联u时间参与者：一种习惯用法，用于激活时间参与者：一种习惯用法，用于激活那些系统定

29、期的、自动执行的用例那些系统定期的、自动执行的用例Copyright College of Software, BUAA-45-参与者的命名参与者的命名对参与者赋予能更好地表达其角色对参与者赋予能更好地表达其角色(作用作用)的名称的名称u不好的参与者命名的例子：用职务名称和个不好的参与者命名的例子：用职务名称和个人姓名来命名人姓名来命名例如，张三、老李、校长、科长例如，张三、老李、校长、科长若使用系统的人（职务名称）变化的话，就不是若使用系统的人（职务名称）变化的话，就不是参与者了参与者了u好的参与者命名的例子：用能知道其角色的好的参与者命名的例子：用能知道其角色的名称来命名名称来命名例如，学

30、生、订单管理员、维护部门例如，学生、订单管理员、维护部门即使使用系统的人改变，从系统来看，使用者的即使使用系统的人改变，从系统来看，使用者的角色（作用）是相同的。角色（作用）是相同的。Copyright College of Software, BUAA-46-参与者之间的关系：泛化参与者之间的关系：泛化参与者可以通过参与者可以通过来定义，在这种来定义，在这种泛化关系中，一个参泛化关系中，一个参与者的抽象描述可以与者的抽象描述可以被一个或多个具体的被一个或多个具体的参与者所共享参与者所共享u如系统中经理可以参如系统中经理可以参加雇员的所有用例加雇员的所有用例用例A雇员用例B经理用例CCopyr

31、ight College of Software, BUAA-47-参与者地位参与者地位识别用例之前识别用例之前重要重要u有助于识别用例，宁多勿少有助于识别用例，宁多勿少开始书写用例文档以后开始书写用例文档以后不重要不重要u涉及的参与者太多涉及的参与者太多测试和部署阶段测试和部署阶段重要重要u需要从参与者的角度考虑需要从参与者的角度考虑Copyright College of Software, BUAA-48-思考：识别参与者？思考：识别参与者？某短信系统：用户如果预定了天气预某短信系统：用户如果预定了天气预报短信，系统每天定时给他发天气短报短信，系统每天定时给他发天气短信；如果当天气温低于

32、信；如果当天气温低于0度，还要提度，还要提醒用户注意防寒；醒用户注意防寒；Copyright College of Software, BUAA-49-2.2 识别用例识别用例关键词：价值关键词：价值定义定义u用例实例是用例实例是系统执行系统执行的的一系列动作一系列动作，这些动，这些动作将生成特定作将生成特定参与者可观测参与者可观测的的结果值结果值u一个用例定义一个用例定义一组用例实例（场景）一组用例实例（场景）简洁：参与者简洁：参与者使用系统使用系统达到某个目标达到某个目标记住了，我是(系统)记住了，我是(系统)用例用例Copyright College of Software, BUAA-

33、50-用例要点用例要点可观测可观测用例止于系统边界用例止于系统边界结果值结果值用例是有意义的目标用例是有意义的目标系统执行系统执行结果值由系统生成结果值由系统生成由参与者观测由参与者观测业务语言、用户观点业务语言、用户观点一组用例实例一组用例实例用例的粒度用例的粒度Copyright College of Software, BUAA-51-要点：用例止于系统边界要点：用例止于系统边界Copyright College of Software, BUAA-52-要点：有意义的目标要点：有意义的目标?设定查询条件?会员?选择零件?会员?检索零件Copyright College of Softw

34、are, BUAA-53-要点：结果值由系统生成要点：结果值由系统生成出纳员吃饭Copyright College of Software, BUAA-54-要点：业务语言而非技术语言要点：业务语言而非技术语言用户词汇，而不是技术词汇用户词汇，而不是技术词汇u如：发票，商品，洗衣机如：发票，商品，洗衣机u而不是：记录，字段，而不是：记录，字段，COM，C+等等Copyright College of Software, BUAA-55-要点：用户观点而非系统观点要点：用户观点而非系统观点?订票?旅客?查看今日航班?处理订票?旅客?显示今日航班Copyright College of Softw

35、are, BUAA-56-用例用例 VS. 功能功能呼叫某人呼叫某人接听电话接听电话发送短信发送短信记住电话号码记住电话号码传输传输/接收接收电源电源/基站基站输入输出（显示、键盘）输入输出（显示、键盘）电话簿管理电话簿管理Copyright College of Software, BUAA-57-用例的命名用例的命名参与者视角：参与者视角：u（状语）动词（状语）动词+（定语（定语+ ）宾语）宾语顾客购买商品信用卡支付Copyright College of Software, BUAA-58-要点：用例粒度要点：用例粒度-1用例是一组用例实例的抽象；其内部用例是一组用例实例的抽象；其内部要

36、有路径，路径要有步骤要有路径，路径要有步骤最常犯错误：粒度过细，陷入功能分最常犯错误：粒度过细，陷入功能分解解u通过执行用例，参与者完成想做的事情通过执行用例，参与者完成想做的事情(最终的目的最终的目的)，并为参与者产生价值，并为参与者产生价值u过细的粒度，一般都会导致技术语言的过细的粒度，一般都会导致技术语言的描述，而不再是业务语言描述，而不再是业务语言Copyright College of Software, BUAA-59-用例粒度用例粒度-2把步骤当用例把步骤当用例把系统活动当用例把系统活动当用例?会员?输入用户名?验证用户名和密码?会员?登录 查询订单建立数据库连接执行SQL语句C

37、opyright College of Software, BUAA-60-用例粒度用例粒度-3“四轮马车四轮马车”uC(Create)R(Read)U(Update)D(Delete)u所有业务最终对会成为所有业务最终对会成为CRUD？uCRUD能为能为Actor提供价值？提供价值？uCRUD掩盖业务，掩盖业务，锐变成关锐变成关系数据库的建模：系数据库的建模：“系统就是数据的增删改查系统就是数据的增删改查”关心数据的存储和维护，反而关心数据的存储和维护，反而忽略了用户的目的忽略了用户的目的?删除用户?修改用户?增加用户?管理员?查询用户Copyright College of Softwar

38、e, BUAA-61-用例粒度用例粒度-4如果确实是如果确实是CRUD？u如果如果CRUD不涉及复杂的交互，一个用例不涉及复杂的交互，一个用例“管理管理”即可即可u不管是不管是C、R、U、D，都是为了完成，都是为了完成“管理管理”目标目标u甚至很多种的基本数据管理都可以用一个用例表甚至很多种的基本数据管理都可以用一个用例表示示?管理员?管理用户Copyright College of Software, BUAA-62-用例粒度用例粒度-5灵活处理灵活处理CRUD?管理员?管理用户?增加用户 Copyright College of Software, BUAA-63-找出用例的思路找出用例的

39、思路用例要考虑如下要点来寻找。用例要考虑如下要点来寻找。u参与者的工作是什么参与者的工作是什么u参与者的角色参与者的角色(作用作用)是什么是什么u参与者是否生成、参照、删除系统信息参与者是否生成、参照、删除系统信息u参与者是否需要把外部变更通知给系统参与者是否需要把外部变更通知给系统u系统是否需要把内部事情通知给参与者系统是否需要把内部事情通知给参与者u是否存在进行系统维护的用例是否存在进行系统维护的用例用例数量的参考基准用例数量的参考基准u1个系统中存在十几个用例个系统中存在十几个用例(或更少或更少)u1个用例中有多个用例实例个用例中有多个用例实例(场景场景)Copyright Colleg

40、e of Software, BUAA-64-思考：识别用例思考：识别用例-1Email客户端（如：客户端（如：outlook），），A在北在北京发邮件给上海的京发邮件给上海的B，系统提醒，系统提醒B你有你有“新邮件新邮件”，B收邮件收邮件收件人发件人发邮件收邮件邮件系统提醒新邮件Copyright College of Software, BUAA-65-思考：识别用例思考：识别用例-2提醒新邮件发邮件用户收邮件时间Copyright College of Software, BUAA-66-2.3 构建用例图构建用例图用例图：表达参与者与用例关系图形用例图：表达参与者与用例关系图形主要元素

41、主要元素参与者参与者用例用例系统边界系统边界关联关联扩展扩展包含包含泛化泛化注释体注释体注释连接注释连接Copyright College of Software, BUAA-67-实例分析：旅店预订系统实例分析：旅店预订系统Copyright College of Software, BUAA-68-实例分析：旅游业务申请系统实例分析：旅游业务申请系统阅读阅读“旅游业务申请系统旅游业务申请系统”问题陈述问题陈述u识别系统参与者识别系统参与者u识别系统用例识别系统用例u构建用例图构建用例图Copyright College of Software, BUAA获取系统参与者获取系统参与者-69-

42、抽取抽取角度角度外部事物种类外部事物种类主要日常工作主要日常工作使用目标系统职责使用目标系统职责参与者参与者典型典型代表代表相关相关用户用户前台招待顾客前台招待顾客的员工的员工洽谈客户事宜并为客洽谈客户事宜并为客户办理各种申请和取户办理各种申请和取消手续、完成费用支消手续、完成费用支付付办理申请手续以及办理申请手续以及相关的取消、支付相关的取消、支付等后续业务等后续业务前台服务员前台服务员具体具体用户用户代表代表负责催款的员负责催款的员工工打印和邮寄旅游确认打印和邮寄旅游确认书和交款单书和交款单打印旅游确认书和打印旅游确认书和交款单交款单收款员工收款员工旅行社内的会旅行社内的会计人员计人员财务

43、记帐财务记帐不使用本系统，不不使用本系统，不是参与者是参与者宣传和路线管宣传和路线管理员工理员工制作宣传资料、定期制作宣传资料、定期维护旅游路线和活动维护旅游路线和活动维护旅游路线和旅维护旅游路线和旅游活动游活动路线管理员路线管理员其他其他外部外部事物事物财务系统财务系统记帐等财务操作记帐等财务操作接收本系统中与现接收本系统中与现金相关的财务信息金相关的财务信息财务系统财务系统.外部激励外部激励关注或影响系统的运关注或影响系统的运行行定期自动导出财务定期自动导出财务信息信息时间时间Copyright College of Software, BUAA从参与者的角度获取用例从参与者的角度获取用例

44、-70-参与者参与者主要工作主要工作是否使用系统是否使用系统用例用例前台前台服务员服务员向申请人介绍申请情况向申请人介绍申请情况否否为申请人办理申请手续为申请人办理申请手续是是办理申请手续办理申请手续对申请参加人的增、删、改、查对申请参加人的增、删、改、查等日常维护等日常维护是是管理参加者管理参加者记录申请人支付信息记录申请人支付信息是是完成支付完成支付为申请人取消申请为申请人取消申请是是取消申请取消申请收款收款员工员工打印旅游确认书和余额交款单打印旅游确认书和余额交款单是是打印旅游确认书和余额打印旅游确认书和余额交款单交款单邮寄旅游确认书和余额交款单邮寄旅游确认书和余额交款单否否路线路线管理

45、员管理员制作宣传资料制作宣传资料否否设计旅游路线设计旅游路线是是管理路线管理路线设计旅游团（活动）设计旅游团（活动）是是管理旅游团管理旅游团调整旅游团价格调整旅游团价格是是设定价格设定价格财务财务系统系统记账等财务操作记账等财务操作否否接收与现金相关的财务信息接收与现金相关的财务信息是是导出财务信息（被动）导出财务信息（被动）时间时间定期导出财务信息定期导出财务信息是是导出财务信息导出财务信息辅助辅助用例用例系统要区分各种不同的用户身份，系统要区分各种不同的用户身份，并提供不同的功能并提供不同的功能是是登录登录Copyright College of Software, BUAA旅游业务申请系

46、统参考用例图旅游业务申请系统参考用例图-71-Copyright College of Software, BUAA-72-用例建模流程用例建模流程1. 获取原始需求获取原始需求2. 开发一个可以理解的需求开发一个可以理解的需求u2.1 识别参与者识别参与者u2.2 识别用例识别用例u2.3 构建用例图构建用例图u撰写用例文档撰写用例文档4 重构用例模型重构用例模型u4.1 识别用例间的关系识别用例间的关系u4.2 对用例进行分级和分包对用例进行分级和分包Copyright College of Software, BUAA-73-撰写用例文档撰写用例文档用例文档：更进一步的精度用例文档：更进

47、一步的精度u需求规格说明书的核心，而用例图作为需求规格说明书的核心，而用例图作为用例文档的索引图用例文档的索引图u进一步的精度：进一步的精度：文档文档u文档中每一句话都有其价值文档中每一句话都有其价值Copyright College of Software, BUAA-74-有层次的需求组织形式有层次的需求组织形式用例（取款）用例（取款）u路径（正常取款）路径（正常取款）步骤（系统验证取款金额合法）步骤（系统验证取款金额合法）补充约束（取款金额必须为补充约束（取款金额必须为50元的倍数）元的倍数）Copyright College of Software, BUAA-75-谁来写用例文档谁来

48、写用例文档最完美：业务人员接受训练，写出优最完美：业务人员接受训练，写出优美的用例文档美的用例文档最糟糕：业务人员不管，完全由开发最糟糕：业务人员不管，完全由开发人员杜撰人员杜撰Copyright College of Software, BUAA-76-用例文档的组成用例文档的组成用例标识用例标识(UC)、名称、描述、名称、描述涉及的参与者、涉及的用例涉及的参与者、涉及的用例涉众利益涉众利益前置条件、后置条件前置条件、后置条件事件流事件流u基本路径基本路径u备选路径备选路径补充约束补充约束u字段列表、业务规则字段列表、业务规则u非功能需求、设计约束非功能需求、设计约束待解决问题待解决问题相关

49、图相关图(用例图、活动图、类图用例图、活动图、类图)Copyright College of Software, BUAA-77-涉众利益涉众利益同样是同样是“取钱取钱”u为什么家里的抽屉不用密码，取款机要用？为什么家里的抽屉不用密码，取款机要用？u为什么取了钱以后要为什么取了钱以后要“系统扣除帐户金额系统扣除帐户金额”还有一些因素没有考虑还有一些因素没有考虑Copyright College of Software, BUAA-78-从涉众利益角度定义用例从涉众利益角度定义用例Cockburn：用例是：用例是，以参与者为达成特定目标和系，以参与者为达成特定目标和系统交互的方式演绎统交互的方式

50、演绎Copyright College of Software, BUAA-79-用例平衡涉众之间的利益用例平衡涉众之间的利益用例平衡涉众之间的利益用例平衡涉众之间的利益涉众是受系统影响的，有自己主张的涉众是受系统影响的，有自己主张的人或组织，可能的涉众有：人或组织，可能的涉众有：u最终用户、客户、政府、法律最终用户、客户、政府、法律u开发人员、管理人员、竞争对手、开发人员、管理人员、竞争对手、对于用户在对于用户在ATM取钱的用例取钱的用例u用户：希望方便用户：希望方便u银行：希望安全银行：希望安全u法律：保护财产法律：保护财产Copyright College of Software, BU

51、AA-80-涉众利益的冲突涉众利益的冲突用例相当于参与者在台上表演，而最重要的是用例相当于参与者在台上表演，而最重要的是台下的观众台下的观众(涉众涉众)的利益的利益编写用例文档的过程就是描述如何满足涉众之编写用例文档的过程就是描述如何满足涉众之间的利益，达到涉众利益的平衡间的利益，达到涉众利益的平衡涉众有轻重缓急涉众有轻重缓急Copyright College of Software, BUAA-81-寻找涉众的思路寻找涉众的思路区分涉众与参与者区分涉众与参与者u涉众是与当前用例存在利益关系的人或涉众是与当前用例存在利益关系的人或组织组织u参与者是启动或参与用例执行过程的人参与者是启动或参与用

52、例执行过程的人或外部事物或外部事物可能的涉众有：可能的涉众有：u当事人当事人u上游下游上游下游u操作对象的主人操作对象的主人uCopyright College of Software, BUAA-82-前置、后置条件前置、后置条件前置条件约束在用例开前置条件约束在用例开始前系统的状态始前系统的状态u作为用例的入口限制，它作为用例的入口限制，它阻止参与者触发该用例直阻止参与者触发该用例直到满足所有条件到满足所有条件u说明在用例触发之前什么说明在用例触发之前什么必须为真必须为真后置条件约束用例执行后置条件约束用例执行后系统的状态后系统的状态u用例执行后什么必须为真用例执行后什么必须为真u对于存在

53、各种分支事件流对于存在各种分支事件流的用例，则可以指定多个的用例，则可以指定多个后置条件后置条件Copyright College of Software, BUAA-83-定义前置、后置条件定义前置、后置条件前置、后置条件必须是系统能检测到前置、后置条件必须是系统能检测到的的前置条件必须是系统在用例开始前就前置条件必须是系统在用例开始前就能检测到的能检测到的Copyright College of Software, BUAA-84-应用前置、后置条件应用前置、后置条件某些用例依赖于其他用例某些用例依赖于其他用例u一个用例在离开系统时，可能是另一个一个用例在离开系统时，可能是另一个用例的前置

54、条件（例如：用例的前置条件（例如：“登录登录”和和“管理系统管理系统”）有助于识别漏掉的用例有助于识别漏掉的用例u如果一个用例的前置条件不能有执行其如果一个用例的前置条件不能有执行其他用例满足，可能意味着丢失了用例他用例满足，可能意味着丢失了用例（例如：（例如：“管理订单管理订单”却没有却没有“登录登录”用例）用例）Copyright College of Software, BUAA-85-事件流描述事件流描述-用例交互四部曲用例交互四部曲1. 动动 作作4. 回回 应应2.改变改变3.验证验证系系 统统Copyright College of Software, BUAA-86-事件流描述

55、要点事件流描述要点事件流描述要使用户和开发人员互相理解事件流描述要使用户和开发人员互相理解用例的功能，要注意以下几点：用例的功能，要注意以下几点：u使用自然语言：使用用户平时所使用的语言使用自然语言：使用用户平时所使用的语言进行描述进行描述u要明确参与者与系统所交互的信息要明确参与者与系统所交互的信息u不使用不使用例如例如、等等这样的不清晰的表达这样的不清晰的表达u不要细化不要细化GUIu不要描述计算机内部的处理，要描述从系统不要描述计算机内部的处理，要描述从系统外部所看到的活动外部所看到的活动u除了基本流程，还要描述替代流程除了基本流程，还要描述替代流程u要明确描述用例的开始和结束要明确描述

56、用例的开始和结束Copyright College of Software, BUAA-87-例例1：使用自然语言：使用自然语言技术语言：无法与用户沟通技术语言：无法与用户沟通u系统通过系统通过ADO建立数据库连接，传送建立数据库连接，传送SQL查询语句，从查询语句，从“商品表商品表”查询商品查询商品的详细信息的详细信息自然语言自然语言(用户语言用户语言)u系统按照查询条件搜索商品的详细信息系统按照查询条件搜索商品的详细信息Copyright College of Software, BUAA-88-例例2：描述参与者与系统交互过程：描述参与者与系统交互过程以以参与者参与者或系统作为主语描述或

57、系统作为主语描述u参与者参与者u系统系统示例示例u出纳员接收顾客的付款出纳员接收顾客的付款顾客的付款数顾客的付款数可能高于商品总额可能高于商品总额u出纳员录入顾客所付的现金总额出纳员录入顾客所付的现金总额u系统显示出应找还给顾客的余额，打印系统显示出应找还给顾客的余额，打印付款收据付款收据Copyright College of Software, BUAA-89-例例3：不细化：不细化GUI过细的过细的GUI描述描述u会员从下拉框中选择类别会员从下拉框中选择类别u会员在相应文本框中输入查询条件会员在相应文本框中输入查询条件u会员点击会员点击“确定确定”按钮按钮Copyright Colleg

58、e of Software, BUAA-90-例例4：分支和循环的描述：分支和循环的描述分支：放到备选路径中分支：放到备选路径中u参与者的选择参与者的选择u另一条成功线路另一条成功线路u系统进行验证系统进行验证u循环：直接描述循环：直接描述Copyright College of Software, BUAA-91-用例文档中的补充约束用例文档中的补充约束用例重点在于描述功能需求，而其它用例重点在于描述功能需求，而其它方面的补充约束：方面的补充约束：u与特定用例相关的补充约束，作为该用例文与特定用例相关的补充约束，作为该用例文档中一部分来描述档中一部分来描述u一些全局性的补充约束，单独形成一份

59、独立一些全局性的补充约束，单独形成一份独立的文档，如的文档，如“补充需求规约补充需求规约”文档文档补充约束补充约束u字段列表字段列表u业务规则业务规则u非功能需求非功能需求u设计约束设计约束Copyright College of Software, BUAA-92-补充约束：字段列表补充约束：字段列表描述与用例相关的数据需求描述与用例相关的数据需求u不同于数据模型不同于数据模型只是一部分，但可以用只是一部分，但可以用E/R图或业务对象图作为辅助说明图或业务对象图作为辅助说明u不等于数据字典不等于数据字典容易过早把时间花在细节容易过早把时间花在细节上，早期只关注数据本身，不关注实现细节上，早期

60、只关注数据本身，不关注实现细节示例示例(可按数据字典语法，也可简单描述可按数据字典语法，也可简单描述)u注册信息注册信息=用户名用户名+密码密码+email+电话电话*u房间的状态可能有：空闲、已预订、占用房间的状态可能有：空闲、已预订、占用uCopyright College of Software, BUAA-93-补充约束：业务规则补充约束：业务规则描述业务逻辑和操作规则描述业务逻辑和操作规则u事实：设备是资产的一种事实：设备是资产的一种u推理：如果过了计划中的交互日期，货物还推理：如果过了计划中的交互日期，货物还没有送到，即为没有送到，即为“未按时送货未按时送货”u约束：合同总金额不能