餐厅管理系统

议题餐厅管理系统UML可视化建模技术讲授内容:2.1UML可视化建模实例2.1.1业务需求2.1.2业务域分析2.1.3用例分析2.1.4动态建模2.1.5静态建模2.1.6实现建模2.1.7复用扩展2.1.8架构分析2.2UML可视化建模案评审2.2.1评审的意义2.2.2评审的原则2.3UML可视化建模案例分析2.1.1建模过程地图我们现在在哪里?2.1.1系统目标1.从客户高层的要求中寻找系统目标客户老板描述未来该系统的目标是：(1)构建一个计算机辅助软件，提高员工的工作效率和准确性。（2）界面友好。（3）员工只作简单培训就可胜任工作。2.初步得出开发系统的映像（1）信息流动快，沟通有效（2）界面显示个性化，表达专业化，操作辅助化（3）使用人员计算机水平低，要求软件易用性强2.1.1餐馆业务需求（1）1.顾客进餐馆以后，如果穿有外套或帽子，保管员帮助顾客保存衣帽到储存室，并开据存衣票。2.如果有空位，领餐员直接让顾客落座。否则，如果排队，让预定客户落座，非预定顾客留下姓名，在等待区等待，或在休息区喝饮料。一直等轮到有准备好的餐桌时，领餐员让顾客落座。3.领餐员叫来该服务区的指定服务员，服务员给就餐者一份菜单，并让助手给顾客到水和上瓜子、花生，同时询问顾客是否要酒水。如果要，服务员亲自去拿。4.服务员推荐本餐馆的特色菜，顾客边喝边看菜单，服务员暂时离开5到10分钟，时间长短取决于顾客选菜时间。5.顾客点菜后，服务员记下所点的菜，并把一张定单交给厨房的厨师，内容包括桌号、主菜、酒水和点菜时间。活动图（上）2.1.1餐馆业务需求（2）6.在准备主菜时先给顾客上凉菜，顾客吃完凉菜后，服务员给顾客上主菜，7.顾客吃完主菜后，服务员询问顾客要主食还是水果，如果要主食，在顾客点主食菜单后，上主食；如果要水果，服务员就给顾客上水果，如果都不需要，服务员拿来帐单让顾客确认。8.几分钟之后，服务员再来收现金，找零钱，给发票。9.顾客离开座位后，持票取回衣帽，离开餐馆。10.服务员在顾客走后叫来清洁员，清洁员清理餐桌，并重新布置好餐桌，最后把旧台布送洗衣间。活动图（下）现在我们在那里？架构雏形创建系统构架的初始草图步骤：1.初步定义一组在构架方面具有重要意义的元素。2.初步定义一组分析机制。3.初步定义系统的分层与组织。首先，餐馆的主要分析类是服务员和顾客，服务员在餐馆不断的流动为顾客服务，这决定网络可以用一个局域网，其次，服务员在服务时要随时了解有关信息，这决定了数据采集入口采用无线方式，有关信息要通过网络访问数据库（客户服务器机制）最后，由于所有员工都要访问系统，且每次访问的数据量都不大，加之用的是无线手提pc，用b/s结构最好。一层是客户端，另一层是数据库服务器端。结论：采用浏览器/服务器的二层体系架构。我们现在在哪里?2.1.2业务领域分析2.1.2.1寻找分析类方法：（1）寻找出需求中的名词从需求中找出的名词如下；顾客，外套，帽子，储存室，保管员，存衣票，领餐员，队，预订，姓名，休息区，侯餐区，饮料，餐桌，服务区，服务员，菜单，就餐者，水，助手，瓜子，花生，酒水，餐馆，特色菜，选择菜，定单，厨师，厨房，凉菜，主菜，桌号，时间，主食，主食菜单，水果，账单，现金，零钱，发票，座位，清洁员，洗衣间，台布，洗衣间。(2)合并含义相同的名词，排除范围以外的名词，寻找隐含的名词顾客，就餐者洗衣间经理(3)去掉只能作为类属性的名词姓名，时间，桌号，预订（4）剩下的名词就是要找的分析类（候选类)2.1.2业务领域分析2.1.2.2分组目的：为建立抽象类做好准备，为系统的扩展性打下基础。（1）与人有关的类：顾客，保管员，领餐员，服务员，助手，厨师，清洁员，经理，可以分两个类，顾客类和员工类（2）与食物有关的类：饮料，主食，主菜，凉菜，酒水，水果，水，特色菜，瓜子，花生，可以分一个类，食物类(3)与餐馆用具有关的类，餐桌，台布，座位，分为一个用具类(4)与餐馆的支付有关的类，账单，现金，零钱，发票，分为一个支付类(5)与表单有关的类，存衣票，菜单，主食菜单，定单，分为表单类（6）与餐馆分区有关的类，保存室，侯餐区，休息区，服务区，厨房，2.1.2业务领域分析2.1.2业务领域分析2.1.2.3寻找关联目的：为建立核心设计式样做好准备，并为建立业务模型打下基础。（1）寻找需求中与每个类相关的动词，以及隐含的动词如顾客类，动词有:保存，开据，预订，落座，留下…..(2)通过动词，找到相关的短语。如顾客类，相关短语有：保管员给顾客保存外套，保管员给顾客保存帽子，给顾客开据存衣票，顾客在餐桌落座，顾客留下姓名，顾客吃凉菜，顾客吃主菜，顾客用菜单选菜，顾客吃主食，给顾客下定单，顾客付账，保管员给顾客取帽子，保管员给顾客取外套。（4）寻找短语中的二元关联类。（5）寻找多元关联保管员可以给一个顾客可以保存和取回多个帽子(或外套)，它们之间是多元关联。（6）添加多重性。（7）以同样的方法寻找其他分析类所参与的关联类2.1.2业务领域分析2.1.2业务领域分析2.1.2.4寻找聚集目的：为建立核心分析类的对象组成结构做好准备，并为建立对象生命周期之间的关系打下基础。（1）如食物类中，一个食物对象由一个凉菜对象，一个饮料对象，一个主菜对象，一个主食对象，一个酒水对象组成，除主菜对象外，其他对象是可选的（2）如在餐馆类中，一个餐馆对象由多个服务区对象，一个侯餐区对象，一个休息区对象，一个储存室对象，一个厨房对象，一个洗衣间对象组成（3）一个定单对象由多个选择菜对象组成2.1.2业务领域分析2.1.2业务领域分析2.1.2.5填充分析类目的：完成业务分析的最后工作，并为设计类图打下基础。（1）在顾客类中，主要属性有:姓名、到达时间、餐桌号、定单、服务时间，操作（来自动词和隐含动词)有：吃、喝、选菜、付账。（2）在员工类中，主要属性有：姓名、住址、身份证号、入司时间、工作年限、薪水，（子类助手有协助的对象属性），每个子类有特定的操作。（3)服务员子类的操作有:拿（酒水）、介绍(特色菜)、收钱、呼叫(助手)、检查(定单）。（4）厨师子类的操作有：准备、做饭、优先级。（5）助手子类的操作有:准备、传菜、上（瓜子花生）、到水。（6）经理子类的操作有:监督、管理、分配（工作）。（7）支付类的属性有：饭菜费用、其他费用、总计，操作有计算总帐，显示总帐。（8）完成业务领域分析，形成模型字典。2.1.2业务领域分析我们现在在哪里?2.1.3用例分析2.1.3.1寻找角色角色是用例的发起者，根据前面业务领域分析知道，餐馆业务有以下角色:1.服务员2.领餐员3.保管员4.吧员5.助手6.厨师7.清洁员8.商务9.经理2.1.3用例分析2.1.3.2寻找信息流动的位置从前面需求中，可以找到以下与服务员角色有关的信息流动位置：（1）服务员介绍特色菜，把信息流给顾客。（2）服务员在顾客选菜是回答顾客提出的问题，把信息流向顾客。（3）顾客下订单，信息流到服务员，服务员又把该信息流给厨师。（4）服务员询问厨师定单完成的情况，把信息流向厨师，厨师反馈信息流向服务员。（5）顾客对账单有疑问，服务员回答顾客问题，把信息流向顾客。（6）服务员呼叫助手上瓜子花生，把信息流向助手。（7）服务员呼叫清洁员清理餐桌，把信息流向清洁员。2.1.3用例分析2.1.3.3筛选信息流动位置，细化信息流动过程筛选每个角色可以用计算机辅助信息流动的位置，可以找到以下与服务员角色有关的活动：（1）输入定单。（2）把定单输到厨房。（3）修改订单。（4）跟踪定单状态。（5）通知厨师顾客的用餐状态。（6）账单结算。（7）打印账单。（8）召来一名助手（9）召来一名清洁师（10）接受厨房的通知…….2.1.3用例分析2.1.3.4寻找基本用例把每个角色的每个活动，作为低级用例进一步细化，如服务员角色的“输入定单”活动，需要做一下细化：前置条件：顾客已经阅读过菜单，并作出了选择后置条件：定单被输入餐馆管理计算机系统用例步骤：1.服务员激活他的手提pc，进入输入定单界面。2.定单输入界面显示在手提pc上。3.服务员把顾客的菜单选项输入餐馆管理计算机系统。4.系统把定单发给厨房pc。再寻找备选流程（如厨师正忙）和异常流程（已估清）如此反复，完成每个角色的每个活动的用例化。2.1.3用例分析2.1.3.5寻找顶级用例对用例进行组合，形成用户使用系统有经济意义顶级用例。并分析顶级用例和低级用例的关系（包含和扩展），如对服务员角色，可以形成一下四个顶级用例：1.管理定单（包括输入定单，发送定单，修改订单，跟踪定单，输入饮料定单，发送饮料定单)2.管理账单（包括结算账单，打印账单）3.发送信息（呼叫助手，呼叫清洁员)4.接收信息（接收吧台通知，接收厨房通知，接收对方确认）2.1.3用例分析我们现在在哪里?2.1.4动态分析2.1.4.1健壮性分析1.把每个角色的每个低级用例进一步分析，找出隐藏在用例底下的边界类，控制类，实体类：2.职责划分，把用例中的行为分配给的每个对象，该行为就成为对象发出（或收到）的消息，最后成为类的操作。3.根据上面对象分配的行为，填充相应类的操作。如：输入定单用例可以找到一下类角色：服务员边界类：服务员操作界面类，厨师操作界面类控制类：定单处理类实体类：定单实体类，定单持久化实体。2.1.4动态分析（健壮性）我们现在在哪里?2.1.4动态分析2.1.4.2交互分析把每个角色的每个低级用例进一步实例化，如服务员角色的“输入定单”用例，需要做一下实例化：用例步骤：1.服务员激活他的手提pc，进入输入定单界面。2.定单输入界面显示在手提pc上。3.服务员把顾客的菜单选项输入餐馆管理计算机系统。4.计算机系统创建一个定单对象。5.定单程序把定单输入发给厨房pc的界面6.定单程序把定单输入发给定单数据库。7.定单程序通知服务员已把定单发给厨师和数据库。如此反复，画出所有角色主要的顺序图（或协作图）2.1.4动态分析（顺序图）2.1.4动态分析2.1.4.3寻找界面类1.根据每个角色的顶级用例寻找界面类(如果有原型,也可参考原型)，如服务员角色有四个顶级用例，对业务相关的用例再进行合并，形成定单，支付，信息（源于发信息和收信息用例）三个界面类2.为每个界面类，从低级用例中找出相应的动作，形成界面类的功能键，如定单界面类就有：菜单项选择控件，获取饮料单控件，修改菜单控件，跟踪菜单控件，发送饮料单控件，发送菜单控件。2.1.4动态分析2.1.4动态分析（状态图）我们现在在哪里?2.1.5静态建模2.1.5.1.补充非主要分析类保管和吧台不是餐馆业务的主要分析类，在静态建模期间仍需要细化（1）保管员的属性继承员工属性，操作有：保存外衣，保存帽子，返还外衣，返还帽子，开据票据，回收票据。（2）吧员的属性继承员工属性，操作有：开饮料定单，准备饮料，打印饮料定单，上饮料，清洁。2.1.5.2修改主要分析类在分析类中添加与效率有关的属性（1）如在顾客类中，添加等待时间，吃饭时间，离开时间，状态属性。（2）如果要管理服务员的工作效率问题，也可添加相关的时间属性（3）在餐桌类中增加状态属性。（4）在定单类中增加状态属性。2.1.5静态建模我们现在在哪里?2.1.6实现建模2.1.6.1增加效率的硬件方案从信息流动方式，提高信息流动效率（1）如服务员把定单走动拿给厨师，改为用无线手持设备。（2）如厨房把定单的菜做好，可用桌面pc通知服务员（3）服务员呼叫助手和清洁员也用手持设备（4）经理管理效率用桌面pc2.1.6实现建模2.1.6实现建模2.1.6.2功能组织功能的组织可以按业务分类、组织机构、区域，角色等（1）如按业务组织，可分为：寄存，预订，用餐，清洁，收银。（2）如按组织机构组织分为：储存部，大堂，厨房，前台。（3）如按服务区域划分。可分为：储存区，侯餐区，休息区，服务区，厨房，洗衣间。（4）如按角色组织。可分为：服务员，领餐员，助手，厨师，商务，保管员，