实例1学校教材订购系统.docx
《实例1学校教材订购系统.docx》由会员分享，可在线阅读，更多相关《实例1学校教材订购系统.docx（14页珍藏版）》请在冰豆网上搜索。
实例1学校教材订购系统
1.引言
编写目的
对学校教材订购系统进行初步设计
项目背景
名称:
学校教材订购系统
本项目的用户:
学校的学生，教师和教材订购治理员
本项目与其它软件或其他系统的关系:
工作于windows所有的系统
参考资料
软件工程—理论、方式与实践
系统简介
本系统能够细化为两个子系统：
销售系统和采购系统
销售系统的要紧工作进程为：
第一由教师或学生提交购书单，经教材发行人员审核是有效购书单后，开发票、记录并返给教师或学生领书单，教师或学生能够到书库领书。
采购系统的要紧工作进程为：
假设是教材脱销，那么记录缺书，发缺书单给书库采购人员；一旦新书入库后，即发进书通知给教材发行人员。
技术要求及限定条件
当书库中的各类书籍数量发生转变（包括进书和出书）时，都应修改相关的书库记录，如库存表或进/出库表。
（1）在实现上述销售和采购的工作进程时，需考虑有关的合法性验证。
（2）系统的外部项至少包括：
教师、学生和教材工作人员。
系统的相关数据存储至少包括：
购书表、库存表、缺书记录表、待购教材表、进库表和出库表。
需求说明书
1.需求分析的目的
需求分析对学校教材订购系统进行简单的分析，给出了系统的数据流图。
加深与用户间的交流，在功能与系统界面上与用户达到一致的观点，以便于开发出用户中意的系统。
2.软件产品的作用范围
学校教材订购系统是为大多数教育院校开发的，用于日常的教材治理，包括销售与采购。
提供数字化的治理，提高学校教材治理部门的工作效率。
3.一样性描述
本系统能够细化为两个子系统：
销售系统和采购系统
销售系统的要紧工作进程为：
第一由教师或学生提交购书单，经教材发行人员审核是有效购书单后，开发票、记录并返给教师或学生领书单，教师或学生能够到书库领书。
采购系统的要紧工作进程为：
假设是教材脱销，那么记录缺书，发缺书单给书库采购人员；一旦新书入库后，即发进书通知给教材发行人员。
4.产品功能
本系统在向学生售书时要紧输入学生学号、班级代号、购书数量、购书书名信息，然后打印领书单返回给学生领取书籍。
本系统在采购图书进程中，图书发行人员需将脱销教材的编号、书名、出版社信息、版本号等一系列信息打印给书库采购人员，一旦新书入库后，即发进书通知给教材发行人员。
5.数据流图与数据字典
顶层数据流图
0层数据流图
1层数据流图
概要设计说明书
1.引言
概念
1.1.1专门术语
购书表：
寄存提交的购书信息。
库存表：
寄存库中存在的书籍数据。
缺书记录表：
寄存缺少的书籍信息。
待购教材表：
寄存待购的书籍信息。
入库表：
寄存入库书籍的数据。
出库表：
寄存已销售的书籍数据。
1.1.2缩写
系统：
假设未专门指出，系统指本“学校教材订购系统”。
1.1.3系统相关数据存储模型
购书表模型如下：
编号
书名
书籍编号
出版社
数量
交易金额
交易日期
备注
1
2
…
库存表模型如下：
书籍编号
书名
作者
出版社
数量
类别
SW-01
SW-02
…
缺书记录表模型如下：
书名
书籍编号
出版社
数量
备注
A
B
…
待购教材表模型如下：
编号
书名
书籍编号
作者
出版社
数量
备注
1
2
…
入库表模型如下：
书名
书籍编号
作者
出版社
数量
进书日期
备注
A
B
…
出库表模型如下：
书名
书籍编号
数量
领书人姓名
开票人姓名
备注
A
B
…
2.整体设计
需求概述
为方便教师、学生领书，教材发行人员处置各类单据，和采购人员采购需开发一个“学校教材订购系统”。
教师或学生提交购书单，经教材发行人员审核是有效购书单后，开发票、记录并返给教师或学生领书单，教师或学生能够到书库领书。
假设是教材脱销，那么记录缺书，发缺书单给书库采购人员；一旦新书入库后，即发进书通知给教材发行人员。
要求系统能有效、快速、平安、靠得住和无误的完成上述操作。
并要求系统易于操作，数据库利于保护。
软件结构
2.2.1销售子系统
2.2.2采购子系统
3.功能模块
4.程序描述
功能
销售子系统模块：
提交购书单、审核购书单、开发票、记录购书记录、返回领书单、修改和保护数据库中相应的表。
采购子系统模块：
发缺书单、记录缺书记录、打印待购书信息、发进书通知单、修改和保护数据库中相应的表。
性能
（1）精度：
购书是由需求决定的，只要有缺书现象那么会表现出来，但也因为如此，若是需要提早多购书籍的话，那么需要治理人员的参与。
（2）时刻要求：
订购需要提早假设干天。
（3）靠得住性：
高
（4）灵活性：
在购书单未审核时，能够撤销订购或修改，一旦审核，那么不能再修改。
输入项目
销售子系统模块：
需要输入购书单中要求的信息（提交人姓名、订购书籍书名、数量、备注）。
采购子系统模块：
需要输入缺书单中要求的信息（脱销书籍书名、书籍编号、开票人姓名、交易金额、交易日期）。
输出项目
销售子系统模块：
需要打印领书单（订购书籍书名、书籍编号、数量、领书人姓名），发票（订购书籍书名、书籍编号、开票人姓名、交易金额、交易日期）。
采购子系统模块：
需要打印进书通知单（书籍编号、书名、出版社、作者、数量、进书日期）。
详细设计说明书
1.引言
编写目的
在学校教材订购系统中，已经对本系统所包括的子模块作了概要的茶树，这些子模块的具体功能将在以下取得详细的论述。
本时期已在系统的整体设计的基础上，对学校教材订购系统做详细设计。
要紧解决了实现该系统程序模块具体设计问题。
包括确信算法，数据结构，模块接口的利用，数据库的动态操作等。
2.系统模块的详细设计
系统功能模块示用意
销售子系统模块具体描述
销售系统的工作进程为：
第一由教师或学生提交购书单，经教材发行人员审核是有效购书单后，开发票、记录并返给教师或学生领书单，教师或学生能够到书库领书。
采购子系统模块具体描述
采购子系统工作进程为：
工作人员提交缺书单后，进行审查，无误后记录缺书，审核记录进程后，汇总缺书，生成采购表，采购终止后发进书通知单，最后更新相应表单，审核修改良程。
在以上各审核进程中发觉错误时，返回上一层从头进行操作。
程序逻辑
2.2.1销售子系统模块程序流程图
1购书单错误信息显示
2记录购书记录错误信息显示
1修改表错误信息显示
2.2.2采购子系统模块程序流程图
1缺书单错误信息显示
2记录错误信息显示
3修改错误信息显示
存储分派
为程序当中的数据结构在内存中开辟空间存储，加入到数据库中后在数据库的表中为其开辟存储空间。
限制条件
输入的信息都封装在数据结构当中，不能独立存在，在向数据库中提交数据时必需一路提交而不能逐项提交。
输入数据的类型必需和概念的数据类型相匹配。
测试打算
1.测试方式与用例设计
测试目的
测试的实施是对软件规格说明、设计规格说明和编码的最终审核。
软件测试的目的是以最少的人力、物力和时刻投入，尽可能多地找出软件中潜在的各类错误和缺点。
测试的结果为软件靠得住性分析提供了依据。
测试内容
测试库存数，定单数，缺货数
测试步骤
（1）单元测试:
单元测试也称模块测试或程序测试，单元测试是对每一个模块单独进行的，验证数据是不是与模块一致，检查各个模块是不是正确实现规定的功能，对模块的所有要紧处置途径进行测试且与预期的结构进行对照，还要对所有错误处置途径进行测试，从而发觉模块在编码中或算法中的错误。
（2）集成测试:
集成测试也称组合测试或子系统测试，通常采纳自上而下或自下而上的测试方式。
集成测试的对象是指已经通过单元测试的模块，不是对零散模块进行单个测试，而是用系统化的方式装配和测试软件系统。
（3）确认测试:
确认测试又称有效性测试。
它的任务是检查软件的功能与性能是不是与要求规格说明书中确信的指标相吻合。
（4）系统测试:
系统测试是对整体性能的测试，要紧解决各子系统之间的数据通信和数据共享问题和检测系统是不是达到用户的实际要求，系统测试的依据是系统分析报告。
系统测试应在系统的整个范围内进行，这种测试不只对软件进行，而是对组成系统的硬件和软件一路进行。
（5）用户验收测试:
在系统测试完成后，进行用户的验收测试，它是用户在实际应用环境中所进行的真实数据测试。
在具体的测试中，一样应遵循以下原那么：
由程序设计者之外的人进行测试；测试用例应由两部份组成：
输入数据和预期输出结果；选用不合理的输入数据与非法输入测试；不仅要查验程序是不是实现预期功能，还应检查程序是不是做了不该该做的工作；集中测试容易犯错的程序模块；对程序求该以后，必需从头进行测试。
测试用例设计
1.4.1白盒测试（结构化测试）
1.4.2黑盒测试（功能测试）
通过采纳错误推测法可列举出程序中所有可能有的错误和容易发上的特殊情形：
1库存数、定单数、缺货数<0
2是不是有不正确或遗漏了的功能
3在函数传递的进程中，可否正确的同意输入数据，可否产生正确的输出信息
1性能上是不是知足要求
依照以上情形设计测试用例：
正确输入：
教材编号：
SW-01
教材名称：
软件工程—理论、方式与实践
孙家广
出版社：
高等教育出版社
类别：
运算机
返回信息：
书籍信息添加成功
错误输入：
教材编号：
SW-02
教材名称：
数据结构与算法
张铭
类别：
运算机
返回信息：
输入信息不完整，请检查后填写完整
测试情形分析
1.5.1测试用例执行情形
输入帐号和密码以后登岸系统，进入软件主界面，点击各按钮均能响应。
添加待购教材界面输入教材编号，作者信息等均能存入数据库，在待购教材信息界面能正确呈现待购教材信息。
通过测试系统大体达到设计要求，系统功能完整，错误处置正确，且能正确提示错误种类。
1.5.2建议
将系统的功能加倍完善；改写需求文档，设计文档，使系统的往后保护加倍方便；进行系统化，提高性能。
2.测试总结
总的来讲,软件通过测试,大体上达到需求分析时期所提出的要求.同时软件的质量和靠得住性是能够同意的,但由于没有正式运行有些问题可能还发觉不了,这些错误最终会被用户在利用进程中发觉而需要在保护时期更正它们。
可能的保护打算
1.大体工作：
a）检查用户需求说明书，对用户原先的需求做到心中有数；
b）同用户和开发人员商讨，明确保护的类型；
c） 检查程序和相应的文档；
d）确信程序错误的性质与位置，或要增加功能的部份；
e） 研究程序修改可行性和修改可能引发的副作用；
f）对改变的部份进行编码；
g） 修改相应的程序文档和程序库
2.改良保护方式的一些建议：
a）利用结构化程序设计技术来修改程序；
b）鼓舞保护人员与用户和开发人员相互商讨问题；
c）成立和增强程序设计和文档标准；
d）改良现有软件的文档；
e
升级会员 