2.基于UseCase的需求分析

2020-02-27 57浏览

1.第二讲    基于UseCase的需求分析需求工程基于场景建模案例分析——订单管理系统
2.关于需求工程        理解要求导出需求精化模型协商冲突编写规格说明评审确认需求管理
3.业务需求 from 用户要求
4.业务需求 from 领域知识
5.需求模型基于场景的模型类模型行为模型流模型
6.基于场景建模——用例驱动核心思想：使用用例和场景捕获业务需求，并确保由它们来驱动设计、实现和测试。 • 在分析阶段，使用用例来描述功能需求，并由客户确定这些功能； • 在设计和实现阶段，必须实现用例； • 在测试阶段，由用例对系统进行验证，它们是测试用例的基础。 • 以用例驱动的面向对象开发过程使得用户的任何需求都能够在系统开发链中完整地体现，不仅是需求过程，还包括设计、实现和测试过程。
7.基于场景建模——开发用例  新建初始用例主场景（Primary Scenarious）  细化初始用例主场景（Primary Scenarious）+次场景（Secondary Scenarious ）  编写规范用例         用例主要参与者情景目标前提条件起动场景异常优先级       何时可用使用频率使用方式次要参与者次要参与者的使用方式为解决的问题
8.订单处理系统——初始项目描述初始项目描述：某商业公司拟开发一个购物网站，该网站接受用户登陆和购买商品，提交订单并按要求完成支付后，该商业公司通过快递公司投递商品。
9.风险分析——市场因素分析     竞争对手是谁？竞争点是什么？技术优势？市场优势？业务发展的未来趋势，例如：    更多的国内办公室更多的小公司是否存在以下潜在问题：     不能快速适应市场发展变化项目周期太短，人力资源短缺客户量猛增，处理能力有限响应时间性能令客户失望
10.National Widgets的风险因素      如何在系统出错时防止丢失订单？系统必须易于操作以使得非专业人士可以使用？如果我们不提供Web界面是否会成功？我们应该如何处理公司不同部门的众多实时用户？我们应该如何应付数据库崩溃？有些软件设计人员没有开发经验，特别是缺少团队开发精神。
11.National Widgets的风险因素       如何在系统出错时防止丢失订单？* 系统必须易于操作以使得非专业人士可以使用？*** 如果我们不提供Web界面是否会成功？*** 我们应该如何处理公司不同部门的众多实时用户？** 我们应该如何应付数据库崩溃？* 有些软件设计人员没有开发经验，特别是缺少团队开发精神。 ***
12.确定系统边界  什么是系统边界？ National Widgets公司需要把订购的商品投递给客户。投递过程包括打包和贴标签、称重量，再根据运送方法、邮递速度、保险、重量、目的地等等收取邮资。我们的订单处理系统要包括计算邮费吗？如何计算？
13.确定执行者（IDENTIFYING ACTORS） l l l l l l l l 谁使用这个系统？谁安装系统？谁启动系统？谁维护系统？谁关闭系统？其他哪些系统使用这个系统？谁从这个系统获取信息？谁为这个系统提供信息？ l 是否有相关事件自动在预定的时间发生？
14.确定用例(IDENTIFYING USE CASES) 从执行者的角度看，用例应该是一个完整的任务。一个单独用例的行为经常是在一个相对较短的时间段内完成。如果用例各部分分布在较长时间段内，尤其是它们被不同的执行者来执行，那么建议把每一部分作为一个用例。       考虑以下问题：执行者想要系统有什么样的功能？系统存储信息吗？执行者将要创建、读取、更新、或删除什么样的信息？系统是否需要把自身内部状态的变化通知给执行者？有哪些外部的事件系统必须知道？执行者将怎样通知系统这些事件？
15.订单处理用例图
16.描述执行者和用例确定用例执行者：客户：从National Widgets公司订购商品的人客户代表：National Widgets公司处理客户请求的雇员运输公司：USPS,UPS,DHL,FedEx,DM等等职员：National Widgets公司的雇员，负责包装、贴标签和运送订货。潜在用例执行者：库存系统：记录公司存货的软件记账系统：记录公司账目的软件
17.订单处理用例图
18.订单处理用例描述 1.订购货物(Place Order)—客户提交新商品订单并且为商品付费。 2.获得目录(Get Catalog)—客户要求得到一个目录或产品清单。 3.获得订单的状态(Get Status on Order)—客户得到一个已存在订单的状态。 4.退货(Return Product)—客户退还商品并要求赔偿。 5.取消订单(Cancel Order)—客户取消一个已存在的订单。 6.记录投诉(Register Complain)—客户向公司发送投诉信息。 7.运送包裹(Deliver Packages)—要求运输公司将商品运送到客户手中。 8.计算邮费(Calculate Postage)—计算将商品投递到客户手中需要多少邮费。 9.打印信件标签(Print Mailing Label)—打印信件标签。 10.获得产品信息(Get Product Information)—获得关于商品的信息，关于库存的价钱和质量。 11.更新商品数量(Update Product Quantities)—更新库存的商品数量。 12.接收退订项（Receive Back_ordered Items）—处理退货单。 13.从账号中取钱(Charge Account)—从客户账号取钱。 14.从账号中赊钱(Credit Account)—向客户账号中返钱。
19.订购处理用例包——用例重组如果用例图过于庞大和杂乱将会如何处理？—— 需要创建多个用例图。每一个图可能代表系统中一个主要领域功能。在大型系统中，可以创建包来代表子系统或者主要功能领域。在UML之中，包是其他UML元素的载体。然后为每一个包绘制一张用例图，来表示它所包含的用例。订购货物订购完成
20.订购货物用例图
21.订购完成用例图
22.看一看我们作了哪些工作…… 此时已经确定了一个清晰定义的边界和项目定义范围。还有些事情需要考虑： 是否所有的系统需求都被用例表示出来了？如果不是，确定这些需求已包含在系统需求之内，但无法被执行者看到。 是否所有的执行者和用例都有名称？是否那些需要进一步细化的事物有简短的描述？ 是否定义了系统边界和项目范围？如果不是，这会成为系统的潜在的主要风险。要尽早解决这一问题。 是否所有的未确定部分都列在假设部分了？
23.细化用例
24.订购货物详细用例前置条件：一个合法的客户已经登录到这个系统事件流： 1. 当客户选择订购货物时，用例开始。 2. 客户输入他（她）的姓名和地址。 3. 如果客户只输入邮编，系统将给出州和市区名。 4. 客户输入想要购买的商品代码。 5. 系统为每一项给出商品描述和价格。 6. 系统保存有连续的的已经订购的产品清单。 7. 客户输入信用卡支付信息。 8. 客户选择提交。 9. 系统检验输入的信息，把该订单作为未完成的交易保存，同时向记账系统提供支付信息。如果客户提交的信息不正确，系统就提示客户修改。 10. 当支付被确认后，该订单也被标记上已经确认，同时返回给客户一个订单ID，用例也就结束了; 如果支付没有被确认，系统将提示客户去改正支付信息或者取消。如果客户选择去修改信息，就回到第7步；如果选择取消，用例结束。后置条件：如果订单没有被取消，它将被保存在系统里，并做上标记。
25.包含For结构的详细用例——搜索事件流： 1．当客户选择订购货物时用例开始。 2．客户输入他（她）的姓名和地址。 3．如果客户只输入邮编，系统给出州和市名。 4．开始循环当客户输入产品代码， a）系统给出产品描述和价格。 b）系统往客户订单中添加该物品价格。结束循环 5．客户输入信用卡支付信息。 6．客户选择提交。 7．系统检验输入的信息，把该订单作为未完成的交易保存，同时向帐目系统提供支付信息。如何客户提交的信息不正确，系统就提示客户修改。 8．当支付被确认后，订单被标记上已经确认，同时返回给客户一个订单ID，用例结束。如果支付没有被确认，系统将提示客户去改正支付信息或者取消：如果客户选择去修改信息，就回到第5步；如果选择取消，用例结束。 
26.用例的常用三种表示形式取消订单用例的非正式文本形式  当客户代表接受到一个取消订单的要求时，客户代表在系统中找到该订单，把该定单置取消标记。然后向记账系统发送一个向客户帐号加钱的请求。  取消订单用例的步骤序列 1． 2． 3． 4． 5． 6． 7．当客户代表接收到取消一个订单的请求时，用例开始。客户代表输入一个订单ID。客户代表选搜索。系统显示这个订单的内容。客户代表选择取消。系统将该定单做上取消标志。记账系统收到向客户帐号返钱的通知，用例结束。
27.用例的表格表示（续）客户代表系统记账系统 1．接收到取消订单的请求 2．输入一个订单ID 3．按下搜索 4．显示订单内容 5．选择取消 6．给该订单作取消标记 7．向客户账号中返钱
28.复杂用例处理事件流分为两个部分：基本路径和可选路径。基本路径：描述选择对用例来说是最普通的步骤序列：每一步都假设一切都是正确的，每一步选取最通用的方式。可选路径：给基本用例添加可选项和异常处理。一个找出可选路径的方法就是沿着基本路径一条一条地找，并且考虑： · 在这个点上还可以执行别的活动吗？ · 在这个点上有没有什么可能出错的？ · 有什么随时可能发生的行为吗？
29.基本路径与扩展
30.复杂用例处理——基本路径事件流：基本路径 1．当客户选择订购货物时用例开始。 2．客户输入她（他）的姓名和地址 3．对于每一种输入的产品代码 a）系统显示产品描述和价格 b）系统在该客户的订单中添加这个物品的价格循环结束 4．客户输入信用卡支付信息。 5．客户选择提交。 6．检验输入的信息，把该订单作为未完成的交易保存，同时向记帐系统提供支付信息。 7. 支付被确认后，订单也被标记上已经确认，同时返回给客户一个订单ID，用例结束。
31.复杂用例处理——可选路径事件流：基本路径 1．当客户选择订购货物时用例开始。 2．客户输入她（他）的姓名和地址 3．对于每一种输入的产品代码 a）系统显示产品描述和价格 b）系统在该客户的订单中添加这个物品的价格循环结束 4．客户输入信用卡支付信息。 5．客户选择提交。 6．检验输入信息，把该订单作为未完成交易保存，同时向记帐系统提供支付信息。 7. 支付被确认后，订单标记上已经确认，同时返回给客户一个订单ID，用例结束。可选路径  在选择提交前任何时候，客户都可以选择取消。这次订购不被保存，用例结束。  在第6步，如果接收任何不完整的信息，系统提示客户去修改这些信息。  在第7步，如果支付没有被确认，系统将提示客户去修正支付信息或者取消。  如果客户选择去修正信息，就回到基本路径的第4步；否则用例结束。
32.复杂用例处理——可选路径：简单描述  不完整信息     错误数据  因为错误的密码或者用户名，用户不能登录。        输入的产品代码没有匹配项。产品不能运送错误的付款可选行为  客户通过支票付款   没有付费信息订单不完整运送地址不完整客户通过发邮件订购客户通过电话订购执行者取消操作客户取消这次订购系统崩溃  系统在订购过程中崩溃系统不可用性   系统没有反映，客户不能登录订单丢失
33.高级用例归档技术搜索订单用例 1．当客户键入订单ID、客户ID或者客户名，用例开始。 2．客户选择查找。 3．如果客户键入订单ID a)系统显示订单，然后用例结束 4．如果客户键入一个订单ID a)系统返回当前用户的所有订单表。 b)客户在这个列表中选择一个订单。 c)系统显示了这个订单，然后用例结束。
34.高级用例归档技术——包含取消订单用例 1．客户键入请求取消一个订单，用例开始。 2．包含查找。 3．如果这个订单状态被确认，系统处理取消订单 a) 系统标志订单取消 b) 系统通知记账系统向客户帐号返钱，用例结束。 4．如果订单状态是运送 a) 系统通知National Widgets的退还部门客户，用例结束。
35.查找有包含用例的搜索订单图
36.高级用例归档技术——扩展  扩展一般用于扩展已有用例的行为。这是一种在不改变用例原始功能的情况下增加用例行为的一种方法。例如：使用一段订单处理系统后，National Widgets认为我们需要增加一种功能 ——为老顾客的交易提供折扣，并且保证随时提供顾客选择的商品。
37.订购货物详细用例 扩展点1：销售项前置条件：一个合法的客户已经登录到这个系统 1．系统得到产品的销售折扣信息时，用例开始。事件流： 2．系统在订单处理中显示折扣。 1. 当客户选择订购货物时，用例开始。 3．系统通过把原始价格乘以销售折扣比例来计算折扣数。 2. 客户输入他（她）的姓名和地址。 4. 系统从订购总价格中减去折扣数，用例结束。 3. 如果客户只输入邮编，系统将给出州和市区名。 4. 客户输入想要购买的商品代码。 5. 系统为每一项给出商品描述和价格。 6. 系统保存有连续的的已经订购的产品清单。 7. 客户输入信用卡支付信息。 8. 客户选择提交。 9. 系统检验输入的信息，把该订单作为未完成的交易保存，同时向记账系统提供支付信息。如果客户提交的 扩展点2：特殊顾客信息不正确，系统就提示客户修改。 1．系统得到顾客折扣信息时，用例开始。 10. 当支付被确认后，该订单也被标记上已经确认，同时 2．系统在订单上显示折扣。返回给客户一个订单ID，用例也就结束了; 如果支付没有被确认，系统将提示客户去改正支付信 3．系统通过把订单总价格乘以顾客折扣比例得到折扣总数息或者取消。 4. 系统从订单总价格中减去折扣数，用例结束。如果客户选择去修改信息，就回到第7步；如果选择取消，用例结束。后置条件：如果订单没有被取消，它将被保存在系统里，并做上标记。
38.订购货物带有扩展点的订购货物用例
39.带有扩展用例的订购货物图订购货物《extends》扩展点销售项：第5步前特殊顾客：第8步前《extends》（销售项） [每季度产品销售折扣清单中的产品] 老顾客打折（特殊顾客） [特殊顾客清单中的顾客] 《extends》（销售项，特殊顾客） [调试条件为真] 调试季度销售折扣 扩展点：销售项 打印“检查销售项扩展功能”，进入调试。 扩展点：老顾客打折 打印“检查特殊顾客扩展功能”，进入调试。
40.高级用例归档技术——继承  继承可以在执行者或者用例之间使用。用例之间的继承意味一个用例是另一个用例的特殊的版本。这个特殊的用例从一个通用用例中继承行为或者增加行为。
41.订购货物——电话订购货物   订购货物用例允许客户从National Widgets处订购产品。用例所要求的数据包括用户的支付地址，支付信息和定购的产品列表。客户还可以指定不同于支付地址的送货地址。电话订购货物 1．客户打电话给National Widgets处的客户代表，用例开始。 2．客户代表从客户处得到一个目录ID并把它输入系统。 3．系统从数据库得到用户姓名和地址。 4．客户代表向客户确认以上信息。 5．客户代表从客户处取得产品号并输入系统。 6．对每一个键入的产品号码 a)系统提供一个产品描述和价格 b)系统把物品价格加入到客户订单中循环结束 7. 客户代表从客户处得到支付信息并输入系统。 8. 客户代表向系统提交订单。 9. 系统将订单作为未完成的交易保存，向记账系统提供支付信息。 10. 当支付确认后，订单被标志为确认，向用户返回ID，用例结束。
42.订购货物——网上订购货物  网上订购货物客户在National Widgets主页上选择订购货物，用例开始。系统在线显示目录主页。客户浏览在线目录，然后选择要购买的产品。对于每个选择的产品 a) 系统显示产品介绍和价格。 b) 客户选择把产品加入到购物车中。 c) 系统把物品价格增加到总数中。结束循环 5．客户选择购买。 6．系统要求客户键入用户名和密码。 7．客户键入用户名和密码。 8．系统送显示货地址和支付方式信息。 9．用户选择OK。 10．系统把这次订单作为未完成的交易保存，并向电子商务系统提供支付信息。 1． 2． 3． 4． 11. 当支付被确认，订单被标志为确认，返回给用户一个订单ID，用例结束。
43. 订购货物这个用例允许客户从National Widgets处订购产品。用例所要求的数据包括用户的支付地址，支付信息和定购的产品列表。客户还可以指定不同于支付地址的送货地址。电话购货这个用例和订购货物基本相同，以下几点除外： •客户为客户代表提供所有的信息， •由客户代表把所有信息输入系统。 •客户提供一个目录ID，用来从数据库中得到客户帐号信息。客户代表确认客户信息。
44. 订购货物这个用例允许客户从National Widgets处订购产品。用例所要求的数据包括用户的支付地址，支付信息和定购的产品列表。客户还可以指定不同于支付地址的送货地址。网上购物这个用例和订购货物基本相同，以下几点除外：第2步不需要。在第3步中，客户通过在线浏览选择产品，而非键入产品号。在第4步a）中，系统显示信息，客户选择把物品放入购物车中。在第4步b）中，价格总数和购物车联系在一起。在第5、6步中，客户登录到系统，系统提供送货地点和交易的支付信息。在第7步中，送货信息不需要确认。支付被送往电子商务包中。
45.用例图中的继承实例
46.完善的订单处理用例