(餐饮管理)送餐管理系统

订餐业务管理系统的需求描述

“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.用例文档（以用例“订餐处理”为例）

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)该用例范围内的主要实体类可通过如下类图表示，在系统分析阶段可以暂时省略系统中的边界类