信息系统分析与设计实验报告1Word格式文档下载.docx
《信息系统分析与设计实验报告1Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《信息系统分析与设计实验报告1Word格式文档下载.docx（29页珍藏版）》请在冰点文库上搜索。
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个对象类，导出的对象关系模型如下：
实验七：
分析类图建模
这一部分通过图对系统进行描述
1.顺序图：
交互图是帮助在一个用例的分析类之间分配责任并说明类对象之间的相互交互的图，常用的交互图的类型是顺序图，它以时间顺序的方式说明类的对象之间的交互。
下图为按照指导原则描绘的“预订”用例的顺序图：
图中详细描述了“预定”用例的顺序图：
Customer选择一个或多个产品调用该用例，这个消息//selectitem（选择产品项）表明，它被传给：
OrderForm。
表单将信息传递给控制对象：
OrderControl，于是创建订单。
控制对象将创建新订单的责任传给了：
Order，：
Order创建一个新订单。
类似的，控制将增加一个项目的责任传递给了：
LineItem。
它来创建一个新的项目。
或者，：
Order对象可以负责增加：
LineItem对象。
2.活动图：
活动图和顺序图相似，但两个图的重点不同，顺序图在于说明一个程序中的控制流，而活动图说明系统中活动到活动的控制流，什么活动可以并行进行，和任何通过流的可选路径。
“预定”用例的活动图：
子流程同步的活动图：
3.状态图：
状态图通过制定一个对象在自己的生存期间响应时间而经历的状态序列以及对这些事件的响应来描述对象的行为。
一个对象的状态是在对象生存期间的一个条件或情况，在这个时间它满足某些条件，执行某些活动或等待某些事件。
可以认为对象的活动图是状态图的一个特例。
例如，对象订单的状态经历创建、供应、完成，它的状态图如下：
4.分析类图：
分析类图说明分析类和这些类之间的关系，有两种关系——结构关系和行为关系，结果方面从数据建模中可以获得，分析类图的行为方面可以从顺序图或通信图导出。
下图是“预订”用例的一个分析类图：
第三部分
实验八：
物理数据库设计
物理数据库设计是对系统存储结构和存取方法等依赖于具体计算机结构的各项物理设计措施的设计，涉及访问的效率考虑因素比如响应时间和事务吞吐量，本实验旨在确保用户在运行查询时不必等待不合理的时间，从而有效执行任务。
1、关系对象属性特性描述
在实验六中，我们的到如下的对象关系
根据上述对象关系，结合逻辑数据模型以及实际情况，分析了各个属性的特征，如数据类型、设计域、数据的完整性（默认值、是否为空、控制范围、参照完整性）等，具体涉及如下表所示：
Customer
字段名
数据类型
是否允许为空
键或索引
说明
CustID
Int（20）
否
主键
唯一；
系统自动赋予
CustTomerName
Nvarchar（30）
CustAddres
CustPhone
参照顾客表
唯一
Admin
AdminID
AdminPsd
Int（30）
长度大于6
AdminName
AdminType
Nuem
分为前台管理员、电话预定员、系统管理员
Order
OrderID
参照管理员表
OrderDate
datetime
系统自动生成
SubTotal
Numeric（18,2）
根据LineItem表生成
TotalAmount
Int
是
LineItem
Int（10）
参照订单表
ProId
参照产品表
Quantity
ActualPrice
LineAmount
Product
ProName
Nvarchar（50）
]
ProPrice
Numeric（8,2）
ProPictur
Image
ProAbstract
Ntest
非空
ProAmount
参照留言表
2、物理数据库文件组织及索引设计
根据实际情况和需求分析，我们估计了表的行的大小和数目如下图所示。
表名
行对象数目
每个行对象的字节数
2000
200
5000000
100
10000000
40
Product
4000
500000
1000000
50
我们假设选择的块大小是由4000个可用字节的4k（4096个字节）。
在Admin表的例子中，分块因子4000/200。
Admin表的大小是2000/20。
Admin表的扫描时间是100*2.5ms为0.25s。
类似的可以算出其余几个表的计算如下图
每行字节数
分块因子
（BF）
块数
扫描时间
（秒）
是否需要索引
20
0.25
125000
312.5
100000
250
0.5
25000
62．5
80
12500
31.25
上面的计算表明
1）索引这六个表的6个主键——AdminId、OrderId、（OrderId，ProId）、ProId、CustId、（CustId，CustPhone）。
主键一般是最常被访问的属性。
2）可将Admin和Product存储在数据库服务器的高速缓冲去。
即使没有被缓存，扫描时间也只不过0.25s和5s，没有必要索引除了主键之外的任何属性。
3）Order、LineItem、Customer和CustPhone是大表，并且需要索引来加快查询的速度
升级会员 