三、订餐系统中的类图
类图是对象结构建模的一部份，类图描述系统中类的静态结构。尽管其他模型可以帮助建模者发现被模拟对象的重要信息，但是它们不能揭示的信息则必须求助于类图。类图模拟保证系统正常工作的所有必要资源。其它所有模型如果想获取这些资源（例如属性值、状态和对行为的约束）的信息，最终都必须访问类图。类图是代码生成（将模型转化为代码）的来源，也是逆向工程（将代码转化为模型）的目标设生成物。
1、类图的生成
顾客、员工、主管、菜单、材料、系统管理员 参与者相关的类（图）
（1）顾客类是参与者的类，它的属性包括订餐号、送餐地址、电话号码、身份证号码、VIP标记、VIP号码。
（2）主管是参与者类，它的属性包括姓名、姓别、年龄、身份证号码、工号。
（3）系统管理员是管理员类。
2、系统中的其它类
材料类是记录仓库中材料信息的类，包括菜名，数量，单价，进货渠道。 菜单类是记录餐馆中出售菜种的类，包括菜名、价格、简介。
- 8 -
各类之间的关系。
- 9 -
四、订餐系统中的活动图
活动图是基于对象的状态变迁所绘制的视图。它的主线是状态的变化，而不是时间，而时序图则是对象在不同时间段内的表现。为了满足这个活动图，类的一些基本必要方法就可以初步确定。再加上逻辑视图中类关系的分析，可以套用一些设计模式，又可以进一步再确定一些类的方法和属性。这一切的图，就是为了让你从需求情景描述-设计用例-逻辑视图-详细类分析抽象出你的类设计。总之，让面向对象的设计过程，思路连续，可推导。系统不可能完成所有的事情，必然有一部分功能是由人来完成的，所以活动图，从手工的角度描述了一个业务的流程，其中有些是手工作业，有些是系统的功能，活动图描述出了整个流程。活动这个术语的解释依赖于作图的目的和抽象层次。在描述概念层视图中，活动表示需要完成的一些任务；在说明层视图和实现层视图中，活动表示类中的方法。一个活动可以顺序地跟在另一个活动后执行，这是简单地顺序关系。如果触发事件连接到一个用加黑地粗线段表示地同步条上，且同步条引出几个带箭头地触发事件，那么这几个触发事件是并行的，也就是说这几个活动的执行次序可以是随意的。
1、客户的活动图
客户登录订餐系统后可以进行以下的操作：a.可以先查看自己帐号上的余额，然后再查看菜单，如果想订餐就创建订单；也可以直接退出系统。b.如果对
- 10 -
自己的余额、和菜单都了解的情况下也可以直接创建订单，然后再退出系统。c.也可以先查看菜单、余额再创建订单或查看菜单后直接创建订单；然后退出系统。
2、送餐人员的活动图：
3、厨师的活动图：
送餐人员登录系统后：查看客户订单获得菜名和送餐的地址。
厨师登录系统后可以进行以下的操作：a.厨师可以根据自己的手艺（能炒的菜）、和库存中原料的数量来创建菜单；b.厨师查看客户订单获得菜名。
4、主管的活动图：
- 11 -
主管登录系统后可以进行以下的操作：a.查看一天的销售情况；b.查看客户对餐馆的一些建议；c.查看客户的订单；d.查看库存的数量e.添加或修改材料数据。
五、订餐系统的构件图
构件图描述软件构件及构件之间的关系，显示代码的结构。构件是逻辑架构中定义的概念和功能（类、对象、它们的关系、协作）在物理架构中的实现。典型情况下构件是开发环境中的实现文件。在以构件为基础的开发（CBD）中，构件图为架构师提供一个开始为解决方案建模的自然形式。构件图允许一个架构师验证系统的必需功能是由构件实现的，这样确保了最终系统将会被接受。
除此之外，构件图对于不同的小组是有用的交流工具。图可以呈现给关键项目发起人及实现人员。通常，当构件图将系统的实现人员连接起来的时候，构件图通常可以使项目发起人感到轻松，因为图展示了对将要被建立的整个系统的早期理解。开发者发现构件图是很有用的，因为构件图给他们提供了将要建立的系统的高层次的架构视图，这将帮助开发者开始建立实现的路标，并决定关于任务分配及（或）增进需求技能。系统管理员发现构件图也是很有用的，因为他们
- 12 -