订货中心系统用例模型分析.doc

一、《订货中心系统》简介： 有这样一个订货中心，它接受客户的电话、传真、电子邮件、信件和web主页表单形式的订货请求，形成货物订单，并告知客户订单的价钱。根据客户要求的发货目标地点的信息，订货中心的经理以最经济的方式确定一家仓库来负责向客户发货。仓库人员收到订单后按一定的策略处理订单，发出货物，并在订单上填写所发货物的数量信息，后把订单返回给订货中心。订货中心确认后把订单交给收费部门，由该部门负责关联客户收到货物后的付费。 客户在收到货物之前可以向订货中心查询他的订货处理情况。收到订货后，如果出现质量问题或者物品错送问题（即送的货物不是客户想要的货物），客户有权利向订货中心退货，订货中心必须接受退货，并退还用户所付款（如果用户已付款）。仓库在处理订单时由于受到库存货物有限这一现实情况的约束，因此采取一定的策略来保证那些优先级较高的订单先得到发货。 在订货中心的人工系统中，交流主要通过电话、传真，如订单传送等。在引入计算机管理后，订货中心、仓库、收费部门之间可以共享客户、订单信息，不仅省去了电话、传真的成本，同时重要的是提高了订货中心运作效率。 二、系统建模： 参与者识别及描述： 问题1：谁使用订货中心系统的主要功能？ 回答：管理者（Manager）、发货人员（Shipper）、客户（Customer）和收款人员（TollCollector）。 问题2：谁需要订货中心系统的支持以完成其日常工作任务？ 回答：Manager、Shipper和TollCollector。 问题3：谁负责维护、管理并保持订货中心系统正常运行？ 回答：Manager。 问题4：订货中心系统需要应付（或处理）哪些硬件设备？ 回答：信用卡（Credit card）。 问题5：订货中心系统需要和哪些外部系统交互？ 回答：没有。 问题6：谁（或什么）对订货中心系统运行产生的结果（值）感兴趣？ 回答：Customer、Manager。 订货中心系统的参与者：管理者（Manager）、发货人员（Shipper）、客户（Customer）、收款人员（TollCollector）和信用卡（Credit card），分别描述如下： 参与者：管理者（Manager） 参与者职责： 接受订货，计算价钱，选择仓库发货。 参与者识别问题：1、2、3、6。 参与者：发货人员（Shipper） 参与者职责： 根据订单发货给顾客，填写订单。 参与者识别问题：1、2。 参与者：收款人员（TollCollector） 参与者职责： 根据订单签收顾客的订货款，顾客退还商品时退款。 参与者识别问题：1、2。 参与者：客户（Customer） 参与者职责： 订货、退还订货、查询订单。 参与者识别问题：1、6。 参与者：信用卡（Credit card） 参与者职责： 电子付订货款。 参与者识别问题：4。 用例识别及描述： 用例模型获取的第一步是识别参与者，通过参与者的识别可以进一步识别用例，从而得到用例模型。然而用例的识别要比参与者识别复杂得多，一方面要从系统的功能需求中抽象出用例，同时还要控制用例的数目。用例数目过多则造成用例模型过大，同时引入设计因素的可能性也加大了；用例数目过少则造成用例的粒度太大，不便于进一步分析，或者不充分。 订货中心系统是一个中等规模的系统，我们先可以不特别关注它的用例数目问题。根据前面介绍的方法，我们首先从各个参与者那里来识别用例： 从管理者（Manager）识别 管理者要求系统为其提供什么功能？管理者需要做哪些工作？ 答：管理者要求系统提供： 接受顾客订货请求并创建订单； 计算订单价钱； 根据订单信息选择仓库，并将订单发送给该仓库； 查询订单货物发送情况； 查询客户订单付款情况； 评价商务结果； 客户退货处理； 把从仓库返回的订单发送到收费处； 商品价格更新。 管理者需要做： 生成订单； 查询输入订单号。 管理者需要阅读、创建、销毁、更新或存储系统中的某些（类）信息吗？ 答：是，这些信息包括： 订单； 职员（仓库人员、收费人员）信息； 顾客信息； 物品条目及价格信息； 仓库信息； 税务信息。 系统中的事件一定要告知管理者吗？管理者需要告诉系统一些什么吗？那些系统内部事件从功能的角度代表什么？ 答：是，这些事件包括： 仓库有关物品短缺以致无法满足某订单； 订单数据出现错误； 顾客超过期限未付款。 由于系统新功能的识别，管理者的日常工作被简化或效率提高了吗？ 答：是。 从发货人员（Shipper）识别 发货人员要求系统为其提供什么功能？发货人员需要做哪些工作？ 答：发货人员要求系统提供： 仓库存储物品的管理； 发货处理。 发货人员需要做： 从所有的订单中按顺序挑选处优先级较高的订单来发货； 在订单上签上发货的品名、数量。 发货人员需要阅读、创建、销毁、更新或存储系统中