汽车销售管理系统分析设计Word文件下载.docx
《汽车销售管理系统分析设计Word文件下载.docx》由会员分享，可在线阅读，更多相关《汽车销售管理系统分析设计Word文件下载.docx（52页珍藏版）》请在冰点文库上搜索。
图2组织/业务关系图
第三节业务功能一览表
图3业务功能一览表
第四节业务流程图
收据
图4业务流程图
第五节数据流程图
纠正错误
不合格订单
发订单合格订单不满足
订货
检索
满足订货
有新顾客
修改
开发货单
通知
记录记录
图5-1销售过程数据流图
确定
给采购人员发货单
发出到货通知
记录对照暂存订单
记录产生
开出
发货
图5-2采购过程数据流图
给顾客收据开出
现金支票转账无误
给会计发货单
无误
修改提供依据
提供依据
提交编制
提交编制
图5-3财务过程数据流图
第六节系统数据库建模----E-R模型分析
1N
1
N
N1111
11
N1NN
N11NN
1N
NMMN
N11N
图6-1E-R图
图6-2E-R图
第七节系统U/C矩阵分析
功能
数据类
顾客数据
发货单
应收款账目
销售历史
暂存订单
公司订单
到货通知
应付款账目
收付单据
会计总账
报表
库存
销售管理
客户管理
C
U
销售配件
记录业务
采购管理
记录缺货
追加订货
验货入库
收付款
会计核算
编制报表
监督管理
图7U/C矩阵
第三章汽车销售管理信息系统的系统设计
第一节功能子系统划分
根据U/C矩阵分析，对汽车配件公司业务管理信息系统进行功能子系统划分，
如图8所示。
本系统只要花分为四个功能子系统：
图8系统功能子系统图
销售管理子系统：
对客户数据、订货处理等销售业务进行管理；
财务管理子系统：
负责各种报表和账目的管理工作；
采购管理子系统：
管理供应商信息，进行采购、收货、验货等采购业务；
库存管理子系统：
对仓库存货进行管理和监督。
第二节层次化模块结构图
汽车配件公司业务管理信息系统中，模块划分和处理过程设计是非常关键的一步，因此，我本着对系统可修改性、易读性、易查错性等方面进行设计。
基本思想是：
1、模块化；
2、图表文字解说。
其中，HIPO图是一种强有力的描述系统机构和模块内部处理功能的工具，它主要包括层次结构图和IPO图两个部分。
层次结构图描述了整个系统的设计结构以及各类模块之间的关系；
IPO图则描述了在某个特定模块内部的输入（I）、处理过程（P）、输出（O）思想。
图9-1层次化结构模块图
层次化结构模块图是从结构化设计的角度提出的一种工具。
汽车配件公司业务管理信息系统的模块化分为若干子系统，如销售管理子系统、采购管理子系统等，它们之间是平级关系，并且，相互之间也不交叉。
同时，一个模块还下分了子模块，如销售管理子系统下面包含了客户管理和订货管理两个子模块。
这样，从整体上来划分，形成从全局来进行管理的格局。
图9-2层次化订货管理模块结构图
图10-1订单输入IPO图
订单输入IPO图表示了订单输入模块，讲述了如何输入客户订单，检查其正确性，核对建立新的账号等功能。
图10-2订单处理IPO图
订单处理IPO图表示了订单处理模块，讲述了如何核对处理订单，对库存量和订单进行比较处理等功能。
图10-3库存查询IPO图
库存查询IPO图表示了库存查询管理模块，讲述了如何核对配件信息和原有配件库存量，核查近期销售记录情况以及对出错信息的处理。
图9-3层次化配件采购管理模块结构图
图10-4暂存订单处理IPO图
暂存订单处理IPO图表示了暂存订单管理模块，讲述了如何核查暂存订单配件汇总信息，核对暂存配件和相应的供应商的列表等处理过程。
图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）MicrosoftSQLServer2005（1套）：
5000元
（3）MicrosoftServer2008（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）其他支出：
综上可得，印第安汉堡的餐品预定系统为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元，再考虑货币的时间价值，系统每年的净收益如下所示。
综上可知，五年内系统的总收益为94770美元。
三、成本/收益分析
通过上述成本收益的分析可知，当贴现率为10%时，新开发的信息系统总成本为96862元，总收益为94770元。
由于总成本是大于总收益的，所以系统越运行，越亏损，该信息系统不具备经济上的可行性。
我们调整贴现率可知，当贴现率为5%时，系统具有经济上的可行性。
（贴现率为5%）
总成本为104942美元。
总收益为108237美元。
成本收益分析
（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，<
TotalAmount）
Customer（CustId，CustomerName，<
Multivalued>
CustPhone，CustAddress）
Product（ProId，ProName，ProPrice，ProPicture，ProAbstract，<
ProAmount）
2、为1：
n关系安排外键
在此系统中，有两个一对多的关系，根据将1方的主键增加为n方的外键，则order关系将被修改为包含CustId和AdminId，作为外键。
Order（OrderId，CustId，AdminId，OrderDate，<
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个对象类，导出的对象关系模型如下：
Product（ProId，ProName，ProPrice，ProPicture，ProAbst
升级会员 