UML订餐系统.docx

UML订餐系统.docx

《UML订餐系统.docx》由会员分享，可在线阅读，更多相关《UML订餐系统.docx（20页珍藏版）》请在冰点文库上搜索。

UML订餐系统

学院：

班级：

专业：

课题：

指导老师：

前言

听老师说这课程（UML）是一门很新的课程，在贵州的学校来说开这门课的很少。

它是才发展起来的一门新兴的课程。

用起来是十分的方便和适用的。

在刚开始上这门课的时候老师交给我们每个组一个任务——用UML画一个自己所要开发的系统的图。

这和流程图不一样，流程图我们用了一些伪代码和我们自己的语言而画成。

用UML则不一样，它用了一些UML所特定的图来代表它的功能，方向等等。

又因为我们是初次接触这门课，所以我们只画了比较简单的系统——订餐系统。

老师讲一种图我们就画一种，在老师的不断纠正和自己的不断改进下，当课程结束后我们一组10人终于完成了我们的订餐系统图。

在其中包含了用例图，对象图，顺序图，通信图，类图，状态图，活动图，包图和部署图10个图。

为了人更能理解我们的系统具体的功能我们还做了一下一些必要的工作。

1、画每个图之后做了文字注释比如一些名词的解释，功能的具体解释等。

2、尽量将每种图的细节画出来画这些图也不是要真正的要开发这个系统，只是为了我盟能够更好的理解UML，为我们了解这门课也好还是以后真要从事这项工作也好能够更好理解这门课程，学懂这门课程打下基础。

一、订餐系统中的用例图

用例图（UseCaseDiagram）在需求分析阶段有很重要的作用，它描述人们希望如何使用一个系统，作为参与者的外部用户所能观察到的系统功能的模型图。

开发的全过程都是围绕需求阶段的用例图进行的。

我们所要开发的订餐系统内容十分丰富，用户包括授权的主管、客户、厨师及送餐人员、未授权的用户以及外部数据库系统，其角色层次图如图4-14所示:

未授权用户进人订餐系统后可以浏览系统内的公共资源，如餐馆的基本情况、菜单、新闻等，还可以通过注册系统申请成为授权用户。

授权用户通过订餐系统的身份认证后享有系统规定的资源，主管可以查看一天的销售情况、菜单、顾客的建议、顾客提交的订单、库存；顾客可以查看菜单、向餐馆提出建议、以及订餐等；厨师可以查看顾客提交的订单、顾客提出的建议、菜单、库存等；送餐人员可以查看顾客提交的订单获得地址、菜单等。

外部数据库则主要用于和系统进行数据交换。

经过以上分析得到订餐系统用例模型图如下：

作为教学评估系统的参与者有：

（1）主管：

主管可以登录系统查看一天的销售情况、顾客的建议、顾客提交的订单、以及查看库存、修改菜单等；

（2）顾客：

查看菜单、向餐馆提出建议、以及订餐等。

（3）厨师：

查看顾客提交的订单获得菜名、顾客提出的建议等

（4）送餐人员：

查看顾客提交的订单获得地址。

（5）系统管理员：

维护系统。

由以上的分析可以看出，系统的参与者主要有5类：

主管、顾客、厨师、送餐人员、系统管理员。

1、主管的用例图：

包含如下的用例：

（1）、登录系统。

（2）、查看销售情况（数据的统计）。

（3）、查看交费情况（用户是否已经付款）。

（4）、查看用户订单及备注（比如：

不吃葱、辣椒等）。

（5）、设置材料采购数据。

2、客户的用例图：

包含如下用例：

（1）、登录系统。

（2）、查看菜单。

（3）、提出建议。

（4）、提交订单及备注（如：

少加盐、多加辣椒等）。

（5）、网上付费及自己的余额查询。

3、送餐人员的用例图：

包含如下用例：

（1）、登录系统。

（2）、查看客户订单获取送餐地址。

4、厨师的用例图：

包含如下用例：

（1）、登录系统。

（2）、查看客户订单获取菜名。

（3）、添加菜单。

5、系统管理员用例图：

包含如下用例：

（1）、用户的查询。

（2）、数据分析。

（3）、菜单的设置。

（4）、结果查询（销售情况、客户订单、付费情况等）

二、订餐系统的时序图

时序图（SequenceDiagram）主要用于按照交互发生的一系列顺序，显示对象之间的这些交互。

顺序图的主要用途之一，是把用例表达的需求，转化为进一步、更加正式层次的精细表达。

用例常常被细化为一个或者更多的序列图。

顺序图除了在设计新系统方面的用途外，它们还能用来记录一个存在系统的对象现在如何交互。

当把这个系统移交给另一个人或组织时，这个文档很有用。

订餐系统的时序图主要有：

（1）、用户添加充值时序图；

（2）、客户订餐时序图；

（3）、主管对餐馆的相关信息查询时序图；

（4）、菜单更新时序图；

1、用户充值时序图：

2、客户订餐时序图：

3、主管查询时序图：

4、菜单更新时序图：

三、订餐系统中的类图

类图是对象结构建模的一部份，类图描述系统中类的静态结构。

尽管其他模型可以帮助建模者发现被模拟对象的重要信息，但是它们不能揭示的信息则必须求助于类图。

类图模拟保证系统正常工作的所有必要资源。

其它所有模型如果想获取这些资源（例如属性值、状态和对行为的约束）的信息，最终都必须访问类图。

类图是代码生成（将模型转化为代码）的来源，也是逆向工程（将代码转化为模型）的目标设生成物。

1、类图的生成：

顾客、员工、主管、菜单、材料、系统管理员

参与者相关的类（图）

（1）顾客类是参与者的类，它的属性包括订餐号、送餐地址、电话号码、身份证号码、VIP标记、VIP号码。

（2）主管是参与者类，它的属性包括姓名、姓别、年龄、身份证号码、工号。

（3）系统管理员是管理员类。

2、系统中的其它类。

材料类是记录仓库中材料信息的类，包括菜名，数量，单价，进货渠道。

菜单类是记录餐馆中出售菜种的类，包括菜名、价格、简介。

各类之间的关系。

四、订餐系统中的活动图

活动图是基于对象的状态变迁所绘制的视图。

它的主线是状态的变化，而不是时间，而时序图则是对象在不同时间段内的表现。

为了满足这个活动图，类的一些基本必要方法就可以初步确定。

再加上逻辑视图中类关系的分析，可以套用一些设计模式，又可以进一步再确定一些类的方法和属性。

这一切的图，就是为了让你从需求情景描述-设计用例-逻辑视图-详细类分析抽象出你的类设计。

总之，让面向对象的设计过程，思路连续，可推导。

系统不可能完成所有的事情，必然有一部分功能是由人来完成的，所以活动图，从手工的角度描述了一个业务的流程，其中有些是手工作业，有些是系统的功能，活动图描述出了整个流程。

活动这个术语的解释依赖于作图的目的和抽象层次。

在描述概念层视图中，活动表示需要完成的一些任务；在说明层视图和实现层视图中，活动表示类中的方法。

一个活动可以顺序地跟在另一个活动后执行，这是简单地顺序关系。

如果触发事件连接到一个用加黑地粗线段表示地同步条上，且同步条引出几个带箭头地触发事件，那么这几个触发事件是并行的，也就是说这几个活动的执行次序可以是随意的。

1、客户的活动图：

客户登录订餐系统后可以进行以下的操作：

a.可以先查看自己帐号上的余额，然后再查看菜单，如果想订餐就创建订单；也可以直接退出系统。

b.如果对自己的余额、和菜单都了解的情况下也可以直接创建订单，然后再退出系统。

c.也可以先查看菜单、余额再创建订单或查看菜单后直接创建订单；然后退出系统。

2、送餐人员的活动图：

送餐人员登录系统后：

查看客户订单获得菜名和送餐的地址。

3、厨师的活动图：

厨师登录系统后可以进行以下的操作：

a.厨师可以根据自己的手艺（能炒的菜）、和库存中原料的数量来创建菜单；b.厨师查看客户订单获得菜名。

4、主管的活动图：

主管登录系统后可以进行以下的操作：

a.查看一天的销售情况；b.查看客户对餐馆的一些建议；c.查看客户的订单；d.查看库存的数量e.添加或修改材料数据。

五、订餐系统的构件图

构件图描述软件构件及构件之间的关系，显示代码的结构。

构件是逻辑架构中定义的概念和功能（类、对象、它们的关系、协作）在物理架构中的实现。

典型情况下构件是开发环境中的实现文件。

在以构件为基础的开发（CBD）中，构件图为架构师提供一个开始为解决方案建模的自然形式。

构件图允许一个架构师验证系统的必需功能是由构件实现的，这样确保了最终系统将会被接受。

除此之外，构件图对于不同的小组是有用的交流工具。

图可以呈现给关键项目发起人及实现人员。

通常，当构件图将系统的实现人员连接起来的时候，构件图通常可以使项目发起人感到轻松，因为图展示了对将要被建立的整个系统的早期理解。

开发者发现构件图是很有用的，因为构件图给他们提供了将要建立的系统的高层次的架构视图，这将帮助开发者开始建立实现的路标，并决定关于任务分配及（或）增进需求技能。

系统管理员发现构件图也是很有用的，因为他们可以获得将运行于他们系统上的逻辑软件构件的早期视图。

虽然系统管理员将无法从图上确定物理设备或物理的可执行程序，但是，他们仍然欢迎构件图，因为它较早地提供了关于构件及其关系的信息（这允许系统管理员轻松地计划后面的工作）。

订餐系统中主要有两个构件图：

业务对象构件图和用户界面构件图。

系统建立在一个含有登录信息、菜单信息、客户信息、系统维护信息的数据库上。

1、业务对象构件图：

（1）、对象构件图说明：

查看销售情况：

该构件的功能是查看时间段的销售数量，金额。

菜单设置：

该构件的功能是通过数据库实时更新客户才看到的订餐菜单，也可以根据店内的营业拓展而更改。

客户订餐：

该构件的功能是对不同权限的客户提供订餐，退订服务。

送餐员查看订单：

该构件的功能是为送餐员提供客户订餐的统计数据，同时也是送餐员记录送餐成功与否及处理的平台。

厨师查看订单：

该构件的功能是为厨师提供客户订餐的统计数据，同时也是厨师记录每一个炒菜成功与否的平台。

除了业务对象以外，系统与用户交互的组件也能创建一个组件图。

2、用户界面构件图：

（2）、用户界面构件图说明：

销售情况统计界面：

是在查看销售情况时的显示界面。

菜单设置界面：

是在店主修改菜单时所见界面，通过数据库修改时没有相关界面。

送餐员数据统计界面：

是送餐员查看送餐统计数据及标记送餐成功与否得到界面。

客户订单界面：

是客户订餐时所见界面。

厨师炒菜数据统计界面：

是厨师查看炒菜统计数据及标记每一个炒菜成功与否的界面。

六、订餐系统的部署图

部署图描述了一个运行时的硬件结点，以及在这些结点上运行的软件组件的静态视图。

部署图显示了系统的硬件，安装在硬件上的软件，以及用于连接异构的机器之间的中间件。

创建一个部署模型的目的包括：

（1）探究系统投产的相关问题。

（2）探究你的系统和生产环境中的其它系统的依赖关系，这些关系可能是已经存在，或是将要引入的。

（3）描述一个商业一个用主要的部署结构。

（4）设计一个嵌入系统的硬件和软件结构。

（5）描述一个组织的硬件／网络基础结构。

订餐系统由5个节点构成，应用服务器主要负责整个系统的总体协调工作；数据库负责数据的管理；Web应用程序模块用于用户（主管、顾客、厨师及送餐人员）进行一天销售情况的查询、订餐结果的查询；业务操作模块用于处理客户进行网上订餐、数据分析等一般业务的流程；信息维护模块用于系统管理员维护整个系统的数据信息，如添加新用户、更改评估内容等。

系统配置图如下：

七、小组成员

张於李旭东陈文波李兴健张丽

朱赟李益宇邓有强陈勤燕王浩

八、总结：