汽车销售管理信息系统的系统规划.docx

汽车销售管理信息系统的系统规划一、汽车销售管理信息系统的系统规划第一节 项目开发背景随着经济的发展和中国汽车市场的不断扩大，某汽车配件公司也随着发展的浪潮不断扩大规模，随之，订单成倍增加，各项业务更加细化，各部门工作量增加，以往的人工处理方式就显得力不从心，劳动强度大而且容易出错。 项目开发目的 本课程设计的具体任务就是设计一个企业内部业务管理信息系统，利用现代计算机和数据库开发技术来代替人工处理，从而减轻企业各部门工作人员的劳动强度，提高工作质量和效率，提高信息资源的利用率和企业管理水平。 可行性分析 现在企业的业务流程管理方式为手工处理，重复劳动多，劳动强度大，而且容易出错，新系统的使用将有以下几个方面的优势：从技术上考察A 处理速度快，准确；B 通过权限的设置，数据的安全性好；C 方便查询；D 控制精度或生产能力的提高2 从经济上考察A 系统建设不需要很大的投入；B 可缩减人员编制，减少人力费用；C 人员利用率的改进；3 从各种社会因素来考察A 可降低工作人员工作强度，提高效率，会得到企业上下员工的一致同意的；B 可引进先进的管理系统开发方案，从而达到充分利用企业现有资源综上所述，本系统的开发立项是可行的。第二章 企业内部业务管理信息系统的系统分析第一节 组织结构与功能分析 图1 组织结构图第二节 组织/业务关系图业务联系 组织程度销售部会计部采购部仓库经理销售活动*财务管理*采购活动*库存管理*行政监督管理* 图2 组织/业务关系图第三节 业务功能一览表经营主管销售主管仓库主管采购主管财务主管业务员仓库采购员财务会计销售员管理应收款明细账管理应付款账目管理会计总账编制报表收款发出订货单验收货物入库接收发货单修改库存量管理货物入库出库检索库存验证订货单修改订货单开发货单检查暂存订货单确定顾客订货 图3 业务功能一览表 第四节 业务流程图销售历史公司档案存档会计人员暂定订单核对验收入库检查暂存订货单应收款明细账核对应收款明细账采购人员供应商经理订货配件汇总订货单填写发货单发货单修改会计总账会计总账应付款账目接受并开收据修改应收款明细账编制报表查询库存量顾客销售部门订货单库存配件发货单验证订货单确定顾客订货检索库存开发货单并修改库存产生暂定订单登录新客户数据客户数据到货通知修改库存量付款业务员收据 图4 业务流程图 第五节 数据流程图1.1.5登录新顾客数据采购人员业务人员1.1.1验证订货单1.1.4产生暂定订单1.1.2确定顾客订货1.1.3开发货单修改库存暂定订单应收款明细账库存配件顾客数据销售历史顾客纠正错误不合格订单发订单合格订单不满足订货 检索满足订货有新顾客 修改 开发货单通知记录记录图5-1 销售过程数据流图供货商销售部门采购人员1.1.1订货配件汇总订货单1.1.2订货1.1.3填写发货单发货单1.1.4核对验收入库1.1.6办理销售业务发货单到货通知库存配件应收款明细账1.1.5通知销售部门顾客确定给采购人员发货单发出到货 通知记录对照暂存订单记录产生 开出发货图5-2 采购过程数据流图应付款账目1.1.5修改会计总账1.1.1付款顾客1.1.2核对应收款明细账1.1.3接受并开收据收据1.1.4修改应收款明细账应收款明细账会计人员供应商1.1.6核对应付款账目1.1.7付款并修改应付款账目会计总账1.1.8编制报表会计报表销售分析报表库存报表经理库存配件1.1.9查询库存量给顾客收据开出现金支票转账无误给会计发货单无误 修改 提供依据 提供依据提交编制提交编制提交编制图5-3 财务过程数据流图 销售顾客配件采购部门供销商经理销售部门库存配件会计部门应付款账目应收款明细账报表客户订单公司合作合作编辑接受属于查询记录属于管理参考对应产生对应管理产生属于购买供应第六节 系统数据库建模-E-R模型分析1N1N1N111111N11111NN1NNN11NN1 NNMMNN11N图6-1 E-R图图6-2 E-R图第七节 系统U/C矩阵分析功能数据类 顾客数据发货单应收款账目销售历史暂存订单公司订单到货通知应付款账目收付单据会计总账报表库存销售管理客户管理CU销售配件UCUUU记录业务CC采购管理记录缺货UCU追加订货UC验货入库UUCCU财务管理收付款UUUUC会计核算UUUCU编制报表UUUUUCU库存管理库存管理UUUC监督管理UUUUU 图7 U/C矩阵第三章 汽车销售管理信息系统的系统设计第一节 功能子系统划分根据U/C矩阵分析，对汽车配件公司业务管理信息系统进行功能子系统划分， 如图8所示。本系统只要花分为四个功能子系统：企业业务管理系统库存管理财务管理采购管理销售管理会计账目管理会计报表管理订货管理客户管理采购配件管理供应商管理库存量管理库存查询管理图8 系统功能子系统图销售管理子系统：对客户数据、订货处理等销售业务进行管理；财务管理子系统：负责各种报表和账目的管理工作； 采购管理子系统：管理供应商信息，进行采购、收货、验货等采购业务；库存管理子系统：对仓库存货进行管理和监督。第二节 层次化模块结构图汽车配件公司业务管理信息系统中，模块划分和处理过程设计是非常关键的一步，因此，我本着对系统可修改性、易读性、易查错性等方面进行设计。基本思想是：1、模块化；2、图表文字解说。其中，HIPO图是一种强有力的描述系统机构和模块内部处理功能的工具，它主要包括层次结构图和IPO图两个部分。层次结构图描述了整个系统的设计结构以及各类模块之间的关系；IPO图则描述了在某个特定模块内部的输入（I）、处理过程（P）、输出（O）思想。企业业务管理系统库存管理财务管理采购管理销售管理会计账目管理会计报表管理订货管理客户管理采购配件管理供应商管理库存量管理库存查询管理 图9-1 层次化结构模块图层次化结构模块图是从结构化设计的角度提出的一种工具。汽车配件公司业务管理信息系统的模块化分为若干子系统，如销售管理子系统、采购管理子系统等，它们之间是平级关系，并且，相互之间也不交叉。同时，一个模块还下分了子模块，如销售管理子系统下面包含了客户管理和订货管理两个子模块。这样，从整体上来划分，形成从全局来进行管理的格局。订货管理A.1订单输入A.2.1订单处理A.2.2开发货单A.2.3图9-2 层次化订货管理模块结构图输入部分 I处理描述 P输出部分 O1. 利用权限打开数据库2. 输入定货单的顾客信息：名 称、地址、电话、开户行、账号3. 输入定货单的各类信息：配 件名称、规格、编号1. 核对用户账号和新建用账号2. 核查定单信息3. 处理过程出错信息 定单不合格新建用户合格定单处理老用户合格定单处理1. 将合格标志送回上一级调用模式2. 将核对的记录记入文件3. 修改顾客记录4. 将合格的定单信息以标准格式输出模块名称：定单输入系统使用单位：销售部图10-1 订单输入IPO图 订单输入IPO图表示了订单输入模块，讲述了如何输入客户订单，检查其正确性，核对建立新的账号等功能。模块名称：定单处理系统使用单位：销售部和采购部输入部分 I处理描述 P输出部分 O1. 利用权限打开数据库2. 上组模块送入的合格的定单信息3. 输入当前各配件库存量1. 将定单的配件信息与配件当前 存量核对2. 处理过程出错信息库存量满足定单要求处理库存量暂缺处理零库存量定单处理部分满足库存量处理1. 将合格标志送回上一级调用模式2. 将核对的记录记入文件3. 完全满足定单要求输出发货单4. 暂缺配件库存量的暂存定货单文件图10-2 订单处理IPO图订单处理IPO图表示了订单处理模块，讲述了如何核对处理订单，对库存量和订单进行比较处理等功能。模块名称：库存量查询系统使用单位：销售部和经理输入部分 I处理描述 P输出部分 O1. 利用权限打开数据库2. 输入查询的配件编号、规格、名称等信息3. 读取近期销售记录4. 读取原有配件库存量1. 核对配件信息和原有配件库存量2. 核查近期销售记录情况 3. 处理过程出错信息当前零库存量配件处理当前库存量详细处理1. 将合格标志送回上一级调用模式2. 将核对的记录记入文件3. 输出销售库存的当前查询结果文件图10-3 库存查询IPO图库存查询IPO图表示了库存查询管理模块，讲述了如何核对配件信息和原有配件库存量，核查近期销售记录情况以及对出错信息的处理。暂存订单输入C.2.1C.2配件采购管理C.2.2暂存订单处理C.2.3配件入库图9-3 层次化配件采购管理模块结构图模块名称：暂存订单处理系统使用单位：采购部输入部分 I处理描述 P输出部分 O1. 利用权限打开数据库2. 输入暂存订货单配件信息： 编号、规格、名称、暂缺数量等3. 读取供应商列表信息1. 核查暂存订货单配件汇总信息2. 核对暂存配件和相应的供应商列表3. 处理过程1. 将合格标志送回上一级调用模式2. 将核对的记录记入文件3. 修改供应商列表信息4. 输出以供应商分类的采购订货单出错信息按配件汇总处理按供应商汇总处理图10-4 暂存订单处理IPO图暂存订单处理IPO图表示了暂存订单管理模块，讲述了如何核查暂存订单配件汇总信息，核对暂存配件和相应的供应商的列表等处理过程。模块名称：配件入库处理系统使用单位：采购部输入部分 I处理描述 P输出部分 O1. 利用权限打开数据库2. 上组中输出的采购订货单信息3. 输入供应商发货信息4. 读取原库存量信息5. 读取标准配件质量信息1. 核对采购订货单和发货单信息2. 核对发货配件质量信息和标准配件 质量信息3. 处理过程出错信息核对出错质量不合格不合格配件处理合格配件入库处理1. 将合格标志送回上一级调用模式2. 将核对记录记入文件3. 修改库存量信息4. 修改应付款明细帐图10-5 配件入库处理IPO图配件入库处理IPO图表示了配件管理模块，讲述了如何核对采购订货单合法货单信息，核对发货配件质量信息和标准配件质量信息等功能。第五章 系统设计总结第一节 项目实施中各个工作流程及时间分布1 项目开发的编写 1天2 业务流程图设计 2天3 数据流程图设计 1天4 E-R图设计 1天5 U/C矩阵设计 2天6 HIPO图设计 2天7 文档修改、定稿 1天第二节 本人系统设计特点1 优点：本系统具有较强的直观性，设计完整，能较好的体现系统的设计构思；缺点：设计的有些方面有点简单，有很多地方还需进一步分析改进。 目 录前言1第一部分 项目管理与计划1实验1 制定项目计划1实验2 项目可行性分析1第二部分 系统分析1实验3 项目需求收集1实验4 用例建模1实验5 通过用例获取概念数据模型1实验6 将概念数据模型转换为对象关系模型1实验7 分析类图建模（序列图、交互图、状态图、活动图）1实验8 确定设计方案（*）1第三部分 系统设计1实验9 物理数据库设计1实验10 确定系统构架等设计元素、设计类图建模1实验11 界面设计1第四部分 系统实现1实验12 系统实现代码（*）1附录：项目成员分工情况1备注：*为选做实验。第一部分实验一：制定项目计划实验二：制定项目计划从经济上分析项目的可行性一、 投资成本印第安汉堡餐品预定系统在投资成本上包括两方面，一次性成本和续生成本。一次性成本包括基建投资和其他一次性投资，具体是指与项目活动、系统开发和系统启用有关的费用，包括在该信息系统开发过程中全部一次性投入，如系统开发、新硬件和软件的采购，用户培训、站点准备、数据或系统转化。根据搜集到的资料显示，印第安汉堡的餐品预定系统的一次性成本如下所示：（1） PC机：2台，5000*2=10000元（2） Microsoft SQL Server 2005（1套）：5000元（3） Microsoft Server2008（1套）：10000元（4） 打印机1台：1000元（5） 人员培训：7人/2000元，合计14000元总计：本系统开发的一次性投入为40000元，并且新系统需在6个月内实现。经常性支出是指由于正在进行的系统演化和使用而产生的费用，例如应用软件维护、逐渐增加的数据存储费用、增加的沟通、新软件和硬件租借以及消费用品和其他支出等。根据搜集到的资料显示，在印第安汉堡的餐品预定系统中，这种经常性投入表现为续生成本，并且需要连续投资5年，具体如下所示：（1） 预定系统的维护：1000元/年*5年=5000元（2） 每年增加的数据存储费用：5000元/年*5年=25000元（3） 消费用品支出：800元/年*5年=4000元（4） 其他支出：1000元/年*5年=5000元综上可得，印第安汉堡的餐品预定系统为15000美元/年，折算为现值为96862元。具体如下图所示。（贴现率为10%时）二、 投资收益由于我们的系统结构较为简单，功能单一，初期投入后利润也不会有太多。我们同样将系统运行后的投资收益分为一次性收益和经常性收益。根据预测，印第安汉堡的餐品预定系统的投资收益如下所示：1 一次性收益：无。2 经常性收益：（1）由于系统的改进而增加的收益：2000元/年*5=10000元（2）市场占有率的提高而增加的收益（假设市场占有率以每年10%增加）1000+1000*（1+10%）1+1000*（1+10%）2+1000*（1+10%）3+1000*（1+10%）4+1000*（1+10%）5=7716元（3）效率的提高：1000元/年*5=5000元（4）不可定量的其他收益：5年共2284元开发该订餐系统，当其投入运行后，每年的净收益为25000元，再考虑货币的时间价值，系统每年的净收益如下所示。（贴现率为10%时）综上可知，五年内系统的总收益为94770美元。三、 成本/收益分析通过上述成本收益的分析可知，当贴现率为10%时，新开发的信息系统总成本为96862元，总收益为94770元。由于总成本是大于总收益的，所以系统越运行，越亏损，该信息系统不具备经济上的可行性。我们调整贴现率可知，当贴现率为5%时，系统具有经济上的可行性。（贴现率为5%）总成本为104942美元。总收益为108237美元。（贴现率为5%）成本收益分析（1） 投资回收期为第4.58年。（2） 投资回报率为3.14%（3） 净收益108237美元-104942美元=3295美元。从经济上考虑，当贴现率为5%是，新系统在经济上具有可行性。第二部分实验三：项目需求收集我们选择访谈的形式进行需求收集，分别对顾客、服务员、厨师进行提问，以下是我们设计的问题针对顾客：1 您更偏重哪种口味的汉堡 饮料 冰淇淋2 能说一下汉堡 饮料 冰淇淋与季节的关系吗3 您希望多长时间拿到您的定餐4 您一般什么时候来店里消费5 您希望我们店通过什么方法实现个性化推荐，发传单 贴海报 咨询服务员针对服务员：1 一天中什么时候是消费的最高峰2 你觉得什么样的界面操作比较方面3 你觉得系统存在什么样的问题4 您对系统有什么样的改进意见5 您觉得订餐系统对企业带了的效益体现在哪里针对厨师：1 您希望多长时间来准备汉堡 饮料 冰淇淋2 现在一天大约做多少汉堡 饮料 冰淇淋 （库存的要求）3 对这个系统您最不喜欢的是什么4 您对订餐系统在缺货处理上有怎样的评价5 您觉得订餐系统对你的工作有何帮助最可能得到的文档是访谈记录，最不可能得到的文档是观察笔记实验四：用例建模我们为印第安汉堡构建的信息系统主要是为了方便客户点餐以及管理员及时进行库存控制，以减少顾客在点餐和取餐时的时间开销，为印第安汉堡赢取更大的利益。一、印第安汉堡点餐系统的用例图如下所示。二、印第安汉堡点餐系统的用例描述1.顾客通过印第安汉堡的点餐系统生成订单的用例描述用例名称：生成订单简要说明：电话订餐接线员或者前台接到顾客的订单，生成订单一式三联。参与者：电话订餐接线员或者前台前置条件：顾客的订餐需求是有效的后置条件：生成正确的订单，包括顾客的姓名、电话、住址以及订单编号 等基础内容。假设条件：电话订餐接线员或者前台已经成功登录订餐系统基本操作流程：（1）接线员或者前台接收到顾客的有效订餐（2）在订餐系统中输入顾客需求的餐品名称进行查询，比对顾客对餐品的需求量和库存量。（3）在库存充足的条件下，点击进入目标餐品的预订页面，要求顾客报送姓名、电话及住址信息，点击“确认按钮”生成订单，此项操作只针对电话订餐接线员，如为前台订餐，直接在库存充足的情况下，点击“确定”按钮生成订单一式三联即可。（4）系统将顾客的订单信息写入数据库，以进行库存管理。可选操作流程：（1）顾客有信息输入错误的，前台人员不予以确认原错误订单，再按照顾客的正确信息重新生成订单即可。（2）顾客在订餐过程中临时决定退订的，操作如“顾客信息输入有误”同样处理。2.管理员对数据库中的订单进行管理的用例描述用例名称：订单管理简要说明：由后台管理员对已经生成的订单进行查询和删除参与者：后台管理员前置条件：点餐系统中存在业已生成的订单后置条件：显示订单信息、删除相应的订单假设条件：后台管理员使用特殊账号正确登录到点餐系统基本操作流程：(1) 后台管理员输入需要查询的订单编号，也可以通过顾客名称、电话号码等进行订单查询。(2) 当后台管理员接到顾客的退订申请时，查询到相应的订单，进行删除操作，并及时通知其他有关部门。(3) 后台管理员实时查询库存量，向有关部门报告，进行有效的库存控制。可选操作流程：对于餐品已经送出后接到顾客退订申请的，及时删除相应的订单。3.后台管理员对餐品进行管理用例描述用例名称：餐品管理简要说明：后台管理员根据公司业务发展的需要对点餐系统中供应的餐品进行增、删、该操作。参与者：后台管理员前置条件：点餐系统中确实存在需要修改的餐品信息后置条件：显示更新后的餐品信息假设条件：后台管理员使用特殊账号正确登录到点餐系统基本操作流程：(1) 后台管理员在主页面上点击“增加餐品”按钮，进入增加餐品的二级页面，填写相应信息，完成餐品增加操作。(2) 后台管理员在主页上输出查询条件，选择出需要修改的餐品（一般是餐品价格的修改），点击餐品图片进入二级页面， 完 成对餐品的修改操作。(3) 后台管理员在主页上输出查询条件，选择出需要删除的餐品，点击餐品图片右下方的“删除，”完成对餐品的删除操作。可选操作流程：增加餐品的前提是库存不为零，库存超过一定数量的餐品系统显示不能删除餐品信息。4.印第安汉堡点餐系统对库存量进行管理的用例描述用例名称：库存控制简要说明：系统根据订单的数量和内容减少相应的库存量。参与者：后台管理员前置条件：系统中存在一些已经生成的订单后置条件：库存量作相应的变动假设条件：后台管理员使用特殊账号正确登录到点餐系统基本操作流程：(1) 系统根据已经确认的订单中餐品名称和餐品数量做相应库存量的减少。每销售出去一个餐品，库存数据库中对应餐品的库存量相应的减一。(2) 系统显示每种餐品剩余库存量以便管理员及时同有关部门协调，增加相应餐品的供给。可选操作流程：库存量为零时，系统提示不能进行相应的库存减少的操作。5送货员向顾客供应订货的用例描述用例名称：供应订货简要说明：送货员凭借其中一份订单与顾客钱货两清，完成整个订餐过程参与者： 送货员前置条件：顾客完成“点餐”用例，且餐品未送达。后置条件：交易完成，删除相应订单假设条件：顾客提交了有效的点餐需求基本操作流程： (1) 送货员凭借订单与顾客完成交易后，向有关管理部门提示“送货成功”。(2) 系统根据订单中的餐品名称和餐品数量作相应库存量的减少。可选操作流程：如果交易不成功的话，送货员应及时提醒后台管理员，后台管理员应及时删除相应订单。实验五：通过用例获取概念数据模型概念数据模型是对组织数据的描绘，它以一种独立于现实的方式说明了数据的结构和数据之间的相互关系。本次实验通过对前面用例进行分析，并结合我们订餐系统的功能和需求，建立概念数据模型，具体步骤如下：1、标识用例中的类通过观察用例并结合实际分析，我们可以抽象出以下几个类：Admin（管理员），Order（订单），Customer（顾客），Product（产品），以及关联类Lineitem（订单行项目）。2、确定每一个类的属性 用例中没有提供关于属性的所有详细资料，因此我查看了与“订单”用例相关文档，并结合本系统的功能需求，将属性分配到类。Admin（管理员）：AdminId（管理员号），AdminName（管理员姓名），AdminPsd（管理员密码），AdminType（管理员类型）Order（订单）：OrderId（订单号），OrderDate（订单时间），SubTotal（小计），TotalAmount（总数量），Customer（顾客）：CustId（顾客号），CustomerName（顾客姓名），CustPhone（顾客电话）CustAddress（顾客地址）Product（产品）：ProId（产品号），ProName（产品名称）， ProPrice（产品单价），ProPicture（产品图片），ProAbstract（产品介绍），ProAmount（产品库存）LineItem（订单行项目）：Quantity（数量），ActualPrice（实际价格），LineAmount（项目总数量）3、确定标识符即选择一个属性作为这个类的唯一标识符。在此我们选择AdminId（管理员号）、OrderId（订单号、CustId（顾客号）、ProId（产品号）为标识符4、考虑属性的性质在此，除了普通的属性以外，我们认为顾客联系方式应除了常用的一个以外，至少一个备用，所以CustPhone（顾客电话）为多值属性，订单的ubTotal（小计），TotalAmount（总数量），产品的ProAmount（产品库存）可由其他数据确定，应为导出属性。5、属性与属性之间的关系通过分析我们可以知道，一个顾客可以下多个订单，一个订单只能对应一个顾客购买；一个管理员（前台）可以处理多个订单，但每个订单对应一个管理员，因此Customer和Order，Asmin和Order的关系是一对一的。每个订单可包含多种产品，每个产品可以包括在不同的订单里，因此Product和Order为多对多的关系，用关联类LineItem来表示。6、建立概念数据模型 综上所述，我们建立的概念数据模型如下图所示：实验六：将概念数据模型转换为对象关系模型对象关系数据模型是带有面向对象扩充的关系数据模型，以关联表或关系的形式描绘数据。本次实验基于前面概念数据模型的建立，将其转化为对象关系，接着将所有关系合并为最终的、综合的一组关系，其步骤如下：1、将类转化为对象关系类的标识符成为该对象关系的主键，类的其他属性成为该对象关系的非主键属性。则对象关系如下：Admin（AdminId，AdminName，AdminPsd，AdminType）Order（OrderId，OrderDate，<<Derived>>SubTotal，<<Derived>>TotalAmount）Customer（CustId，CustomerName，<<Multivalued>>CustPhone，CustAddress）Product（ProId，ProName， ProPrice，ProPicture，ProAbstract，<<Derived>>ProAmount）2、为1：n关系安排外键在此系统中，有两个一对多的关系，根据将1方的主键增加为n方的外键，则order关系将被修改为包含CustId 和AdminId，作为外键。Order（OrderId，CustId，AdminId，OrderDate，<<Derived>>SubTotal，<<Derived>>TotalAmount）3、最后转化关联类 在Order和Product之间有一关联类LineItem，其可映像为对象关系，并用两个类的主键OrderId 和ProId的组合作为他的主键。LineItem（OrderId ，ProId ，Quantity，ActualPrice，LineAmount）4、规范化关系对象，进一步细化由于Customer允许通过接收多值属性违背了第一范式，因而Customer不是一个良构关系，而是一个对象关系，又因为我们进一步讨论决定接收纯粹的关系模型，因此将Customer分为关系，为：Customer（CustId，CustomerName， CustAddress）CustPhone（CustId，CustPhone）5、对象关系模型 经过一步步的细化，我们产生了6个对象类，导出的对象关系模型如下：Admin（AdminId，AdminName，AdminPsd，AdminType）Order（OrderId，CustId，AdminId，OrderDate，<<Derived>>SubTotal，<<Derived>>TotalAmount）LineItem（OrderId ，ProId ，Quantity，ActualPrice，LineAmount）Product（ProId，ProName， ProPrice，ProPicture，ProAbstract，<<Derived>>ProAmount）Customer（CustId，CustomerName， CustAddress）CustPhone（CustId，CustPhone）实验七：分析类图建模这一部分通过图对系统进行描述1.顺序图：交互图是帮助在一个用例的分析类之间分配责任并说明类对象之间的相互交互的图，常用的交互图的类型是顺序图，它以时间顺序的方式说明类的对象之间的交互。下图为按照指导原则描绘的“预订”用例的顺序图：图中详细描述了“预定”用例的顺序图：参与者：Customer选择一个或多个产品调用该用例，这个消息/select item（选择产品项）表明，它被传给：OrderForm。表单将信息传递给控制对象：OrderControl，于是创建订单。控制对象将创建新订单的责任传给了：Order，：Order创建一个新订单。类似的，控制将增加一个项目的责任传递给了：LineItem。它来创建一个新的项目。或者，：Order对象可以负责增加：LineItem对象。2.活动图： 活动图和顺序图相似，但两个图的重点不同，顺序图在于说明一个程序中的控制流，而活动图说明系统中活动到活动的控制流，什么活动可以并行进行，和任何通过流的可选路径。 “预定”用例的活动图： 子流程同步的活动图： 3.状态图： 状态图通过制定一个对象在自己的生存期间响应时间而经历的状态序列以及对这些事件的响应来描述对象的行为。一个对象的状态是在对象生存期间的一个条件或情况，在这个时间它满足某些条件，执行某些活动或等待某些事件。可以认为对象的活动图是状态图的一个特例。 例如， 对象订单的状态经历创建、供应、完成，它的状态图如下： 4.分析类图： 分析类图说明分析类和这些类之间的关系，有两种关系结构关系和行为关系，结果方面从数据建模中可以获得，分析类图的行为方面可以从顺序图或通信图导出。下图是“预订”用例的一个分析类图：Order<<Primary>>