- 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
- 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
- 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
- 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们。
- 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
- 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
2. 分析用户需求 3. 编写需求文档 4. 评审需求文档 5.管理需求文档 11.2 学生成绩管理系统设计 1. 系统功能分析 2. 系统结构分析 3.系统所需界面 11.2.2 数据库与表的设计 1.登录界面设计 2.主菜单设计 3.主程序设计 2. 权限认证表单设计 第一步:在“项目管理器”中设计完成相应的数据库、数据表、各种应用界面、菜单以及主控程序main.prg,并将main.prg设置为主文件; 第二步:生成可执行文件。 11.2.8 学生成绩管理系统生成 11.2.9 学生成绩管理系统的发布 1. 将程序和数据集中在一个目录中; 2. 创建发布目录; 3. 指定发布树目录; 4. 选定发布程序中所应包含的系统组件; 5. 设置磁盘映像目录和规格; 6. 设置安装选项; 7. 设置软件安装目录和组名; 8. 设置文件位置。 11.3 车站售票管理系统设计 C/S模式的基本概念 系统功能设计 数据库设计 软件封面设计 系统主界面设计 订购票窗体设计 查询和退票窗体设计 售票收入统计窗体设计 将数据库升迁到SQL Server 售票管理系统生成 售票管理系统的发布 1. C/S结构的定义; 2. C/S结构的特点: (1)可靠的数据完整性和安全性控制; (2)高效的联机事务处理性能; (3)良好的开放性和易扩充性; (4)高效的应用程序开发。 11.3.1 C/S模式的基本概念 本系统设计主要包括包括售票子系统、订票子系统、查询子系统以及列车时刻表等,其中售票子系统与订票子系统至少应满足以下几个方面的要求: 1. 每一车次乘客乘车的起始点、终点、日期以及可以预订的座位号等基本信息。 2. 显示乘客要求的车次及座位号是否已售出。 3. 查询每一车次的售票、订票情况以及售票收入的统计。 4. 按多种方式查询列车时刻信息表。 车站售票管理系统的基本结构设计如图11-14所示。 11.3.2 系统功能设计 车站售票管理系统主要用于车站售票信息管理,车站售票管理系统数据库包括车次信息数据表、订票数据表、车次座位等级分配及座位占用表、以及用户信息表。 1. 车次信息表(编号、始发站、终点站、发车时间、到达时间) 2. 订票信息表(车次编号、始发站、发车时间、发车日期) 3. 座位等级分配表用于在系统使用前或使用中对车次的等级进行设定并在售票时自动标记占用符 4. 用户信息表用于设定及管理系统用户 11.3.3 数据库设计 《VFP基础教程》 清华大学出版社 * 11.1 数据库应用系统开发步骤 11.2 学生成绩管理系统设计 11.3 车站售票管理系统设计实例 第11章 Visual FoxPro数据库应用系统开发实例 11.1.1 需求分析 11.1.2 系统结构设计 11.1.3 系统详细设计 11.1.4 编译应用程序 11.1 Visual FoxPro数据库应用系统开发步骤 1. 获取用户需求 2. 分析用户需求 3. 编写需求文档 4. 评审需求文档 5. 管理需求文档 11.1.1 需求分析 1. 获取用户需求 软件需求主要包括:功能需求、界面需求、性能需求、环境需求、可靠性需求、安全保密需求、资源使用需求、软件成本与开发进度需求等。要了解客户的需求,首先要对客户进行访谈和调研,充分收集相关需求信息。对每一次交流一定要有详细记录,这是进一步分析需求和编写需求说明书的原始资料。 对收集到的用户需求信息做进一步的分析和整理,罗列出所有需要在程序设计中实现的功能;分析需求是否真实地反映了用户的意图;使需求符合系统的整体目标;保证需求项之间的一致性,解决需求项之间可能存在的冲突。对于用户提出的每个需求都要知道“为什么”,不要盲目接受用户或客户提出的需求,必须弄清楚用户所提出需求的理由。一般来讲,用户通常不能提出隐含的需求,但它可能是实现另一用户需求的前提条件,忽略这一点往往容易因为对隐含需求考虑得不够充分而引起需求变更,延长软件的开发周期。 需求分析阶段的工作成果,体现为《用户需求说明书》。需求文档可以使用自然语言或形式化语言来描述,还可以添加图形的表述方式和模型表征的方式。需求文档应该包括用户的所有需求,包括功能性需求和非功能性需求。 需求说明文档完成后,需要经过正式评审,以便作为下一阶段工作的基础。一般的评审分为用户评审和同行评审两
文档评论(0)