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备注：*为选做实验。第一部分实验一：制定项目计划实
2、验二：制定项目计划从经济上分析项目的可行性一、投资成本印第安汉堡餐品预定系统在投资成本上包括两方面，一次性成本和续生成本。一次性成本包括基建投资和其他一次性投资，具体是指与项目活动、系统开发和系统启用有关的费用，包括在该信息系统开发过程中全部一次性投入，如系统开发、新硬件和软件的采购，用户培训、站点准备、数据或系统转化。根据搜集到的资料显示，印第安汉堡的餐品预定系统的一次性成本如下所示：（1）PC机：2台，5000*2=10000元（2）Microsoft SQL Server 2005（1套）：5000元（3）Microsoft Server2008（1套）：10000元（4）打印机1台：1
3、000元（5）人员培训：7人/2000元，合计14000元总计：本系统开发的一次性投入为40000元，并且新系统需在6个月内实现。经常性支出是指由于正在进行的系统演化和使用而产生的费用，例如应用软件维护、逐渐增加的数据存储费用、增加的沟通、新软件和硬件租借以及消费用品和其他支出等。根据搜集到的资料显示，在印第安汉堡的餐品预定系统中，这种经常性投入表现为续生成本，并且需要连续投资5年，具体如下所示：（1）预定系统的维护：1000元/年*5年=5000元（2）每年增加的数据存储费用：5000元/年*5年=25000元（3）消费用品支出：800元/年*5年=4000元（4）其他支出：1000元/年*
4、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*（
5、1+10%）4+1000*（1+10%）5=7716元（3）效率的提高：1000元/年*5=5000元（4）不可定量的其他收益：5年共2284元开发该订餐系统，当其投入运行后，每年的净收益为25000元，再考虑货币的时间价值，系统每年的净收益如下所示。（贴现率为10%时）综上可知，五年内系统的总收益为94770美元。三、成本/收益分析通过上述成本收益的分析可知，当贴现率为10%时，新开发的信息系统总成本为96862元，总收益为94770元。由于总成本是大于总收益的，所以系统越运行，越亏损，该信息系统不具备经济上的可行性。我们调整贴现率可知，当贴现率为5%时，系统具有经济上的可行性。（贴现率为5
6、%）总成本为104942美元。总收益为108237美元。（贴现率为5%）成本收益分析（1）投资回收期为第4.58年。（2）投资回报率为3.14%（3）净收益108237美元-104942美元=3295美元。从经济上考虑，当贴现率为5%是，新系统在经济上具有可行性。第二部分实验三：项目需求收集我们选择访谈的形式进行需求收集，分别对顾客、服务员、厨师进行提问，以下是我们设计的问题针对顾客：1 您更偏重哪种口味的汉堡 饮料 冰淇淋2 能说一下汉堡 饮料 冰淇淋与季节的关系吗3 您希望多长时间拿到您的定餐4 您一般什么时候来店里消费5 您希望我们店通过什么方法实现个性化推荐，发传单 贴海报 咨询服务员
7、针对服务员：1 一天中什么时候是消费的最高峰2 你觉得什么样的界面操作比较方面3 你觉得系统存在什么样的问题4 您对系统有什么样的改进意见5 您觉得订餐系统对企业带了的效益体现在哪里针对厨师：1 您希望多长时间来准备汉堡 饮料 冰淇淋2 现在一天大约做多少汉堡 饮料 冰淇淋 （库存的要求）3 对这个系统您最不喜欢的是什么4 您对订餐系统在缺货处理上有怎样的评价5 您觉得订餐系统对你的工作有何帮助最可能得到的文档是访谈记录，最不可能得到的文档是观察笔记实验四：用例建模我们为印第安汉堡构建的信息系统主要是为了方便客户点餐以及管理员及时进行库存控制，以减少顾客在点餐和取餐时的时间开销，为印第安汉堡赢
8、取更大的利益。一、印第安汉堡点餐系统的用例图如下所示。二、印第安汉堡点餐系统的用例描述1.顾客通过印第安汉堡的点餐系统生成订单的用例描述用例名称：生成订单简要说明：电话订餐接线员或者前台接到顾客的订单，生成订单一式三联。参与者：电话订餐接线员或者前台前置条件：顾客的订餐需求是有效的后置条件：生成正确的订单，包括顾客的姓名、电话、住址以及订单编号 等基础内容。假设条件：电话订餐接线员或者前台已经成功登录订餐系统基本操作流程：（1）接线员或者前台接收到顾客的有效订餐（2）在订餐系统中输入顾客需求的餐品名称进行查询，比对顾客对餐品的需求量和库存量。（3）在库存充足的条件下，点击进入目标餐品的预订页面
9、，要求顾客报送姓名、电话及住址信息，点击“确认按钮”生成订单，此项操作只针对电话订餐接线员，如为前台订餐，直接在库存充足的情况下，点击“确定”按钮生成订单一式三联即可。（4）系统将顾客的订单信息写入数据库，以进行库存管理。可选操作流程：（1）顾客有信息输入错误的，前台人员不予以确认原错误订单，再按照顾客的正确信息重新生成订单即可。（2）顾客在订餐过程中临时决定退订的，操作如“顾客信息输入有误”同样处理。2.管理员对数据库中的订单进行管理的用例描述用例名称：订单管理简要说明：由后台管理员对已经生成的订单进行查询和删除参与者：后台管理员前置条件：点餐系统中存在业已生成的订单后置条件：显示订单信息、
10、删除相应的订单假设条件：后台管理员使用特殊账号正确登录到点餐系统基本操作流程：(1) 后台管理员输入需要查询的订单编号，也可以通过顾客名称、电话号码等进行订单查询。(2) 当后台管理员接到顾客的退订申请时，查询到相应的订单，进行删除操作，并及时通知其他有关部门。(3) 后台管理员实时查询库存量，向有关部门报告，进行有效的库存控制。可选操作流程：对于餐品已经送出后接到顾客退订申请的，及时删除相应的订单。3.后台管理员对餐品进行管理用例描述用例名称：餐品管理简要说明：后台管理员根据公司业务发展的需要对点餐系统中供应的餐品进行增、删、该操作。参与者：后台管理员前置条件：点餐系统中确实存在需要修改的餐
11、品信息后置条件：显示更新后的餐品信息假设条件：后台管理员使用特殊账号正确登录到点餐系统基本操作流程：(1) 后台管理员在主页面上点击“增加餐品”按钮，进入增加餐品的二级页面，填写相应信息，完成餐品增加操作。(2) 后台管理员在主页上输出查询条件，选择出需要修改的餐品（一般是餐品价格的修改），点击餐品图片进入二级页面， 完 成对餐品的修改操作。(3) 后台管理员在主页上输出查询条件，选择出需要删除的餐品，点击餐品图片右下方的“删除，”完成对餐品的删除操作。可选操作流程：增加餐品的前提是库存不为零，库存超过一定数量的餐品系统显示不能删除餐品信息。4.印第安汉堡点餐系统对库存量进行管理的用例描述用例
12、名称：库存控制简要说明：系统根据订单的数量和内容减少相应的库存量。参与者：后台管理员前置条件：系统中存在一些已经生成的订单后置条件：库存量作相应的变动假设条件：后台管理员使用特殊账号正确登录到点餐系统基本操作流程：(1) 系统根据已经确认的订单中餐品名称和餐品数量做相应库存量的减少。每销售出去一个餐品，库存数据库中对应餐品的库存量相应的减一。(2) 系统显示每种餐品剩余库存量以便管理员及时同有关部门协调，增加相应餐品的供给。可选操作流程：库存量为零时，系统提示不能进行相应的库存减少的操作。5送货员向顾客供应订货的用例描述用例名称：供应订货简要说明：送货员凭借其中一份订单与顾客钱货两清，完成整个
13、订餐过程参与者： 送货员前置条件：顾客完成“点餐”用例，且餐品未送达。后置条件：交易完成，删除相应订单假设条件：顾客提交了有效的点餐需求基本操作流程： (1) 送货员凭借订单与顾客完成交易后，向有关管理部门提示“送货成功”。(2) 系统根据订单中的餐品名称和餐品数量作相应库存量的减少。可选操作流程：如果交易不成功的话，送货员应及时提醒后台管理员，后台管理员应及时删除相应订单。实验五：通过用例获取概念数据模型概念数据模型是对组织数据的描绘，它以一种独立于现实的方式说明了数据的结构和数据之间的相互关系。本次实验通过对前面用例进行分析，并结合我们订餐系统的功能和需求，建立概念数据模型，具体步骤如下：
14、1、标识用例中的类通过观察用例并结合实际分析，我们可以抽象出以下几个类：Admin（管理员），Order（订单），Customer（顾客），Product（产品），以及关联类Lineitem（订单行项目）。2、确定每一个类的属性 用例中没有提供关于属性的所有详细资料，因此我查看了与“订单”用例相关文档，并结合本系统的功能需求，将属性分配到类。Admin（管理员）：AdminId（管理员号），AdminName（管理员姓名），AdminPsd（管理员密码），AdminType（管理员类型）Order（订单）：OrderId（订单号），OrderDate（订单时间），SubTotal（小计），To
15、talAmount（总数量），Customer（顾客）：CustId（顾客号），CustomerName（顾客姓名），CustPhone（顾客电话）CustAddress（顾客地址）Product（产品）：ProId（产品号），ProName（产品名称）， ProPrice（产品单价），ProPicture（产品图片），ProAbstract（产品介绍），ProAmount（产品库存）LineItem（订单行项目）：Quantity（数量），ActualPrice（实际价格），LineAmount（项目总数量）3、确定标识符即选择一个属性作为这个类的唯一标识符。在此我们选择AdminId（管理
16、员号）、OrderId（订单号、CustId（顾客号）、ProId（产品号）为标识符4、考虑属性的性质在此，除了普通的属性以外，我们认为顾客联系方式应除了常用的一个以外，至少一个备用，所以CustPhone（顾客电话）为多值属性，订单的ubTotal（小计），TotalAmount（总数量），产品的ProAmount（产品库存）可由其他数据确定，应为导出属性。5、属性与属性之间的关系通过分析我们可以知道，一个顾客可以下多个订单，一个订单只能对应一个顾客购买；一个管理员（前台）可以处理多个订单，但每个订单对应一个管理员，因此Customer和Order，Asmin和Order的关系是一对一的。每
17、个订单可包含多种产品，每个产品可以包括在不同的订单里，因此Product和Order为多对多的关系，用关联类LineItem来表示。6、建立概念数据模型 综上所述，我们建立的概念数据模型如下图所示：实验六：将概念数据模型转换为对象关系模型对象关系数据模型是带有面向对象扩充的关系数据模型，以关联表或关系的形式描绘数据。本次实验基于前面概念数据模型的建立，将其转化为对象关系，接着将所有关系合并为最终的、综合的一组关系，其步骤如下：1、将类转化为对象关系类的标识符成为该对象关系的主键，类的其他属性成为该对象关系的非主键属性。则对象关系如下：Admin（AdminId，AdminName，AdminP
18、sd，AdminType）Order（OrderId，OrderDate，SubTotal，TotalAmount）Customer（CustId，CustomerName，CustPhone，CustAddress）Product（ProId，ProName， ProPrice，ProPicture，ProAbstract，ProAmount）2、为1：n关系安排外键在此系统中，有两个一对多的关系，根据将1方的主键增加为n方的外键，则order关系将被修改为包含CustId 和AdminId，作为外键。Order（OrderId，CustId，AdminId，OrderDate，SubTot
19、al，TotalAmount）3、最后转化关联类 在Order和Product之间有一关联类LineItem，其可映像为对象关系，并用两个类的主键OrderId 和ProId的组合作为他的主键。LineItem（OrderId ，ProId ，Quantity，ActualPrice，LineAmount）4、规范化关系对象，进一步细化由于Customer允许通过接收多值属性违背了第一范式，因而Customer不是一个良构关系，而是一个对象关系，又因为我们进一步讨论决定接收纯粹的关系模型，因此将Customer分为关系，为：Customer（CustId，CustomerName， CustA
20、ddress）CustPhone（CustId，CustPhone）5、对象关系模型 经过一步步的细化，我们产生了6个对象类，导出的对象关系模型如下：Admin（AdminId，AdminName，AdminPsd，AdminType）Order（OrderId，CustId，AdminId，OrderDate，SubTotal，TotalAmount）LineItem（OrderId ，ProId ，Quantity，ActualPrice，LineAmount）Product（ProId，ProName， ProPrice，ProPicture，ProAbstract，ProAmount）
21、Customer（CustId，CustomerName， CustAddress）CustPhone（CustId，CustPhone）实验七：分析类图建模这一部分通过图对系统进行描述1.顺序图：交互图是帮助在一个用例的分析类之间分配责任并说明类对象之间的相互交互的图，常用的交互图的类型是顺序图，它以时间顺序的方式说明类的对象之间的交互。下图为按照指导原则描绘的“预订”用例的顺序图：图中详细描述了“预定”用例的顺序图：参与者：Customer选择一个或多个产品调用该用例，这个消息/select item（选择产品项）表明，它被传给：OrderForm。表单将信息传递给控制对象：OrderCo
22、ntrol，于是创建订单。控制对象将创建新订单的责任传给了：Order，：Order创建一个新订单。类似的，控制将增加一个项目的责任传递给了：LineItem。它来创建一个新的项目。或者，：Order对象可以负责增加：LineItem对象。2.活动图： 活动图和顺序图相似，但两个图的重点不同，顺序图在于说明一个程序中的控制流，而活动图说明系统中活动到活动的控制流，什么活动可以并行进行，和任何通过流的可选路径。 “预定”用例的活动图： 子流程同步的活动图： 3.状态图： 状态图通过制定一个对象在自己的生存期间响应时间而经历的状态序列以及对这些事件的响应来描述对象的行为。一个对象的状态是在对象生存
23、期间的一个条件或情况，在这个时间它满足某些条件，执行某些活动或等待某些事件。可以认为对象的活动图是状态图的一个特例。 例如， 对象订单的状态经历创建、供应、完成，它的状态图如下： 4.分析类图： 分析类图说明分析类和这些类之间的关系，有两种关系结构关系和行为关系，结果方面从数据建模中可以获得，分析类图的行为方面可以从顺序图或通信图导出。下图是“预订”用例的一个分析类图：第三部分实验八：物理数据库设计 物理数据库设计是对系统存储结构和存取方法等依赖于具体计算机结构的各项物理设计措施的设计，涉及访问的效率考虑因素比如响应时间和事务吞吐量，本实验旨在确保用户在运行查询时不必等待不合理的时间，从而有效
24、执行任务。1、关系对象属性特性描述 在实验六中，我们的到如下的对象关系Admin（AdminId，AdminName，AdminPsd，AdminType）Order（OrderId，CustId，AdminId，OrderDate，SubTotal，TotalAmount）LineItem（OrderId ，ProId ，Quantity，ActualPrice，LineAmount）Product（ProId，ProName， ProPrice，ProPicture，ProAbstract，ProAmount）Customer（CustId，CustomerName， CustAddres
25、s）CustPhone（CustId，CustPhone） 根据上述对象关系，结合逻辑数据模型以及实际情况，分析了各个属性的特征，如数据类型、设计域、数据的完整性（默认值、是否为空、控制范围、参照完整性）等，具体涉及如下表所示：Customer字段名数据类型是否允许为空键或索引说明CustIDInt（20）否主键唯一；系统自动赋予CustTomerNameNvarchar（30）否CustAddresNvarchar（30）否CustPhone字段名数据类型是否允许为空键或索引说明CustIDInt（20）否主键参照顾客表CustPhoneNvarchar（30）否主键唯一Admin字段名数据
26、类型是否允许为空键或索引说明AdminIDInt(20)否主键唯一；系统自动赋予AdminPsdInt(30)否唯一；长度大于6AdminNameNvarchar（30）否AdminTypeNuem否分为前台管理员、电话预定员、系统管理员Order字段名数据类型是否允许为空键或索引说明OrderIDInt(20)否主键唯一；系统自动赋予CustIDInt（20）否参照顾客表AdminIDInt(20)否参照管理员表 OrderDatedatetime否系统自动生成SubTotalNumeric(18,2)否根据LineItem表生成TotalAmountInt是根据LineItem表生成Lin
27、eItem字段名数据类型是否允许为空键或索引说明OrderIDInt(10)否主键参照订单表ProIdInt(20)否主键参照产品表QuantityInt（10）否ActualPrice Numeric(18,2)否LineAmountNumeric(18,2)否系统自动生成Product 字段名数据类型是否允许为空键或索引说明ProIdInt(20)否主键唯一；系统自动赋予ProNameNvarchar(50)否唯一ProPrice Numeric(8,2)否ProPicturImage否唯一ProAbstractNtest否唯一；非空ProAmountNtest是参照留言表2、物理数据库文
28、件组织及索引设计根据实际情况和需求分析，我们估计了表的行的大小和数目如下图所示。表名行对象数目每个行对象的字节数Admin2000200Order5000000100LineItem1000000040Product4000200Customer500000200CustPhone100000050我们假设选择的块大小是由4000个可用字节的4k（4096个字节）。在Admin表的例子中，分块因子4000/200。Admin表的大小是2000/20。Admin表的扫描时间是100*2.5ms为0.25s。类似的可以算出其余几个表的计算如下图表名行对象数目每行字节数分块因子（BF）块数扫描时间（
29、秒）是否需要索引Admin2000200201000.25否Order500000010040125000312.5是LineItem1000000040100100000250是Product4000200202000.5否Customer5000002002025000625是CustPhone100000050801250031.25是上面的计算表明1）索引这六个表的6个主键AdminId、OrderId、（OrderId ，ProId）、ProId、CustId、（CustId，CustPhone）。主键一般是最常被访问的属性。2）可将Admin和Product存储在数据库服务器的高速缓冲去。即使没有被缓存，扫描时间也只不过0.25s和5s，没有必要索引除了主键之外的任何属性。3）Order、LineItem、Customer和CustPhone是大表，并且需要索引来加快查询的速度
