细化迭代4——实现退货

 

2.1业务建模

A. 业务流程建模。

u  使用UML活动图分析目标系统所支持的业务流程。

u  使用文字对流程中每个活动的涉众、业务规则、使用到的单据进行必要的说明。

u  

涉众有：收银员、顾客、服务员、酒店、经理、支付授权服务、税务代理机构；

业务规则：

　一、餐前准备工作

　　①、按规定着装；检查自己仪容仪表是否符合规范；做好岗位清洁工作；

　　②、认真、仔细查看上一班交接内容；处理未完成的事项；

　　③、将昨日午市和晚市结账单、收银报表交财务部；

　　④、检查收银台各种设备是否正常，有无异常情况及时上报：电脑、打印机、点钞机、POS机

　　⑤、备用金的工作交接：一楼备用金1000元，茶楼备用金1000元，备足发票、结账单以及其他物品。

　　二、营业操作流程

　　1.接单、录单工作：

　　a.接单员在收单服务员开出的点菜单或酒水单后，仔细查看上面填写内容，如有不清楚或不正确时，客气请服务员更改。

　　b.所有单据正确之后，进行电脑对单，看是否有误遗漏；

　　c．收银员收到服务员买单通知后，确认台号、所点的菜品、酒水饮料之后，打印结账单；

　　d．打完结账单后，将结账单副联交服务人员进行买单；

　　e．收到结账单后，对消费桌进行相应结账处理，收款后马上消台；

　　2.客人联台处理：

　　a．收到由楼面部确认后的联台信息，让通知人员在收银点菜单上写明联台号并签名；

　　b．在卡头登记日期，班次及联台桌号，熟记连台桌号；

　　c．收到连台信息的楼层通知其他楼层；

　　d．其他楼层收到信息后以相同方式记录在卡头上；

　　e．将连台信息置于醒目位置；

　　f．收到买单信息后，由服务员将结账单交接传递到买单楼层，收银员电话确认结账有无传到买单楼层，若买单客人拒买连台单，找楼面主管级以上管理人员协调处理；

　　g．买单后款项及结账单，由收银员保存存根；

　　3.结账工作：

　　a.现金结账；

　　接到服务员或客人现金后，快速清点现钞、验钞，准确找补零钱，若有质疑，与楼面主管联系，客气地请客人调换；结账后由值台服务员在结账单上签字确认实收金额及付发票金额，盖“现金”章

　　B．信用卡结账与POS机的操作；

　　C．客户签单：（折扣优惠以协议为准）

　　4.服务员报签单客户信息；

　　按签单客户协议打折；打印结账单，请客人签名；核对签字模式；

　　结账单上盖“签单”章，留存；

　　注：收银员必须熟记签单客户资料（单位、折扣、签单人以及签单模式）；

　　d.临时挂账（需经理级以上人员担保签字）

e．消费卷结账；

        B. 领域建模。

u  使用UML类图构建领域模型。

u  

2.2需求规格说明

需求规格说明书(Software Requirements Specification)描述了系统的功能需求。构建系统用例模型描述功能需求。

1.   A.     系统用例图。绘制整个系统的UML用例图。

B. 用例详述文本

对所有业务活动用例采用详述风格（包括前置条件、后置条件、主事件流，扩展、业务规则等）进行描述。

用例:（1）  客人进店开手牌 

参与者: 管理员 

目的: 给客户开手牌，安排座位 

概述: 有辛苦人进店后，管理员要看一下系统还有没有手牌，如果有的话给客户开手牌，手牌的种类有客户自己选择，然后安排客户就座 。

前置条件: 系统运行正常 

后置条件: 给出处理结果 ，发出手牌或者告知没有空位 特定要求: 

待请求发出后，系统必须在两秒内作出反应 

主 事件流 

参与者操作 

1.管理员发出查询请求 

2.管理员给客户展示后让客户选择满意的餐桌。管理员开出手牌

系统作出响应 

3.显示空余的桌子和已经有人的桌子，

 4.根据手牌开出这桌客人的预消费列表，并指定专属服务员， 

5.记录服务员与相应的手牌

 6.要求入库 

候选事件流 

第一行：如果没有手牌，系统要给管理员提出警告。 

用例:（2）客户点菜 

参与者: 客户，服务员 

目的: 服务员记录客户的点菜菜单 

概述: 

客户选择自己喜欢的菜品，服务员记录菜品，菜单一式两份手写和复印。复印那份给管理   员，手写那份粘在手牌上。并传给厨房备菜上菜，并随时准备加菜或者减菜 

用例:（3） 管理员记录菜单 

参与者: 管理员 

目的: 记录相应桌子上的菜单 

概述: 

管理员根据服务员拿过来的复印式菜单输入相应手牌上的菜品， 

前置条件: 相应手牌已经开出，并且已经列出点菜列表

 后置条件: 记录菜单，入库留存 

 事件流 

参与者操作 

1. 管理员输入客户所点菜品

      系统响应 

2.根据输入列出所点菜品列表并入库保存 候选事件流 

 用例:（4） 客户加减菜 

参与者: 管理员 

目的: 给客户加减菜，满足客户需求并入库保存 

概述: 

客人要求加减菜时，系统要记录相应手牌的加减菜品以备最后结算作为依据 

类型:   基本 

前置条件: 客户首次所点菜单已经列出并且已经保存 

后置条件: 记录客户加减菜后的菜单入库并且保存

 事件流 

参与者操作 

1.   输入客户加减菜菜单

系统响应 

 2.记录修改后的列表 

3.删除原先的列表并入库保存更改后的列表 

用例:（5） 结账 

参与者: 管理员 

目的: 根据客户消费记录进行结算 

概述: 

管理员调出相应手牌的消费记录并且计算金额，进行收账，收账后要求系统及时入库并且保存 

前置条件: 客户消费情况已经入库并保存 

后置条件: 给出消费列表和项目 

 事件流 

参与者操作 

1.   管理员发出结算请求

系统响应 

 2.显示相应手牌的消费记录，并且自动累加计算  

3.显示消费小票，并送入打印机打印出小票 

4.备份小票和相应的服务员，资料入库并保存，设置权限，非管理员无权打开参阅

2.3补充性规则说明

   补充性规格说明补货并确定其他类型的需求，如可靠性（如10000人并发访问）、可用性（如1米外轻松看到文本）、接口（如支持钱箱、支持网银支付接口）等。也可以包括其他跨越多个用例的功能性需求如报表、安全性、日志和错误处理、数据备份、数据导入导出等。

1.功能性

1.1满足多个顾客的并发执行。1 该系统应支持多达1000名顾客在任意特定时间使用中央数据库，并支持多达500名顾客在任何时候访问本地服务器。

1.2当顾客预定饭菜时，系统必须判断该食品是否还有剩余，若该食品已无库存，需提醒顾客，并通知采购部门进行采购。

2 可用性

2.1前台顾客界面采用美观，方便浏览的布局，色彩温和，餐饮主题突出，模块分布清晰。2.2后台管理界面各管理模块采用下拉菜单式设计，简洁大方，层次清晰，便于操作

2,3顾客界面视窗与WINDOWS系统兼容。

3. 可靠性

保证系统在配置完成以后24小时都可用，平均无故障时间应超过300小时。

系统要求对数据库的访问，存取速度要快，特别是对食品目录的访问的反应时间要在8秒内

4 数据备份

对数据库初始数据的设置，系统维护与升级。对数据进行分析，并根据顾客点菜情况适当修改菜单。权限设置，数据备份。 

5. 安全性

系统要求有较高的安全性，由于在管理订单时，顾客的信息都在网络上传输，所以必须提供额外的安全性措施。

6接口设计 

6.1用户接口

在这一接口里创建对象以访问数据库而不是使用直接函数调用，用户可设置和取得对象属性或调用方法。程序代码变得更清晰，开发和维护更为简单。 

Microsoft使用多种对象接口来访问数据库管理系统，比如SQL Server的数据： (1) 数据访问对象( DAO )。 (2) 远程数据对象( RDO )。 (3) OLE DB。 

(4) ActiveX Data Objects。 

6.2外部接口 

所有本组讨论的接口以标准形式写出，支持Visual Basic程序的调用。SQL Server对Visual Basic编程人员提供两种调用级接口： 

(1) DB-Library。 

(2) 开放式数据库连接(ODBC)。 DB-Library是Microsoft开发的提供到SQL Server的函数调用的API，因此，DB-Libra ry是使用第三部分数据转换和集成数据服务、业务服务、表达服务。

4.3 数据库设计

待续