第四章 项目开发过程
4.１ 需求分析
4.２ 软件概要设计
4.３ 软件详细设计
4.４ 软件实现
4.５ 软件测试
4.６ 软件维护第四章 项目开发过程
设计系统：学生管理系统
以该系统设计为例 。 介绍一般管理项目的开发过程
4.1 需求分析
目的,了解需求分析任务
开发人员要准确理解用户的要求,进行细致的调查分析,将用户非形式的需求陈述转化为完整的需求定义,再由需求定义转化到相应的形式功能规约 （ 需求规格说明 ） 的过程 。
需求分析虽处于软件开发过程的初期阶段,但它对于整个软件开发过程以及软件产品质量是至关重要的 。 随着软件系统复杂性的提高及规模的扩大,需求分析在软件开发中的所处的地位愈加突出,从而也愈加困难 。
需求分析的基本任务包括：
1,问题识别
(1)功能需求：
明确所开发的软件必须具备的功能 。
(2)性能需求：
明确待开发的软件的技术性能指标 。
(3)环境需求：
明确软件运行时所需要的软,硬件要求
(4)用户界面需求：
明确人机交互方式,输入输出数据格式 。
4.1 需求分析
随着学校规模的不断扩大，学生数量日益剧增，有关学生的各种信息量也急剧增长，原始的手工登记、
手工查阅方法已经不能满足我们快速检索的要求。
面对这种形式，需要开发一个能够满足用户需求的系统，
（ 1）功能需求：
实现学籍信息的增加、删除、修改以及查询等管理功能；
管理与学生相关的课程及成绩等信息；
基本上满足一个学校学生信息管理各方面的功能要求。
4.1 需求分析
（ 2）性能需求
能够很方便快捷的管理学生的基本信息
保证信息的安全，防止非法破坏
（ 3）环境需求
安装软件系统的机器配置和外设等
（ 4）用户界面需求
图形化、支持键盘、快捷键和鼠标等
4.1 需求分析
2,分析与综合,导出软件的逻辑模型
分析人员对获取的需求，进行一致性的分析检查，
在分析、综合中逐步细化软件功能，划分成各个子功能。用图文结合的形式，建立起新系统的逻辑模型。
开发学生管理系统的目的是为了提高学校管理学生信息的效率，实现学生信息管理的系统化、规范化。
4.1 需求分析
系统最终要实现的主要功能：
学生基本信息管理：对学生基本信息进行添加、
修改、删除等。
学生成绩信息管理：对学生的成绩进行管理，包括增加新课程成绩、修改和删除原有课程成绩、
查询成绩等；
学生的课程管理：对学生所学课程进行增加、删除、修改、查询等管理操作；
用户和权限管理：按照各种权限管理用户信息，
包括增加、删除、修改用户信息等功能。
4.1 需求分析
数据库需求分析,
根据学生成绩管理系统所需要的信息进行分析，
为本系统设计如下的数据库结构：
学生成绩信息数据库中包含四个基本表，分别保存学生的基本信息、成绩信息、课程信息以及系统的用户信息表。
4.1 需求分析
3．编写文档
(1) 编写,需求规格说明书,,把双方共同的理解与分析结果用规范的方式描述出来，作为今后各项工作的基础。
(2) 编写初步用户使用手册，着重反映被开发软件的用户功能界面和用户使用的具体要求，用户手册能强制分析人员从用户使用的观点考虑软件。
(3) 编写确认测试计划，作为今后确认和验收的依据
(4) 修改完善软件开发计划。在需求分析阶段对待开发的系统有了更进一步的了解，所以能更准确地估计开发成本、进度及资源要求，因此对原计划要进行适当修正。
4.1 需求分析
4.2 软件概要设计
在软件需求分析阶段，已经搞清楚了软件,做什么,的问题，并把这些需求通过规格说明书描述了出来，建立了目标系统的 逻辑模型 。
进入了设计阶段，要把软件,做什么,的逻辑模型变换为,怎么做,的 物理模型,即着手实现软件的需求，并将设计的结果反映在,设计规格说明书,文档中。
软件设计是一个把软件需求转换为软件表示的过程，最初这种表示只是描述了软件的总的体系结构，称为软件概要设计或结构设计。
软件概要设计的基本任务包括：
1,设计软件系统结构 (简称软件结构 )
为了实现目标系统，最终必须设计出组成这个系统的所有程序和数据库 (文件 )，对于程序，则首先进行结构设计，具体为：
(1)采用某种设计方法，将一个复杂的系统按功能划分成模块。
(2)确定每个模块的功能。
(3)确定模块之间的调用关系。
(4)确定模块之间的接口，即模块之间传递的信息
(5)评价模块结构的质量。
4.2 软件概要设计
根据以上内容，软件结构的设计是以模块为基础的，在需求分析阶段，已经把系统分成 层次结构 。设计阶段，以需求分析的结果为依据，
从实现的角度进一步划分为 模块,并组成 模块的层次结构 。
软件结构的设计是概要设计关键的一步，直接影响到下一阶段详细设计与编码的工作软件系统的质量及一些整体特性都在软件结构的设计中决定。
4.2 软件概要设计学 生 信 息 系 统登陆验证成绩管理基本信息管理用户管理修改用户查找用户删除用户添加用户查找成绩修改成绩删除成绩添加成绩查找学生修改学生添加学生删除学生学 生 信 息 系 统 功 能 模 块 图课程管理查找课程修改课程删除课程添加课程
4.2 软件概要设计
2.数据结构及数据库设计
对于大型数据处理的软件系统，除了控制结构的模块设计外，数据结构与数据库设计也是很重要。
(1)数据结构的设计
逐步细化的方法也适用于数据结构的设计。需求分析阶段，在数据字典中对数据的组成、操作约束、数据之间的关系等方面进行描述，确定了数据的结构特性；
在概要设计阶段要细化抽象的数据类型；
详细设计阶段则规定具体的实现细节。
4.2 软件概要设计
(2)数据库的设计
数据库的设计指数据存储文件的设计，主要进行以下几方面设计
①概念设计。在数据分析的基础上，采用自底向上的方法从用户角度进行视图设计，一般用 ER模型来表示数据模型，这是一个概念模型。
E-R模型（实体 -关系,Entity-Relationship）
矩形框 -----实体
菱形框 ----关系
椭圆形 ----属性
无向边 ----将实体和其属性连接
4.2 软件概要设计
E-R模型 4.2 软件概要设计
② 逻辑设计。 ER模型是独立于数据库管理系统的，
要结合具体的 DBMS特征来建立数据库的逻辑结构。给出数据结构的定义，即定义所含的数据项、类型、长度及它们之间的层次或相互关系的表格等等。
③物理设计。对于不同的 DBMS，应用的物理环境不同，提供的存储结构与存取方法各不相同。
物理设计就是根据设计数据模式的要求，选取适合的 DBMS 。
本例选用 Access作为后台数据库
4.2 软件概要设计
4.2 软件概要设计
学生成绩信息数据库中包含四个基本表，分别保存学生的基本信息、成绩信息、课程信息以及系统的用户信息表，每个基本表的数据项和数据结构如下表所示：
（ 1） 学生基本信息表,
表中使用学号字段作为主键。
字段名 数据类型 长度 值唯一 必填项 默认值学号 文本 15 √ √ 无姓名 文本 10 √ 无性别 文本 2 无出生日期 日期 /时间 无班级 文本 10 无
4.2 软件概要设计
（ 2）成绩信息表：表中学号和课程号为主键。学号字段是外键，引用学生基本信息表中的学号字段值。
字段名 数据类型 长度 值唯一 必填项 默认值学号 文本 15 √ √ 无课程号 文本 10 √ 无分数 数字 4 √ 无主键：唯一能标示一个记录，且不含多余项
4.2 软件概要设计
（ 3）课程信息表：表中使用课号字段作为主键。
字段名 数据类型 长度 值唯一 必填项 默认值课号 文本 15 √ √ 无课程 文本 20 无
（ 4）用户信息表：表中使用帐号字段作为主键。
字段名 数据类型 长度 值唯一 必填项 默认值用户名 文本 15 √ √ 无密码 文本 10 无权限 文本 10 √ 无
3.编写概要设计文档
(1)概要设计说明书。
(2)数据库设计说明书，主要给出所使用的 DBMS简介、
数据库的概念模型、逻辑设计、结果。
(3)用户手册，对需求分析阶段编写的用户手册作补充。
(4)修订测试计划，对测试策略、方法、步骤提出明确要求。
4.评审
对设计部分是否完整地实现了需求中规定的功能、性能等要求，设计方案的可行性，关键的处理及内外部接口定义正确性、有效性，各部分之间的一致性等等都一一进行评审。
4.2 软件概要设计
4.3 软件详细设计
目的：掌握软件详细设计的任务和思想
详细设计的基本任务有
(1)为每个模块进行详细的算法设计。用某种图形、
表格、语言等工具将每个模块处理过程的详细算法描述出来。
(2)为模块内的数据结构进行设计。对于需求分析、概要设计确定的概念性的数据类型进行确切的定义。
(3)对数据结构进行物理设计，即确定数据库的物理结构。物理结构主要指数据库的存储记录格式、存储记录安排和存储方法，这些都依赖于具体所使用的数据库系统。
(4)其他设计：根据软件系统的类型，还可能要进行以下设计：
① 代码设计。为了提高数据的输入、分类、存储、检索等操作，节约内存空间，对数据库中的某些数据项的值要进行代码设计。
② 输入 /输出格式设计。
③ 人机对话设计。对于一个实时系统，用户与计算机频繁对话，因此要进行对话方式、内容、格式的具体设计。
(5)编写详细设计说明书。
(6)评审。对处理过程的算法和数据库的物理结构都要评审
4.3 软件详细设计
4.3 软件详细设计
设计主窗体如图所示：
4.3 软件详细设计
登录窗体 修改密码
4.3 软件详细设计
添加、删除用户窗体
4.3 软件详细设计
添加、修改学籍窗体
4.3 软件详细设计
查询学籍窗体
4.3 软件详细设计
添加、修改课程窗体
4.3 软件详细设计
输入成绩窗体
4.3 软件详细设计
修改成绩窗体
4.3 软件详细设计
2,数据库实现
启动 Access，创建一个新的数据库，命名为
student.mdb，保存在要存放这个系统的所有工程文件的文件夹中。
学生成绩信息数据库中的表格设计视图如下所示，
每个表格都代表数据库中的一个独立的表。
学生基本信息设计视图：
4.3 软件详细设计
成绩信息设计视图：
课程信息设计视图：
4.3 软件详细设计
系统用户设计视图：
4.4 软件实现
目的：使用编程工具完成系统编码
在软件实现阶段,根据详细设计用编程语言编写所需的程序 。 这个阶段的文档包括,软件需求规格说明书,,,高层设计说明书,,,详细设计说明书,,
,单元测试计划,编码,用户接口标准等,输出有测试数据,源代码,可执行代码,,单元测试报告,,
需要完成的任务包括：
1.根据详细设计,按照编码,用户接口规范编写程序
2.对程序进行代码复查,编译,调试,直到程序运行通过,符合详细设计的要求；
3.根据单元测试计划进行单元测试,生成单元测试报告 。
4.5 软件测试
目的：掌握进行测试工作的方法和技巧
软件测试是为了发现错误而执行程序的过程，
一个好的测试用例能够发现至今尚未发现的错误，一个成功的测试是发现了至今尚未发现的错误的测试。因此，测试阶段的基本任务应该是根据软件开发各阶段的文档资料和程序的内部结构，精心设计一组,高产,的测试用例，
利用这些实例执行程序，找出软件中潜在的各种错误和缺陷。
软件测试方法一般分为两大类：动态测试方法与静态测试方法。
1,静态测试 静态测试是指被测试程序不在机器上运行，而是采用人工检测和计算机辅助静态分析的手段对程序进行检测。
(1)人工检测。人工检测是不依靠计算机而是靠人工审查程序或评审软件。
(2)计算机辅助静态分析。利用静态分析工具对被测试程序进行特性分析，从程序中提取一些信息，以便检查程序逻辑的各种缺陷和可疑的程序构造。
2,动态测试 一般意义上的测试大多是指动态测试。
有两种方法，分别是黑盒测试法和白盒测试法。
4.5 软件测试
黑盒测试法与白盒测试法
1,黑盒法 该方法把被测试对象看成一个黑盒子，
测试人员完全不考虑程序的内部结构和处理过程，
只在软件的接口处进行测试，依据需求规格说明书，检查程序是否满足功能要求。因此，黑盒测试又称为功能测试或数据驱动测试。通过黑盒测试主要发现以下错误：
(1)是否有不正确或遗漏了的功能。
(2)在接口上，能否正确地接受输入数据，能否产生正确的输出信息。
(3)访问外部信息是否有错。
(4)性能上是否满足要求等等。
4.5 软件测试
2,白盒法 该方法把测试对象看作一个打开的盒子，
测试人员须了解程序的内部结构和处理过程，
以检查处理过程的细节为基础，对程序中尽可能多的逻辑路径进行测试，检查内部控制结构和数据结构是否有错，实际的运行状态与预期的状态是否一致。
黑盒法和白盒法都不能使测试达到彻底。为了用有限的测试发现更多的错误，需精心设计测试用例。
4.5 软件测试
3.6 软件维护
目的：掌握进行软件维护工作的防范,认识维护工作的重要性
软件投入使用后就进入软件维护阶段 。 维护阶段是软件生存周期中时间最长的一个阶段,所花费的精力和费用也是最多的一个阶段 。
软件维护内容有四种：校正性维护，适应性维护，完善性维护和预防性维护。
4.5 软件维护
1.校正性维护
在软件交付使用后，由于在软件开发过程中产生的错误并没有完全彻底的在测试中发现，因此必然有一部分隐含的错误被带到维护阶段来。
这些隐含的错误在某些特定的使用环境下会暴露出来。为了识别和纠正错误，修改软件性能上的缺陷，应进行确定和修改错误的过程，这个过程就称为校正性维护。校正性维护占整个维护工作的 20%左右。
4.5 软件维护
2.适应性维护
随着计算机的飞速发展，计算机硬件和软件环境也在不断发生变化，数据环境也在不断发生变化。为了使应用软件适应这种而修改软件的过程称为适应性维护。这种维护活动占整个维护活动的 25%。
4.5 软件维护
3.完善性维护
在软件漫长的运行时期中，用户往往会对软件提出新的功能要求与性能要求。这是因为用户的业务会发生变化，组织机构也会发生变化。
为了适应这些变化，应用软件原来的功能和性能需要扩充和增强，为达到这个目的而进行的维护活动称为完善性维护，占整个维护活动的
50%。
4.5 软件维护
4.预防性维护
为了提高软件的可维护性和可靠性而对软件进行的修改称为预防性维护。这是为以后进一步的运行和维护打好基础，占整个维护工作的 4%。
4.5 软件维护一个 ATM机的模型设计
1,划分主题
在开发大型、复杂系统的过程中，为了降低复杂程度，需要系统划分成几个不同的主题。
一般按问题领域而不是用功能分解方法来确定主题。
一般按不同主题间对象相互间依赖和交互最少的原则来确定主题。
以 ATM系统为例，我们可以把它划分成,总行,,,分行,和,ATM”等三个主题，这三个主题的编号分别是 1,2和 3，如下图所示。
4.6 一个 ATM机的模型设计
2,确定属性
从需求陈述中选择属性，属性的确定既与问题域有关，也和目标系统的任务有关。
用名词词组表示属性，例如,,汽车的颜色,或
,光标的位置,。用形容词表示可枚举的具体属性，
例如,,红色的,,,打开的,。
应该仅考虑与具体应用直接相关的属性，不要考虑那些超出所要解决的问题范围的属性。
4.6 一个 ATM机的模型设计
3,建立动态模型
在开发交互式系统时，动态模型起着很重要的作用。
建立动态模型分三步
第一步为编写典型交互行为的脚本。 脚本描述常见的交互行为。
第二步 从脚本中提取出事件，确定触发每个事件的动作对象以及接受事件的目标对象。
第三步，排列事件发生的次序，确定每个对象可能有的状态及状态间的转换关系，并用状态图描绘它们。
4.6 一个 ATM机的模型设计
（ 1） 编写脚本
在建立动态模型的过程中，脚本是指系统在某一执行期间内出现的一系列事件。
脚本描述用户 (或其他外部设备 )与目标系统之间的一个或多个典型的交互过程，以便对目标系统的行为有更具体的认识。
编写脚本的目的，是保证不遗漏重要的交互步骤，
它有助于确保整个交互过程的正确性的和清晰性。
下面给出了 ATM系统的正常情况脚本
4.6 一个 ATM机的模型设计
① ATM请储户插卡 ;储户插入一张现金兑换卡。
② ATM接受该卡并读它上面的分行代码和卡号。
③ ATM要求储户输入密码 ;储户输入自己的密码
"1234"等数字。
④ ATM请求总行验证卡号和密码 ;总行要求 "39"号分行核对储户密码，然后通知 ATM说这张卡有效。
⑤ ATM要求储户选择事务类型 (取款、转账、查询等 );储户选择 "取款 "。
⑥ ATM要求储户输入取款额 ;储户输入 "880"。
4.6 一个 ATM机的模型设计
⑦ ATM确认取款额在预先规定的限额内，然后要求总行处理这个事务 ;总行把请求转给分行，该分行成功地处理完这项事务并返回该账户的新余额。
⑧ ATM吐出现金并请储户拿走这些现金；储户拿走现金。
⑨ ATM问储户是否继续这项事务 ;储户回答 "不 "。
⑩ ATM打印账单，退出现金兑换卡，请储户拿走它们；储户取走账单和卡。
⑾ ATM请储户插卡。
下面给出 ATM系统的异常情况脚本
4.6 一个 ATM机的模型设计
① ATM接受这张卡并顺序读它上面的数字。
ATM要求密码 ;储户误输入 "8888"。
② ATM请求总行验证输入的数字和密码 ;总行在向有关分行咨询之后拒绝这张卡。
③ ATM显示 "密码错 "，并请储户重新输入密码 ;储户输入 "1234";ATM请总行验证后知道这次输入的密码正确。
④ ATM请储户选择事务类型 ;储户选择 "取款 "。
⑤ ATM询问取款额 ;储户改变主意不想取款了，他敲 "
取消 "键。
⑥ ATM退出现金兑换卡，并请储户拿走它储户拿走他的卡。
⑦ ATM请储户插卡。
ATM的界面格式
4.6 一个 ATM机的模型设计
（ 2）画事件跟踪图
通常在画状态图之前先画出事件跟踪图。首先需要明确事件及事件与对象的关系。
a.确定事件
外部事件包括系统与用户 (或外部设备 )交互的所有信号、输入、输出、中断、动作等,
对产生相同效果的那些事件组合在一起作为一类事件。例如,,吐出现金,是一个事件类。
4.6 一个 ATM机的模型设计
b.画出事件跟踪图
在事件跟踪图中規定，
① 一条竖线代表一个类与对象；
② 每个事件用一条水平的箭头线表示，箭头方向从事件的发送对象指向接受对象。
③ 时间从上向下递增，画在最上面的水平箭头线代表最先发生的事件，画在最下面的水平箭头线所代表的事件最晚发生。箭头线之间的间距并没有具体含义，箭头线位置也不表示两个事件之间的精确时间差。
4.6 一个 ATM机的模型设计
c,画状态图
一般说来，不同应用系统对相同事件的响应并不相同，因此，在最终分类所有事件之前，必须先画出状态图。如果从状态图中看出某些事件之间的差异对系统行为并没有影响，则可以忽略这些事件间的差异
状态图描绘事件与对象状态的关系。当对象接受了一个事件以后，它的下个状态取决于当前状态及所接受的事件。
由事件引起的状态改变称为,转换,。如果一个事件并不引起当前状态发生转换，则可忽略这个事件。
下图为 ATM状态图
4.6 一个 ATM机的模型设计下图为总行类状态图
4.6 一个 ATM机的模型设计下图为分行类状态图
4.6 一个 ATM机的模型设计
4、建立功能模型
功能模型表明了系统中数据之间的依赖关系，以及有关的数据处理功能，它由一组数据流图组成。
通常在建立了对象模型和动态模型之后再建立功能模型。
(1) 画出基本系统模型图
基本系统模型由若干个数据源点 /终点，及一个处理框组成，这个处理框代表了系统加工、变换数据的整体功能。
基本系统模型指明了目标系统的边界。由数据源点输入的数据和输出到数据终点的数据，是系统与外部世界之间的交互事件的参数。
4.6 一个 ATM机的模型设计
ATM系统的基本系统模型,
本系统的数据源点 /终点为储户,尽管在储蓄所内储户的事务是由柜员通过柜员终端提交给系统的，但是信息的来源和最终接受者都是储户。
另一个数据源点是现金兑换卡，因为系统从它上面读取分行代码、卡号等信息。
(2) 画出功能级数据流图
把基本系统模型中单一的处理框分解成若干个处理框，以描述系统加工、变换数据的基本功能，
就得到功能级数据流图。
4.6 一个 ATM机的模型设计
(3) 描述处理框功能
把数据流图分解细化到一定程度之后，就应该描述图中各个处理框的功能。
注意：描述每个处理框所代表的功能，而不是实现功能的具体算法。
描述既可以是说明性的，也可以是过程性的。
说明性描述规定了输入值和输出值之间的关系，
以及输出值应遵循的规律。
过程性描述则通过算法说明,做什么,。
4.6 一个 ATM机的模型设计
ATM系统数据流图中对,更新账户,处理功能：
更新账户 (账号,事务类型,金额 )→ 现金额,账单数据,信息
如果取款额超过账户当前余额，拒绝该事务且不付出现金。
如果取款额不超过账户当前余额，从余额中减去取款额后作为新的余额，付出储户要取的现金。
如果事务是存款，把存款额加到余额中得到新余额，
不付出现金。
如果事务是查询，不付出现金。
在上述任何一种情况下，账单内容都是,ATM号，
日期，时间，账号，事务类型 ·事务金额 (如果有的话 )，
新余额。
4.１ 需求分析
4.２ 软件概要设计
4.３ 软件详细设计
4.４ 软件实现
4.５ 软件测试
4.６ 软件维护第四章 项目开发过程
设计系统：学生管理系统
以该系统设计为例 。 介绍一般管理项目的开发过程
4.1 需求分析
目的,了解需求分析任务
开发人员要准确理解用户的要求,进行细致的调查分析,将用户非形式的需求陈述转化为完整的需求定义,再由需求定义转化到相应的形式功能规约 （ 需求规格说明 ） 的过程 。
需求分析虽处于软件开发过程的初期阶段,但它对于整个软件开发过程以及软件产品质量是至关重要的 。 随着软件系统复杂性的提高及规模的扩大,需求分析在软件开发中的所处的地位愈加突出,从而也愈加困难 。
需求分析的基本任务包括：
1,问题识别
(1)功能需求：
明确所开发的软件必须具备的功能 。
(2)性能需求：
明确待开发的软件的技术性能指标 。
(3)环境需求：
明确软件运行时所需要的软,硬件要求
(4)用户界面需求：
明确人机交互方式,输入输出数据格式 。
4.1 需求分析
随着学校规模的不断扩大，学生数量日益剧增，有关学生的各种信息量也急剧增长，原始的手工登记、
手工查阅方法已经不能满足我们快速检索的要求。
面对这种形式，需要开发一个能够满足用户需求的系统，
（ 1）功能需求：
实现学籍信息的增加、删除、修改以及查询等管理功能；
管理与学生相关的课程及成绩等信息；
基本上满足一个学校学生信息管理各方面的功能要求。
4.1 需求分析
（ 2）性能需求
能够很方便快捷的管理学生的基本信息
保证信息的安全，防止非法破坏
（ 3）环境需求
安装软件系统的机器配置和外设等
（ 4）用户界面需求
图形化、支持键盘、快捷键和鼠标等
4.1 需求分析
2,分析与综合,导出软件的逻辑模型
分析人员对获取的需求，进行一致性的分析检查，
在分析、综合中逐步细化软件功能，划分成各个子功能。用图文结合的形式，建立起新系统的逻辑模型。
开发学生管理系统的目的是为了提高学校管理学生信息的效率，实现学生信息管理的系统化、规范化。
4.1 需求分析
系统最终要实现的主要功能：
学生基本信息管理：对学生基本信息进行添加、
修改、删除等。
学生成绩信息管理：对学生的成绩进行管理，包括增加新课程成绩、修改和删除原有课程成绩、
查询成绩等；
学生的课程管理：对学生所学课程进行增加、删除、修改、查询等管理操作；
用户和权限管理：按照各种权限管理用户信息，
包括增加、删除、修改用户信息等功能。
4.1 需求分析
数据库需求分析,
根据学生成绩管理系统所需要的信息进行分析，
为本系统设计如下的数据库结构：
学生成绩信息数据库中包含四个基本表，分别保存学生的基本信息、成绩信息、课程信息以及系统的用户信息表。
4.1 需求分析
3．编写文档
(1) 编写,需求规格说明书,,把双方共同的理解与分析结果用规范的方式描述出来，作为今后各项工作的基础。
(2) 编写初步用户使用手册，着重反映被开发软件的用户功能界面和用户使用的具体要求，用户手册能强制分析人员从用户使用的观点考虑软件。
(3) 编写确认测试计划，作为今后确认和验收的依据
(4) 修改完善软件开发计划。在需求分析阶段对待开发的系统有了更进一步的了解，所以能更准确地估计开发成本、进度及资源要求，因此对原计划要进行适当修正。
4.1 需求分析
4.2 软件概要设计
在软件需求分析阶段，已经搞清楚了软件,做什么,的问题，并把这些需求通过规格说明书描述了出来，建立了目标系统的 逻辑模型 。
进入了设计阶段，要把软件,做什么,的逻辑模型变换为,怎么做,的 物理模型,即着手实现软件的需求，并将设计的结果反映在,设计规格说明书,文档中。
软件设计是一个把软件需求转换为软件表示的过程，最初这种表示只是描述了软件的总的体系结构，称为软件概要设计或结构设计。
软件概要设计的基本任务包括：
1,设计软件系统结构 (简称软件结构 )
为了实现目标系统，最终必须设计出组成这个系统的所有程序和数据库 (文件 )，对于程序，则首先进行结构设计，具体为：
(1)采用某种设计方法，将一个复杂的系统按功能划分成模块。
(2)确定每个模块的功能。
(3)确定模块之间的调用关系。
(4)确定模块之间的接口，即模块之间传递的信息
(5)评价模块结构的质量。
4.2 软件概要设计
根据以上内容，软件结构的设计是以模块为基础的，在需求分析阶段，已经把系统分成 层次结构 。设计阶段，以需求分析的结果为依据，
从实现的角度进一步划分为 模块,并组成 模块的层次结构 。
软件结构的设计是概要设计关键的一步，直接影响到下一阶段详细设计与编码的工作软件系统的质量及一些整体特性都在软件结构的设计中决定。
4.2 软件概要设计学 生 信 息 系 统登陆验证成绩管理基本信息管理用户管理修改用户查找用户删除用户添加用户查找成绩修改成绩删除成绩添加成绩查找学生修改学生添加学生删除学生学 生 信 息 系 统 功 能 模 块 图课程管理查找课程修改课程删除课程添加课程
4.2 软件概要设计
2.数据结构及数据库设计
对于大型数据处理的软件系统，除了控制结构的模块设计外，数据结构与数据库设计也是很重要。
(1)数据结构的设计
逐步细化的方法也适用于数据结构的设计。需求分析阶段，在数据字典中对数据的组成、操作约束、数据之间的关系等方面进行描述，确定了数据的结构特性；
在概要设计阶段要细化抽象的数据类型；
详细设计阶段则规定具体的实现细节。
4.2 软件概要设计
(2)数据库的设计
数据库的设计指数据存储文件的设计，主要进行以下几方面设计
①概念设计。在数据分析的基础上，采用自底向上的方法从用户角度进行视图设计，一般用 ER模型来表示数据模型，这是一个概念模型。
E-R模型（实体 -关系,Entity-Relationship）
矩形框 -----实体
菱形框 ----关系
椭圆形 ----属性
无向边 ----将实体和其属性连接
4.2 软件概要设计
E-R模型 4.2 软件概要设计
② 逻辑设计。 ER模型是独立于数据库管理系统的，
要结合具体的 DBMS特征来建立数据库的逻辑结构。给出数据结构的定义，即定义所含的数据项、类型、长度及它们之间的层次或相互关系的表格等等。
③物理设计。对于不同的 DBMS，应用的物理环境不同，提供的存储结构与存取方法各不相同。
物理设计就是根据设计数据模式的要求，选取适合的 DBMS 。
本例选用 Access作为后台数据库
4.2 软件概要设计
4.2 软件概要设计
学生成绩信息数据库中包含四个基本表，分别保存学生的基本信息、成绩信息、课程信息以及系统的用户信息表，每个基本表的数据项和数据结构如下表所示：
（ 1） 学生基本信息表,
表中使用学号字段作为主键。
字段名 数据类型 长度 值唯一 必填项 默认值学号 文本 15 √ √ 无姓名 文本 10 √ 无性别 文本 2 无出生日期 日期 /时间 无班级 文本 10 无
4.2 软件概要设计
（ 2）成绩信息表：表中学号和课程号为主键。学号字段是外键，引用学生基本信息表中的学号字段值。
字段名 数据类型 长度 值唯一 必填项 默认值学号 文本 15 √ √ 无课程号 文本 10 √ 无分数 数字 4 √ 无主键：唯一能标示一个记录，且不含多余项
4.2 软件概要设计
（ 3）课程信息表：表中使用课号字段作为主键。
字段名 数据类型 长度 值唯一 必填项 默认值课号 文本 15 √ √ 无课程 文本 20 无
（ 4）用户信息表：表中使用帐号字段作为主键。
字段名 数据类型 长度 值唯一 必填项 默认值用户名 文本 15 √ √ 无密码 文本 10 无权限 文本 10 √ 无
3.编写概要设计文档
(1)概要设计说明书。
(2)数据库设计说明书，主要给出所使用的 DBMS简介、
数据库的概念模型、逻辑设计、结果。
(3)用户手册，对需求分析阶段编写的用户手册作补充。
(4)修订测试计划，对测试策略、方法、步骤提出明确要求。
4.评审
对设计部分是否完整地实现了需求中规定的功能、性能等要求，设计方案的可行性，关键的处理及内外部接口定义正确性、有效性，各部分之间的一致性等等都一一进行评审。
4.2 软件概要设计
4.3 软件详细设计
目的：掌握软件详细设计的任务和思想
详细设计的基本任务有
(1)为每个模块进行详细的算法设计。用某种图形、
表格、语言等工具将每个模块处理过程的详细算法描述出来。
(2)为模块内的数据结构进行设计。对于需求分析、概要设计确定的概念性的数据类型进行确切的定义。
(3)对数据结构进行物理设计，即确定数据库的物理结构。物理结构主要指数据库的存储记录格式、存储记录安排和存储方法，这些都依赖于具体所使用的数据库系统。
(4)其他设计：根据软件系统的类型，还可能要进行以下设计：
① 代码设计。为了提高数据的输入、分类、存储、检索等操作，节约内存空间，对数据库中的某些数据项的值要进行代码设计。
② 输入 /输出格式设计。
③ 人机对话设计。对于一个实时系统，用户与计算机频繁对话，因此要进行对话方式、内容、格式的具体设计。
(5)编写详细设计说明书。
(6)评审。对处理过程的算法和数据库的物理结构都要评审
4.3 软件详细设计
4.3 软件详细设计
设计主窗体如图所示：
4.3 软件详细设计
登录窗体 修改密码
4.3 软件详细设计
添加、删除用户窗体
4.3 软件详细设计
添加、修改学籍窗体
4.3 软件详细设计
查询学籍窗体
4.3 软件详细设计
添加、修改课程窗体
4.3 软件详细设计
输入成绩窗体
4.3 软件详细设计
修改成绩窗体
4.3 软件详细设计
2,数据库实现
启动 Access，创建一个新的数据库，命名为
student.mdb，保存在要存放这个系统的所有工程文件的文件夹中。
学生成绩信息数据库中的表格设计视图如下所示，
每个表格都代表数据库中的一个独立的表。
学生基本信息设计视图：
4.3 软件详细设计
成绩信息设计视图：
课程信息设计视图：
4.3 软件详细设计
系统用户设计视图：
4.4 软件实现
目的：使用编程工具完成系统编码
在软件实现阶段,根据详细设计用编程语言编写所需的程序 。 这个阶段的文档包括,软件需求规格说明书,,,高层设计说明书,,,详细设计说明书,,
,单元测试计划,编码,用户接口标准等,输出有测试数据,源代码,可执行代码,,单元测试报告,,
需要完成的任务包括：
1.根据详细设计,按照编码,用户接口规范编写程序
2.对程序进行代码复查,编译,调试,直到程序运行通过,符合详细设计的要求；
3.根据单元测试计划进行单元测试,生成单元测试报告 。
4.5 软件测试
目的：掌握进行测试工作的方法和技巧
软件测试是为了发现错误而执行程序的过程，
一个好的测试用例能够发现至今尚未发现的错误，一个成功的测试是发现了至今尚未发现的错误的测试。因此，测试阶段的基本任务应该是根据软件开发各阶段的文档资料和程序的内部结构，精心设计一组,高产,的测试用例，
利用这些实例执行程序，找出软件中潜在的各种错误和缺陷。
软件测试方法一般分为两大类：动态测试方法与静态测试方法。
1,静态测试 静态测试是指被测试程序不在机器上运行，而是采用人工检测和计算机辅助静态分析的手段对程序进行检测。
(1)人工检测。人工检测是不依靠计算机而是靠人工审查程序或评审软件。
(2)计算机辅助静态分析。利用静态分析工具对被测试程序进行特性分析，从程序中提取一些信息，以便检查程序逻辑的各种缺陷和可疑的程序构造。
2,动态测试 一般意义上的测试大多是指动态测试。
有两种方法，分别是黑盒测试法和白盒测试法。
4.5 软件测试
黑盒测试法与白盒测试法
1,黑盒法 该方法把被测试对象看成一个黑盒子，
测试人员完全不考虑程序的内部结构和处理过程，
只在软件的接口处进行测试，依据需求规格说明书，检查程序是否满足功能要求。因此，黑盒测试又称为功能测试或数据驱动测试。通过黑盒测试主要发现以下错误：
(1)是否有不正确或遗漏了的功能。
(2)在接口上，能否正确地接受输入数据，能否产生正确的输出信息。
(3)访问外部信息是否有错。
(4)性能上是否满足要求等等。
4.5 软件测试
2,白盒法 该方法把测试对象看作一个打开的盒子，
测试人员须了解程序的内部结构和处理过程，
以检查处理过程的细节为基础，对程序中尽可能多的逻辑路径进行测试，检查内部控制结构和数据结构是否有错，实际的运行状态与预期的状态是否一致。
黑盒法和白盒法都不能使测试达到彻底。为了用有限的测试发现更多的错误，需精心设计测试用例。
4.5 软件测试
3.6 软件维护
目的：掌握进行软件维护工作的防范,认识维护工作的重要性
软件投入使用后就进入软件维护阶段 。 维护阶段是软件生存周期中时间最长的一个阶段,所花费的精力和费用也是最多的一个阶段 。
软件维护内容有四种：校正性维护，适应性维护，完善性维护和预防性维护。
4.5 软件维护
1.校正性维护
在软件交付使用后，由于在软件开发过程中产生的错误并没有完全彻底的在测试中发现，因此必然有一部分隐含的错误被带到维护阶段来。
这些隐含的错误在某些特定的使用环境下会暴露出来。为了识别和纠正错误，修改软件性能上的缺陷，应进行确定和修改错误的过程，这个过程就称为校正性维护。校正性维护占整个维护工作的 20%左右。
4.5 软件维护
2.适应性维护
随着计算机的飞速发展，计算机硬件和软件环境也在不断发生变化，数据环境也在不断发生变化。为了使应用软件适应这种而修改软件的过程称为适应性维护。这种维护活动占整个维护活动的 25%。
4.5 软件维护
3.完善性维护
在软件漫长的运行时期中，用户往往会对软件提出新的功能要求与性能要求。这是因为用户的业务会发生变化，组织机构也会发生变化。
为了适应这些变化，应用软件原来的功能和性能需要扩充和增强，为达到这个目的而进行的维护活动称为完善性维护，占整个维护活动的
50%。
4.5 软件维护
4.预防性维护
为了提高软件的可维护性和可靠性而对软件进行的修改称为预防性维护。这是为以后进一步的运行和维护打好基础，占整个维护工作的 4%。
4.5 软件维护一个 ATM机的模型设计
1,划分主题
在开发大型、复杂系统的过程中，为了降低复杂程度，需要系统划分成几个不同的主题。
一般按问题领域而不是用功能分解方法来确定主题。
一般按不同主题间对象相互间依赖和交互最少的原则来确定主题。
以 ATM系统为例，我们可以把它划分成,总行,,,分行,和,ATM”等三个主题，这三个主题的编号分别是 1,2和 3，如下图所示。
4.6 一个 ATM机的模型设计
2,确定属性
从需求陈述中选择属性，属性的确定既与问题域有关，也和目标系统的任务有关。
用名词词组表示属性，例如,,汽车的颜色,或
,光标的位置,。用形容词表示可枚举的具体属性，
例如,,红色的,,,打开的,。
应该仅考虑与具体应用直接相关的属性，不要考虑那些超出所要解决的问题范围的属性。
4.6 一个 ATM机的模型设计
3,建立动态模型
在开发交互式系统时，动态模型起着很重要的作用。
建立动态模型分三步
第一步为编写典型交互行为的脚本。 脚本描述常见的交互行为。
第二步 从脚本中提取出事件，确定触发每个事件的动作对象以及接受事件的目标对象。
第三步，排列事件发生的次序，确定每个对象可能有的状态及状态间的转换关系，并用状态图描绘它们。
4.6 一个 ATM机的模型设计
（ 1） 编写脚本
在建立动态模型的过程中，脚本是指系统在某一执行期间内出现的一系列事件。
脚本描述用户 (或其他外部设备 )与目标系统之间的一个或多个典型的交互过程，以便对目标系统的行为有更具体的认识。
编写脚本的目的，是保证不遗漏重要的交互步骤，
它有助于确保整个交互过程的正确性的和清晰性。
下面给出了 ATM系统的正常情况脚本
4.6 一个 ATM机的模型设计
① ATM请储户插卡 ;储户插入一张现金兑换卡。
② ATM接受该卡并读它上面的分行代码和卡号。
③ ATM要求储户输入密码 ;储户输入自己的密码
"1234"等数字。
④ ATM请求总行验证卡号和密码 ;总行要求 "39"号分行核对储户密码，然后通知 ATM说这张卡有效。
⑤ ATM要求储户选择事务类型 (取款、转账、查询等 );储户选择 "取款 "。
⑥ ATM要求储户输入取款额 ;储户输入 "880"。
4.6 一个 ATM机的模型设计
⑦ ATM确认取款额在预先规定的限额内，然后要求总行处理这个事务 ;总行把请求转给分行，该分行成功地处理完这项事务并返回该账户的新余额。
⑧ ATM吐出现金并请储户拿走这些现金；储户拿走现金。
⑨ ATM问储户是否继续这项事务 ;储户回答 "不 "。
⑩ ATM打印账单，退出现金兑换卡，请储户拿走它们；储户取走账单和卡。
⑾ ATM请储户插卡。
下面给出 ATM系统的异常情况脚本
4.6 一个 ATM机的模型设计
① ATM接受这张卡并顺序读它上面的数字。
ATM要求密码 ;储户误输入 "8888"。
② ATM请求总行验证输入的数字和密码 ;总行在向有关分行咨询之后拒绝这张卡。
③ ATM显示 "密码错 "，并请储户重新输入密码 ;储户输入 "1234";ATM请总行验证后知道这次输入的密码正确。
④ ATM请储户选择事务类型 ;储户选择 "取款 "。
⑤ ATM询问取款额 ;储户改变主意不想取款了，他敲 "
取消 "键。
⑥ ATM退出现金兑换卡，并请储户拿走它储户拿走他的卡。
⑦ ATM请储户插卡。
ATM的界面格式
4.6 一个 ATM机的模型设计
（ 2）画事件跟踪图
通常在画状态图之前先画出事件跟踪图。首先需要明确事件及事件与对象的关系。
a.确定事件
外部事件包括系统与用户 (或外部设备 )交互的所有信号、输入、输出、中断、动作等,
对产生相同效果的那些事件组合在一起作为一类事件。例如,,吐出现金,是一个事件类。
4.6 一个 ATM机的模型设计
b.画出事件跟踪图
在事件跟踪图中規定，
① 一条竖线代表一个类与对象；
② 每个事件用一条水平的箭头线表示，箭头方向从事件的发送对象指向接受对象。
③ 时间从上向下递增，画在最上面的水平箭头线代表最先发生的事件，画在最下面的水平箭头线所代表的事件最晚发生。箭头线之间的间距并没有具体含义，箭头线位置也不表示两个事件之间的精确时间差。
4.6 一个 ATM机的模型设计
c,画状态图
一般说来，不同应用系统对相同事件的响应并不相同，因此，在最终分类所有事件之前，必须先画出状态图。如果从状态图中看出某些事件之间的差异对系统行为并没有影响，则可以忽略这些事件间的差异
状态图描绘事件与对象状态的关系。当对象接受了一个事件以后，它的下个状态取决于当前状态及所接受的事件。
由事件引起的状态改变称为,转换,。如果一个事件并不引起当前状态发生转换，则可忽略这个事件。
下图为 ATM状态图
4.6 一个 ATM机的模型设计下图为总行类状态图
4.6 一个 ATM机的模型设计下图为分行类状态图
4.6 一个 ATM机的模型设计
4、建立功能模型
功能模型表明了系统中数据之间的依赖关系，以及有关的数据处理功能，它由一组数据流图组成。
通常在建立了对象模型和动态模型之后再建立功能模型。
(1) 画出基本系统模型图
基本系统模型由若干个数据源点 /终点，及一个处理框组成，这个处理框代表了系统加工、变换数据的整体功能。
基本系统模型指明了目标系统的边界。由数据源点输入的数据和输出到数据终点的数据，是系统与外部世界之间的交互事件的参数。
4.6 一个 ATM机的模型设计
ATM系统的基本系统模型,
本系统的数据源点 /终点为储户,尽管在储蓄所内储户的事务是由柜员通过柜员终端提交给系统的，但是信息的来源和最终接受者都是储户。
另一个数据源点是现金兑换卡，因为系统从它上面读取分行代码、卡号等信息。
(2) 画出功能级数据流图
把基本系统模型中单一的处理框分解成若干个处理框，以描述系统加工、变换数据的基本功能，
就得到功能级数据流图。
4.6 一个 ATM机的模型设计
(3) 描述处理框功能
把数据流图分解细化到一定程度之后，就应该描述图中各个处理框的功能。
注意：描述每个处理框所代表的功能，而不是实现功能的具体算法。
描述既可以是说明性的，也可以是过程性的。
说明性描述规定了输入值和输出值之间的关系，
以及输出值应遵循的规律。
过程性描述则通过算法说明,做什么,。
4.6 一个 ATM机的模型设计
ATM系统数据流图中对,更新账户,处理功能：
更新账户 (账号,事务类型,金额 )→ 现金额,账单数据,信息
如果取款额超过账户当前余额，拒绝该事务且不付出现金。
如果取款额不超过账户当前余额，从余额中减去取款额后作为新的余额，付出储户要取的现金。
如果事务是存款，把存款额加到余额中得到新余额，
不付出现金。
如果事务是查询，不付出现金。
在上述任何一种情况下，账单内容都是,ATM号，
日期，时间，账号，事务类型 ·事务金额 (如果有的话 )，
新余额。
