送餐管理系统.doc

订餐业务管理系统的需求描述“Restaurant On Wheels”公司（下文简称ROW公司）是一家以面向团体客户提供电话订餐服务为主营业务的餐饮企业。为减少投资风险，该公司自己并不生产外卖食品，而是与周边的多家餐馆建立合作关系，这种合作关系允许ROW公司以批发价格和记帐支付的形式获得客户订购的各种套餐。每个季度ROW公司将根据合作餐馆对外卖套餐的更新情况整理订餐目录，并将其送往各个注册的客户手中。ROW有专门的市场营销人员推广公司的服务，客户通过登记相应的联系信息即可获得注册资格，注册客户将获得具有唯一编号的订餐卡，并在每个季度得到最新的订餐目录。当需要订餐时，客户通过电话说明自己的订餐卡号码、要订购套餐的目录编号及数量，订餐员在核对必要信息后登记订餐内容，建立客户订单。对每一张客户订单要产生一张配送签收单以说明客户的配送地址、联系电话、所订购的套餐名称、数量，以及按零售价计算出的应支付金额，同时订单中的由同一家合作餐馆供应的订单项要汇总形成记帐单，说明要在该餐馆采购的套餐名称、数量和按批发价计算出的记帐金额，记帐单支付给相应的合作餐馆，作为月底ROW公司与各家合作餐馆结帐的依据。每一个订单由一名配送人员执行，配送人员通过记帐单到各家餐馆购买所订购数量的套餐，并按配送单将其送往指定的客户地址，客户支付现金并签收配送单。每天配送员要与经理进行当天交易的现金结算。ROW公司的员工主要分为市场推广员、配送员、订餐员三类。工资对订餐员支付固定工资，对市场推广员和配送员则在固定工资基础上再支付一定数额的奖金；市场推广员的奖金根据其推广的客户当月的订餐总金额进行计算，配送员的奖金则按照他所执行的配送任务次数进行计算。目前随着ROW公司业务规模的逐步扩大，迫切需要开发一个订餐业务管理系统以支持如下工作：1. 维护与合作餐馆的联系2. 维护与注册客户的联系3. 管理每个季度所提供的套餐种类4. 有效处理客户的订餐要求，生成执行订单的各种单据。5. 管理员工信息，并自动计算月薪6. 对每个月的销售情况、收支情况、结帐情况等信息进行统计。7. 数据域分析与建模过程1. 根据需求描述，寻找业务领域中的重要“事务”合作餐馆、订餐目录、套餐产品、客户、订单、订单项（明细）、记帐单、配送单、市场推广员、配送员2. 说明事物之间的关系，建立实体关系对a) 合作餐馆提供套餐产品b) 套餐产品组成订餐目录c) 市场人员推广客户d) 客户下达订单e) 订单包含订单项f) 配送员执行订单g) 记帐单采购订单项h) 记帐单支付给合作餐馆i) 3. 考察每个实体关系对的基数、形态4. 指定每个实体的属性5. 复审实体关系模型订餐业务管理系统的实体关系图模型ROW订餐业务管理系统的OO分析与建模1. 用例分析a) 用例是系统向使用者提供的某个完整的服务（功能）单元，用以处理在应用领域中可能发生的一种实际情况。当这种情况发生时，用例被激活，此时“参与者”同系统中的用例构成一个“交互场景”（执行过程），并最终产生一个符合“参与者”使用目的的结果。b) 用例是“动态”的。它是“外部参与者”与“软件系统”对某种业务情况进行处理的“过程”。因此对于用例的命名应该是“动词性”的，如“订餐处理”，“当日配送结算”。c) 用例是“相对独立”的。即系统中的一个用例应该完成与“处理某种业务情况”有关的全部工作。要注意，用例不是流程图，用例之间不是连续执行的，也不应该形成“紧密”的依赖关系。 2. 就ROW订餐系统而言，软件的应用领域中可能发生哪些”需要被处理的情况”，由“谁”负责使用系统的“相应服务”进行处理呢？需要被处理的业务情况（需求）参与者用例客户打电话订餐订餐员订餐处理客户打电话取消未执行的订单订餐员取消订餐发展了新的客户，需要进行注册市场推广员客户注册新的合作餐馆加盟经理注册合作餐馆合作餐馆终止合作关系经理删除合作餐馆每天下班前结算当天的订餐收入经理、配送员当日订餐结算每个月底结算与各家合作餐馆的记帐金额经理当月记帐结算每个月底对所雇佣的员工发工资经理、员工结算员工工资3. ROW系统的用例图（）4. 用例文档（以用例“订餐处理”为例）用例编号UC_01用例名订餐处理简述处理注册客户的电话订餐 前置条件订餐客户已在系统中注册，并获得了有效的订餐目录。订餐员通过执行“订餐”的菜单命令激活该用例。事件流1 系统显示订餐窗口2 餐员在订餐窗口中输入客户的订餐卡编号。3 系统显示出持卡客户的注册信息。E2：该客户未在系统中注册，系统提示“卡号无效”，用例结束4 订餐员核对客户的注册信息。E3：客户答复与注册信息不符，用例结束。5 订餐员输入用户订购的套餐产品编号。6 系统显示套餐名称及单价7 订餐员输入订购的数量。 X6：若用户订购多于一种套餐，返回4。7 订餐员在窗口的列表中选择执行配送的配送员8 订餐员提交订餐信息。 9 系统显示订单确认窗口，显示订单内容。10订餐员确认订单内容E10：订餐员取消订单，用例结束。11系统保存订单12系统打印“签收单”13系统将订购套餐按“供应餐馆”分组，打印记帐单后置条件若用例执行成功，系统登记订单，打印相应的“记帐单”和“配送签收单”5. 活动图对用例文档建模（以用例“订餐处理”为例）6. 系统静态结构分析a) 静态结构分析即分析系统应由哪些事物构成，以及这些事物之间的关系。采用类图进行建模。b) 一次性的确定完整系统的静态结构难度较大，通常以系统中的某个用例为范围，寻找参与到该用例执行过程中的事物。c) 分析系统“静态结构”可以采用“词性分类”、CRC（类职责协作）卡片等技术。可以通过分析用例文档中交互过程描述寻找系统中的实体类，分析过程应该力求回答如下问题：i. 当参与者完成了某个操作后，系统应该对应执行哪些动作；ii. 系统执行这些动作时必须使用哪些数据，什么“事物”负责提供和管理这些数据；iii. 系统执行的每个动作是什么“事物”的职责简单的说就是“系统要干的活”应该由系统中的哪个对象具体去干。d) 分析过程举例1 系统显示订餐窗口a) 这条信息说明系统内一定包含一种组成元素叫“窗口对象”b) 窗口对象提供说明自身特征的数据，如窗口大小、位置、窗口表面的可视元素等。c) 窗口对象至少包含一个职责，那就是“显示自己”2 系统显示出持卡客户的注册信息。a) 系统要完成这个动作，要用到与客户有关的数据，这些数据是说明“窗口”特征的么？很显然不是，所以系统内除了“窗口对象”以外一定还有其他的对象是提供和管理这部分数据的“客户”对象。b) 窗口对象通过找到对应的“客户对象”获得需要显示的数据。从职责上看“窗口”必须承担“显示客户信息”的职责，而“客户”对象则必须负责提供“注册信息”。c) “窗口”和“客户”之间必须有联系，以确保“窗口”能找到“客户”。3 系统显示套餐名称及单价a) 系统必须记下来用户要购买什么，“谁”负责从整体上保存和管理一次电话订餐所产生的全部订购信息呢。订单对象b) 订单对象是由若干条订购信息组成的集合。这个集合中的每一条订购信息要说明买什么套餐，买多少这又构成了一个规模更小的独立组成部分“订单项”。c) 每输入一个订单项要显示对应套餐的信息（名称、单价等），这部分信息谁提供套餐产品。4 订餐员在订餐窗口的列表中选择可用的配送人员a) 系统中一定有“配送人员”对象。b) 这个对象至少两个状态：可用或不可用c) 这个操作步骤的目的是什么？要建立配送员和订单之间的联系。5 依次类推，我们还可以找到的对象包括：“订单确认窗口”、记帐单、合作餐馆等等。6 讨论：配送单是不是系统中必须包括的对象。确定的依据是什么？a) “配送单”这个对象是不是提供和维护了系统工作过程中必须要使用到的，并且不能由其他对象提供的数据？从数据成员的角度上、配送单和订单一致。b) “配送单”这个对象是不是提供了系统工作过程中必须要应用的职责（功能），并且这个功能无法从其他对象中得到。事实上，“配送单”是系统打印给外部参与者的一张纸，这张纸所参与的是配送员和客户在客户家里签收的手工过程（签收不是系统用例，不是在系统中执行的动作）。c) 基于上述原因及需求假设可以考虑将配送单不作为系统中的实体类。e) 该用例范围内的主要实体类可通过如下类图表示，在系统分析阶段可以暂时省略系统中的边界类（如界面等）和控制类等。7. 交互过程分析a) 交互过程分析的任务是将活动图中由系统完成的活动“拆解”成系统中的对象所完成的动作。b) 通过系统静态结构分析，已经能够明确在某个用例范围内，涉及到哪些的种类的对象。交互过程就是要表示出用例的执行过程中，这些对象是怎样协作的。c) 为了简化交互分析过程，通常应该将用例执行过程中参与者与系统的每一次互动展开成一个交互片断，在必要的情况下，最终将产生的多个交互片断整合成完整的一个交互图。d) 实例分析过程可以先把交互过程用文字进行叙述。i. “订餐员”请求“订餐窗口”打开1 订餐窗口“询问”每个配送员的当前状态2