软件工程 课件全套1-9 软件工程基础 - 状态图讲课内容（主要内容讲解）

第1章

软件工程基础软件工程基础

软件系统与现代化文明

迄今为止，软件系统已经成为信息化的关键因素。研究表明软件行业发展指数能够展现一个民族和国家的现代化文明程度。然而，人类在软件开发中遭遇了一系列困难，并且仍然没有有效的办法摆脱相关的困扰。因此，当前阶段，计算机行业的发展受制于软件的发展。

软件工程学科的诞生

为了解决软件系统开发与维护过程中的困难，相关的计算机行业专家于1968年着手研究解决软件困境的方法和管理措施，经过若干年的发展和完善，形成了一门崭新的学科——软件工程。1.1软件危机

1965年之前，每一个具体的应用开发专用软件；一般代码量不大；开发者依据本人或者组织的实际需要开发；只保存很少的文档资料；这对软件的维护极其不利。

1965年至1975进入了“软件作坊”时代。继续使用个性化的开发技术；各组织的软件数量不断增加。

需要对软件实施维护的情况1.操作系统或者硬件更新后；3.在程序运行过程中发现错误时2.在软件开发过程中或使用期间，用户有了新的需求4.程序运行过程中，存在影响系统安全的漏洞时软件危机出现了！软件工程学科诞生！

软件维护代价越来越大，最严重的问题：程序开发者不在现场，软件不可维护；

“软件危机”出现！

1968年，专家们在联邦德国召开会议，主题：什么是软件危机？如何解决软件危机？专家们提出“软件工程”概念，标志着“软件工程”学科诞生。1.1.1有关软件危机的介绍导致软件危机的两个问题：1.软件需求日益增长，如何组织软件开发？2.面对各组织中已开发的大量软件，该如何维护？具体表现（1）开发成本估算、进度预估不准确。“已完成”的软件不能满足用户要求。软件开发过程中，没有统一规范的过程模型，没有详细的文档资料。运行中，经常出现让人不满意或故障具体表现（2）无法维护、升级或更新软件开发生产率提高的速度跟不上技术进步的步伐软件成本所占比例逐年提高总结：实际项目中，

有更多的问题1.1.2原因与解决方法——原因（1）软件是人类创造的最复杂的产品，规模庞大、结构复杂，给软件开发和维护带来困难。（2）项目管理困难。软件具有无形性，导致管理困难，尤其在进度控制、质量控制方面。（3）软件开发费用、

维护成本急剧上升，影响信息化、数字化推广范围。（4）开发技术无法紧跟时代要求。专家注重理论研究，忽视开发技术研究。（5）开发工具落后，生产效率偏低。（6）需求分析的重要性被忽视。开发人员、用户的沟通不及时、不充分，文档资料不全。（7）软件运行、维护过程中管理不善。1.1.2原因与解决方法——解决方法（1）应用适合的软件开发技术和方法。（2）使用适合的软件工具。（3）实施良好的管理，各类人员默契配合。1.2软件工程——定义和目标1.定义

软件工程是采用工程化的思维、原理、技术手段与方法，用以指导软件开发全过程以及软件维护的一门学科。NATO会议：“为了用较低的成本，开发出在设备设施上运行软件，而确立并使用的一系列工程原理。”IEEE定义：“①把系统的、规范的、可度量的方法应用于系统开发、软件实施与维护过程，即把工程化思维应用于软件开发；②研究①中提到的方法。”

2.目标（1）满足客户的全部功能需求、性能要求（2）开发成本尽量低（3）软件企业须依据合同实施，及时交付软件产品（4）软件具有易于维护，较高的可靠性（5）软件具有易用性、可重用性和可移植性1.2.2相关原理（1）01采用生命周期法管理软件开发过程。02始终坚持实施阶段评审。03实行严格的产品控制。1.2.2相关原理（2）04使用现代的程序设计方法。05成果可以审查。06团队成员少而精。0507必须意识到逐步改进并提升工程实践的重要性和必要性。1.2.3软件工程的进步史01传统的软件工程阶段03面向过程工程02面向对象工程04面向构件工程1.3.1软件过程

ISO9000，软件过程：“将输入转化成输出的一系列彼此相关联的资源、活动。”软件过程是为了开发出较高质量的软件所需实现的一系列任务框架。

软件过程：将用户需求转化为软件需求，进而转化为设计方案，并用代码实现设计，继而完成测试和各阶段的文档编制工作，最终确认软件可以部署实施的过程。1.3.2软件生存周期软件生存周期是指从软件研发开始到软件停用的整个过程，

即从提出开发需求，

经过分析、设计、开发、使用和维护等阶段，直到淘汰的整个过程。软件生存周期是由软件定义、开发与维护三个阶段组成，

并且每个阶段又可以进一步分成多个阶段。1.3.2软件生存周期——阶段一：软件定义（1）问题定义：“项目需要解决哪些问题？”调查和研究，写出任务性质、项目目标、项目规模的报告，讨论和研究分析，修改，形成一份书面报告，获得用户的确认。生成结果：问题定义报告。（2）可行性研究：对当前项目的功能需求、技术及市场情况进行调研，并结合实际进行初步分析，明确是否可以启动该项目。可行性研究是一次简化的软件分析与设计过程。可行性研究工作比较简短，只是从较高层次研究问题范围，研究该问题是否可以解决，是否值得解决，是否有可行的解决方案。参与人员：技术主管、技术人员。结果：可行性研究报告、技术方面的调研报告。（3）项目启动：由技术主管或相关负责人制定合同，启动项目，由项目经理制定项目初步计划。结果：任务（项目）计划书、项目合同。1.3.2软件生存周期——软件开发（研发）阶段需求分析：明确软件必须具有哪些功能、性能等。任务：对项目进行详细的需求分析，并编写需求文档。对于B/S结构的软件应制作静态页面效果图。用户：一般不懂技术，往往无法完整准确表达清楚要求；开发人员：不懂业务。需求分析阶段，

系统分析员必须与用户密切配合，充分沟通。参与者：项目经理、项目小组核心成员结果：项目计划修订说明、需求分析说明书、静态演示页面1.3.2软件生存周期——软件开发（研发）阶段概要设计：软件的总体(外部)结构、组成模块、模块的层次结构、调用关系及功能进行设计，并对总体数据结构进行设计。任务：

依据需求分析规格说明书，

为详细设计提供基础。参与者：项目小组核心成员、项目经理、技术主管；结果：概要设计说明书。详细设计：对模块的功能、性能等在技术层面进行完整准确的描述，并转化成过程描述。任务：将每个模块进行详细设计，明确实现各模块的算法与数据结构。若软件比较简单，可不单独编写，相关内容与概要设计说明书一起编写。参与者：小组成员、项目经理；生成结果：软件详细设计说明书、项目计划确定版本。编码实现：写代码。任务：根据详细设计编程实现，美工对操作界面进行美化。参与者：项目经理、程序员、美工。生成结果：软件版本说明、软件产品规格说明。1.3.2软件生存周期—软件开发（研发）阶段测试：确保软件质量。使用各种工具和方法对软件的功能、性能进行检测。任务：项目经理提交测试申请，由测试部门实施测试，项目小组配合测试部门完成错误修改。参与者：测试部门、项目经理、程序开发人员结果：测试申请书、测试计划书、测试报告系统验收：对项目实施验收工作参与者：技术部门主管、项目经理、用户结果：项目所有文档和程序软件过程与软件生命周期：1.3.2软件生存周期软件交付并投入使用后，

便进入软件维护阶段。目的：让软件一直满足用户的需要。该阶段是软件生存周期的最后一

个阶段，持续时间最长的阶段。软件维护阶段1.4软件开发过程模型

根据实践的需要，对软件开发过程进行分类，形成多种风格的软件开发模型，称为软件生存周期模型，或称为软件开发范型。1.4.1瀑布模型软件开发过程按照顺序进行，一步接着一步做。瀑布模型将软件开发过程分为问题定义、可行性研究、需求分析、概要设计、详细设计、软件实现、软件测试、运行维护。1.4.1瀑布模型瀑布模型较适合那些软件需求较明确，开发技术较成熟，项目管理较严格的场合。使用瀑布模型实施项目具有3个特点：①按照顺序开发软件；②不要过早编程；③确保软件质量。各阶段必须按照要求完成相关文档资料的书写和汇总，并且每个阶段都要对书写的文档资料组织复审，及时发现相关隐患并排除。瀑布模型缺陷：将软件实践中相互叠加的过程分成若干阶段。软件规模越大带来的问题越多。因此，人们对瀑布模型增加回溯和反馈的环节，对其加以改进。1.4.2快速原型模型根据用户的要求，先快速开发一个压缩版的原型系统，并在此基础上对客户、潜在用户进行交流。

用户对原型系统进行评价，提出改进意见，细化软件需求。通过逐步构建原型系统从而达到客户要求，继而准确获取客户的实际需求；最终依据详细且实际的需求组织开发软件。1.4.3增量模型增量模型将一系列构件实施集成和测试，每个构件完成不同的功能，最终将其组合成在一起构成完整功能软件。增量模型的灵活性较强，较适用于需求不太明确、软件设计方案具有一定风险的项目。见教材图1.3。对比：瀑布模型是一种整体推进的开发模型，

在进行下一阶

段的任务之前，

必须完成上一阶段的工作。增量模型是一种非整体开发模型，

根据需要可以推迟某个阶段甚至所有阶段的具体细节，而较早实现软件的研发。不过，增量模型也具有较明显的缺陷。增量模型缺陷增量模型要求在研发的软件具有开放式的体系架构。原因是各个构件是人工逐步并入到已存在的软件体系结构中的，因此，加入的新构件不可以破坏已实现的软件结构。

对软件过程的控制，容易失去整体性。实际的软件开发中，用户经常对需求产生变化，在这方面，增量模型更适合这种变化，不过也很容易退化成一边做一边修改开发模型的情况。1.4.4螺旋模型计划阶段：明确软件的目标，确定最终实施方案，理清楚项目的约束条件；风险分析阶段：评估选定的方案，设法识别并消除风险。实施阶段：实施软件开发，并对项目进行验证。评估阶段：对开发工作进行评价，提出相应的修改建议，并明确下一步的计划。1.4.5喷泉模型喷泉模型以用户的需求作为喷泉的起源，

以面向对象方法为基础。开发过程可以分为四个阶段：需求分析阶段、总体设计阶段、详细设计阶段、实现阶段，并且每个阶段可以继续分成多个步骤。每个阶段互相叠加，反映出软件过程的并行性特征。解决了瀑布模型无法支持软件重用及多个开发业务集成的问题，较适用于使用面向对象方法与技术的项目。如图1.5所示，展示了喷泉模型的特点：所示：1.4.7如何选定开发模型0102瀑布模型与原型模型是最常用的开发过程模型，

其次应用较普遍的是增量模型。由于不同的模型具有不同的特点与优缺点。到底如何选择开发模型？（1）是否符合软件自身的特点，其中包括软件规模及其复杂性等方面。（2）是否满足软件开发的总体进度要求。（3）尽可能识别软件开发过程中的风险因素，并设法控制并消除这些风险。（4）是否具有相关辅助工具的支持，比如实现快速原型的工具。（5）选用模型是否与用户和参与人员的知识背景及技能匹配。（6）是否有利于软件项目的控制与管理。1.4.7如何选定开发模型

总结：事实上，

在实际的软件开发过程中，

开发模型的选取不是照搬照抄，

需要依据开发目标的要求实行修改、综合运用。讨论和作业安排THEEND清华大学出版社第2章可行性研究张海藩，牟永敏编著第2章可行性研究并非任何问题都有简单明显的解决办法，事实上，许多问题不可能在预定的系统规模或时间期限之内解决。如果问题没有可行的解，那么花费在这项工程上的任何时间、人力、软硬件资源和经费，都是无谓的浪费。可行性研究的目的，就是用最小的代价在尽可能短的时间内确定问题是否能够解决。主要内容2.1可行性研究的任务2.2可行性研究过程2.3系统流程图2.4数据流图2.5数据字典2.6成本/效益分析主要内容2.1可行性研究的任务2.2可行性研究过程2.3系统流程图2.4数据流图2.5数据字典2.6成本/效益分析2.1可行性研究的任务可行性研究的目的不是解决问题，而是确定问题是否值得去解决。首先，进一步分析和澄清问题定义然后，分析员应该导出系统的逻辑模型最后，探索若干种可供选择的主要解法可行性研究分析过程：2.1

可行性研究的任务至少应该从下述3个方面研究每种解法的可行性技术可行性使用现有的技术能实现这个系统吗?经济可行性这个系统的经济效益能超过它的开发成本吗?操作可行性系统的操作方式在这个用户组织内行得通吗?主要内容2.1可行性研究的任务2.2可行性研究过程2.3系统流程图2.4数据流图2.5数据字典2.6成本/效益分析2.2可行性研究过程怎样进行可行性研究呢?典型的可行性研究过程有下述8个步骤。复查系统规模和目标研究目前正在使用的系统导出新系统的高层逻辑模型进一步定义问题导出和评价供选择的解法推荐行动方针草拟开发计划书写文档提交审查2.2

可行性研究过程复查系统规模和目标分析员访问关键人员，仔细阅读和分析有关的材料，以便对问题定义阶段书写的关于规模和目标的报告书进一步复查确认，改正含糊或不确切的叙述，清晰地描述对目标系统的一切限制和约束。这个步骤的工作，实质上是为了确保分析员正在解决的问题确实是要求他解决的问题。2.2可行性研究过程2.研究目前正在使用的系统现有的系统是信息的重要来源。显然，如果目前有一个系统正被人使用，那么这个系统必定能完成某些有用的工作，因此，新的目标系统必须也能完成它的基本功能；另一方面，如果现有的系统是完美无缺的，用户自然不会提出开发新系统的要求，因此，现有的系统必然有某些缺点，新系统必须能解决旧系统中存在的问题。应该仔细阅读分析现有系统的文档资料和使用手册，也要实地考察现有的系统。常见的错误做法是花费过多时间去分析现有的系统。没有一个系统是在“真空”中运行的，绝大多数系统都和其他系统有联系。2.2

可行性研究过程3.导出新系统的高层逻辑模型优秀的设计过程通常是从现有的物理系统出发，导出现有系统的逻辑模型，再参考现有系统的逻辑模型，设想目标系统的逻辑模型，最后根据目标系统的逻辑模型建造新的物理系统。4.进一步定义问题可行性研究的前4个步骤实质上构成一个循环。分析员定义问题，分析这个问题，导出一个试探性的解；在此基础上再次定义问题，再一次分析这个问题，修改这个解；继续这个循环过程，直到提出的逻辑模型完全符合系统目标。2.2可行性研究过程5.导出和评价供选择的解法分析员应该从他建议的系统逻辑模型出发，导出若干个较高层次的物理解法供比较和选择。其次可以考虑操作方面的可行性。分析员应该根据使用部门处理事务的原则和习惯检查技术上可行的那些方案，去掉其中从操作方式或操作过程的角度看用户不能接受的方案。接下来应该考虑经济方面的可行性。分析员应该估计余下的每个可能的系统的开发成本和运行费用，并且估计相对于现有的系统而言这个系统可以节省的开支或可以增加的收入。最后为每个在技术、操作和经济等方面都可行的系统制定实现进度表，这个进度表不需要制定得很详细，通常只需要估计生命周期每个阶段的工作量。2.2可行性研究过程6.导出和评价供选择的解法根据可行性研究结果应该决定的一个关键性问题是：是否继续进行这项开发工程？分析员必须清楚地表明他对这个关键性决定的建议。如果分析员认为值得继续进行这项开发工程，那么他应该选择一种最好的解法，并且说明选择这个解决方案的理由。通常客户主要根据经济上是否划算决定是否投资于一项开发工程，因此分析员对于所推荐的系统必须进行比较仔细的成本/效益分析。2.2

可行性研究过程7.草拟开发计划分析员应该为所推荐的方案草拟一份开发计划，除了制定工程进度表之外还应该估计对各类开发人员和各种资源的需要情况，应该指明什么时候使用以及使用多长时间。此外还应该估计系统生命周期每个阶段的成本。最后应该给出下一个阶段(需求分析)的详细进度表和成本估计。8.书写文档提交审查应该把上述可行性研究各个步骤的工作结果写成清晰的文档，请用户、客户组织的负责人及评审组审查，以决定是否继续这项工程及是否接受分析员推荐的方案。2.3

系统流程图系统流程图是概括地描绘物理系统的传统工具。应用：在进行可行性研究时，需要分析现有系统，并以概括的形式表达对现有系统的认识；进入设计阶段以后，也需要把新系统的逻辑模型转变成物理模型，需要描绘未来的物理系统的概貌。基本思想：用图形符号以黑盒子形式描绘组成系统的每个部件(程序、文档、数据库、人工过程等)。系统流程图表达的是数据在系统各部件之间流动的情况，而不是对数据进行加工处理的控制过程，因此尽管系统流程图的某些符号和程序流程图的符号形式相同，但是它却是物理数据流图而不是程序流程图。第2章可行性研究2.1可行性研究的任务2.2可行性研究过程2.3系统流程图2.4数据流图2.5数据字典2.6成本/效益分析2.3系统流程图2.3.1符号当以概括的方式抽象地描绘一个实际系统时，仅仅使用图2.1中列出的基本符号就可以了。见课本P39页。当需要更具体地描绘一个物理系统时，还需要更多的符号。见课本P39页图2.2。利用这些符号可以把一个广义的输入输出操作具体化为读写存储在特殊设备上的文件（或数据库），把抽象处理具体化为特定的程序或手工操作等。2.3系统流程图以概括的方式抽象地描绘一个实际系统时，仅仅使用下图中列出的基本符号就足够了需要更具体地描绘一个物理系统时还需要使用右图中列出的系统符号2.3

系统流程图以一个简单的例子进行讲解。某装配厂有一座存放零件的仓库，仓库中现有的各种零件的数量以及每种零件的库存量临界值等数据记录在库存清单主文件中。当仓库中零件数量有变化时，应该及时修改库存清单主文件，如果哪种零件的库存量少于它的库存量临界值，则应该报告给采购部门以便订货，规定每天向采购部门送一次订货报告。2.3.2例子2.3

系统流程图该装配厂使用一台小型计算机处理更新库存清单主文件和产生订货报告的任务。零件库存量的每一次变化称为一个事务，由放在仓库中的CRT终端输入到计算机中；系统中的库存清单程序对事务进行处理，更新存储在磁盘上的库存清单主文件，并且把必要的订货信息写在磁带上。最后，每天由报告生成程序读一次磁带，并且打印出订货报告。如下图所示。2.3系统流程图一个比较好的方法是分层次描绘这个系统。首先用一张高层次的系统流程图描绘系统总体概况，表明系统的关键功能。然后分别把每个关键功能扩展到适当的详细程度，画在单独的一页纸上。这种分层次的描绘方法便于阅读者按从抽象到具体的过程逐步深入地了解一个复杂的系统。2.3.3分层面对复杂的系统时，怎么办？主要内容2.1可行性研究的任务2.2可行性研究过程2.3系统流程图2.4数据流图2.5数据字典2.6成本/效益分析2.4

数据流图概念

数据流图(DFD)是一种图形化技术，它描绘信息流和数据从输入移动到输出的过程中所经受的变换。当数据在软件系统中移动时，它将被一系列“变换”所修改。数据流图中，没有任何具体的物理部件，它只是描绘数据在软件中流动和被处理的逻辑过程。数据流图是系统逻辑功能的图形表示，即使不是专业的计算机技术人员也容易理解它。因此，数据流图是分析员和用户之间极好的通信工具。2.4

数据流图2.4.1

符号正方形表示数据的源点或终点圆角矩形代表变换数据的处理开口矩形代表数据存储箭头表示数据流，即特定数据的流动方向数据流四中基本符号附加符号基本符号

注意：

“处理”并不一定是一个程序。一个处理框可以代表程序的一个模块、单个程序或一系列程序，也可以是人工处理过程（比如人工检查数据正确性）。

“数据存储”也不等同于一个文件，它可以表示一个文件、文件的一部分、数据库的元素或者记录的一部分。（例如查询操作、修改某个记录、某个字段）数据可以存储在磁盘、磁带、主存、磁鼓、微缩胶片、穿孔卡片等介质上。数据存储和数据流的区别？

静止、运动

注意：

数据流图基本要点：描绘“做什么”，不考虑“怎样做”。在数据流图中应该描绘所有可能的数据流向，而不应该描绘出现某个数据流的条件。通常在数据流图中忽略出错处理，也不包括诸如打开或者关闭文件等内务处理。

易混淆的地方：数据流与程序流程图（见P106图5.10）中用箭头表示的控制流有本质区别，不要混淆。对程序流程图比较熟悉的学生，在画数据流图时，往往试图在数据流图中表现分支条件或循环，这是错误的，容易引起混乱。

2.4

数据流图以简单例子说明怎样画数据流图？

假设一家工厂的采购部每天需要一张订货报表，报表按零件编号排序，表中列出所有需要再次订货的零件。对于每个需要再次订货的零件应该列出下述数据：零件编号，零件名称，订货数量，目前价格，主要供应者，次要供应者。零件入库或出库称为事务，通过放在仓库中的CRT终端把事务报告给订货系统。当某种零件的库存数量少于库存量临界值时就应该再次订货。如何画该系统的数据流程图呢？2.4.2

例子2.4

数据流图首先考虑数据的源点和终点，从上面对系统的描述可以知道“采购部每天需要一张订货报表”，“通过放在仓库中的CRT终端把事务报告给订货系统”，所以采购员是数据终点，而仓库管理员是数据源点。第一步可以从问题描述中提取数据流图的4种成分：源点或终点、处理、数据存储和数据流2.4

数据流图因此必须有一个用于产生报表的处理。事务的后果是改变零件库存量，然而任何改变数据的操作都是处理，因此对事务进行的加工是另一个处理。注意，在问题描述中并没有明显地提到需要对事务进行处理，但是通过分析可以看出这种需要。第二步：接下来考虑处理，再一次阅读问题描述，“采购部需要报表”，显然采购部没有这种报表2.4

数据流图系统把订货报表送给采购部，因此订货报表是一个数据流；事务需要从仓库送到系统中，显然事务是另一个数据流。(此例子的事务指：零件入库或出库)产生报表和处理事务这两个处理在时间上明显不匹配——每当有一个事务发生时立即处理它，然而每天只产生一次订货报表。因此，用来产生订货报表的数据必须存放一段时间，也就是应该有一个数据存储。下表给出了上述分析成果，其中加星号标记的是在问题描述中隐含的成分。第三步：最后，我们考虑数据流和数据存储分析结果步骤一：

把数据流图的4种成分都分离出来以后（上图所示），就可以着手画数据流图了步骤二：步骤三：把基本系统模型细化，描绘系统的主要功能步骤四：对功能级数据流图中描绘的系统主要功能进一步细化2.4

数据流图

数据流图中每个成分的命名是否恰当，直接影响数据流图的可理解性。因此，给这些成分起名字时应该仔细推敲。2.4.3

命名2.4数据流图数据流命名时应注意的问题名字应代表整个数据流的内容，而不是仅仅反映它的某些成分不要使用空洞的、缺乏具体含义的名字在为某个数据流(或数据存储)起名字时遇到了困难，则很可能是因为对数据流图分解不恰当造成的，应该试试重新分解2.4

数据流图为处理命名时应注意的问题通常先为数据流命名，然后再为与之相关联的处理命名。名字应该反映整个处理的功能，而不是它的一部分功能。名字最好由一个具体的及物动词加上一个具体的宾语组成。通常名字中仅包括一个动词，如果必须用两个动词才能描述整个处理的功能，则把这个处理再分解成两个处理可能更恰当些。如果在为某个处理命名时遇到困难，则很可能是发现了分解不当的迹象，应考虑重新分解。2.4数据流图1、画数据流图的基本目的是利用它作为交流信息的工具。2、数据流图的另一个主要用途是作为分析和设计的工具。3、数据流图辅助物理系统的设计时，以图中不同处理的定时要求为指南，能够在数据流图上画出许多组自动化边界，每组自动化边界可能意味着一个不同的物理系统。4、一张数据流图包含多少个元素合适？分层，把功能级数据流图细化后得到的处理超过9个时，应该画分图。2.4.4

用途主要内容2.1可行性研究的任务2.2可行性研究过程2.3系统流程图2.4数据流图2.5数据字典2.6成本/效益分析2.5

数据字典概念

数据字典是关于数据的信息的集合，也就是对数据流图中包含的所有元素的定义的集合。2.5数据字典2.5.1

内容数据字典数据流数据存储处理数据流分量

一般说来，数据字典应该由对下列4类元素的定义组成。数据元素的别名就是该元素的其他等价的名字，出现别名主要有下述3个原因：对于同样的数据，不同的用户使用了不同的名字。一个分析员在不同时期对同一个数据使用了不同的名字。两个分析员分别分析同一个数据流时，使用了不同的名字。2.5

数据字典2.5

数据字典由数据元素组成数据的方式只有下述3种基本类型：顺序即以确定次序连接两个或多个分量。选择即从两个或多个可能的元素中选取一个。重复即把指定的分量重复零次或多次。2.5.2定义数据的方法2.5

数据字典第4种关系算符=意思是等价于(或定义为)；+意思是和(即连接两个分量)；［］意思是或(即从方括弧内列出的若干个分量中选择一个)，通常用“|”号隔开供选择的分量；{}意思是重复(即重复花括弧内的分量)；()意思是可选(即圆括弧里的分量可有可无)。2.5

数据字典2.5.3

数据字典的用途数据字典最重要的用途是作为分析阶段的工具数据字典中包含的每个数据元素的控制信息是很有价值的数据字典是开发数据库的第一步，而且是很有价值的一步。2.5数据字典目前，数据字典几乎总是作为CASE“结构化分析与设计工具”的一部分实现的。在开发大型软件系统的过程中，数据字典的规模和复杂程度迅速增加，人工维护数据字典几乎是不可能的。2.5.4数据字典的实现2.5

数据字典在开发小型软件系统时暂时没有数据字典处理程序，建议采用卡片形式书写数据字典，每张卡片上保存描述一个数据的信息。下面给出第2.4节的例子中几个数据元素的数据字典卡片，以具体说明数据字典卡片中上述几项内容的含义。2.5.4数据字典的实现2.5

数据字典2.6成本/效益分析主要内容2.1可行性研究的任务2.2可行性研究过程2.3系统流程图2.4数据流图2.5数据字典2.6成本/效益分析第2章可行性研究2.6成本/效益分析软件开发成本主要表现为人力消耗(乘以平均工资则得到开发费用)。成本估计不是精确的科学，因此应该使用几种不同的估计技术以便相互校验。下面简单介绍3种估算技术。2.6.1

成本估计代码行技术任务分解技术自动估计成本技术2.6成本/效益分析任务分解技术最常用的办法是按开发阶段划分任务。典型环境下各个开发阶段需要使用的人力的百分比大致如下表所示:2.6成本/效益分析成本/效益分析方法主要从四个方面考虑2.6.2

成本/效益分析的方法货币的时间价值投资回收期纯收入投资回收率货币的时间价值通常用利率的形式表示货币的时间价值。假设年利率为i，如果现在存入P元，则n年后可以得到的钱数为：F=P(1+i)n这也就是P元钱在n年后的价值。反之，如果n年后能收入F元钱，那么这些钱的现在价值是：P=F/(1+i)n2.6成本/效益分析2.6.2成本/效益分析的方法第2章可行性研究货币的时间价值

例如，修改一个已有的库存清单系统，使它能在每天送给采购员一份订货报表。修改已有的库存清单程序并且编写产生报表的程序，估计共需5000元；系统修改后能及时订货，这将消除零件短缺问题，估计因此每年可以节省2500元，5年共可节省12500元。但是，不能简单地把5000元和12500元相比较，因为前者是现在投资的钱，后者是若干年以后节省的钱。

假定年利率为12%，利用上面计算货币现在价值的公式可以算出修改库存清单系统后每年预计节省的钱的现在价值，如下表所示。2.6成本/效益分析货币的时间价值2.6成本/效益分析本章小结1.了解可行性研究的必要性，以及如何进行可行性研究2.学习系统流程图、数据流图3.学习数据字典的概念、用途及实现4.成本/效益分析方法本章结束第3章

需求分析需求分析01需求分析

可行性研究的目标：在较短的时间内用较小的代价给出项目是否可行的方案。因此，在可行性阶段，软件开发团队只是掌握了用户的软件项目目标和大体的功能要求，因此，如果想开发出符合用户要求的软件，必须进行用户需求分析。

在整个软件研发过程中，需求分析是一个特别重要的阶段。是否完整准确的获取用户需

求，关系软件研发的成败。需求分析的主要任务是确定软件必须“做什么”，即确定软件的功能需求、性能需求、可靠性等要求。最后，软件分析员（产品经理）应写出《需求规格说

明书》，以文字、表格、模型等形式描述软件的需求。注意，《需求分析规格说明书》的书写工作是一项非常复杂且艰巨的任务。系统分析员与用户之间需沟通的信息非常多，并且在交流过程中，

很容易遗漏重要信息，经常会产生二义性。所以，较全面地掌握需求分析技术是非常重要的工作。3.1任务与步骤

需求分析明确用户需求

需求分析(RequirementsAnalysis)是为了明确用户的具体需求，主要包括功能需求、数据需求、性能需求、可靠性与安全性要求、拓展要求以及运行环境等要求，并且创建软件的逻辑模型，写出“软件需求规格说明(SRS)”等文档。

首先，进行用户意图分析。将用户提出来的各种问题和要求进行归纳整理，通常而言，

用户需求反映在说明书上是功能点列表、数据列表、流程等内容，

不是站在软件开发人员的

角度说明问题。因此，

需要既懂技术又懂业务的系统分析员获取用户需求，

搞清楚用户实际上要做什么，应该做什么，并且把获取的信息清晰明确地表达出来。

其次，

对用户需求进行规范化。当搞清楚用户需求后，

在《需求规格说明书》中建立系

统分析模型，完整、准确且规范地描述将要开发的软件，

务必与用户一起确认，

保证它能够完全符合用户的要求。3.1.1任务需求分析的主要任务是？？？3.1.1任务1.用户要求功能需求即将开发的软件必须实现的功能，通过功能列表列出软件必须实现的全部功能。该部分是最重要的工作。性能需求性能需求是指所开发软件的技术性能指标，

即系统需要满足哪些约束条件，

通常情况下括软件平均响应时间、安全性、网络速率、服务器配置等方面的要求。环境需求系统在运行时需要各种软、硬件条件。比如该软件对服务器、操作系统、外设、数据库软件等具体要求。3.1.1任务接口需求描述软件与外部环境通信的要求，

常见的形式有：

硬件接口需求、用户接口需求、通信接口需求、软件接口需求。界面需求用户界面是人机交互的媒介，界面是否美观大方也是用户非常看重的。未来需求通过与用户交流，

列出不属于当前开发范畴的需求。

不过，

根据分析业务或行业发展趋势，未来非常可能需要完成的功能，便于后期扩展软件功能。3.1.1任务2.分析数据需求

分析软件的数据需求。数据由数据元素组成。使用数据字典对数据进行全面地描述和

定义。数据字典缺点：不直观。使用图形工具来辅助，

层次方框图和Warnier图。3.创建系统的逻辑模型

结合上述获取的结果进行分析与确认，

以确保软件的组成及主要元素是否全面，

并用图

文与符号结合的方式，

导出软件的逻辑模型，

一般会用到数据流图（DFD）、状态转换图、实体联系图（E-R图）、数据字典及主要的算法描述该逻辑模型。4.编写软件需求报告

明确定义目标软件的需求、软件构成及相关的接口。软件需求规格说明书：准确体现用户真实需求，

易理解、直观、易修改等特点。尽可能采用标准的表格、图形与简单容易的符号表示，不用专业性强的术语，让用户看懂，便于交流。3.1.1任务5.需求分析评审（2）

构建评审小组，

组织评审并修改需求和开发计划。确保“软件需求规格说明”真实无遗漏地反映用户的需求。（1）需求分析规格说明书需要经过严格且仔细的评审，主要是查找需求分析过程中存在的缺陷、错误；3.1.2关于需求分析步骤01获取用户需求调查研究法。需求获取阶段，不同的系统开发方法，采取不同的方式。02提炼用户需求分析建模法。将用户提供的信息创建分析模型。包含数据流图、E-R图，状态转换图、控制流图等。04验证用户需求系统分析员与用户一起对需求分析说明书进行仔细、严格的验证、审查。03描述用户需求编写《用户需求规格说明书》。3.2.1常用方法对重要用户组织访谈访谈是最早使用且至今仍广泛适用的需求分析技术。客户访谈既能熟悉高层的战略需求，又可以听取普通用户的需求。客户访谈可以分为正式的与非正式的。采访用户：采用情景分析法；调查大量人员的意见：发放调查表。组建软件联合分析小组由用户、系统分析人员、领域内专家一起组建的软件联合分析小组。这样对软件分析员、用户之间的交流以及需求获取非常有用。3.2.1常用方法相关问题的分析、确认

使用传统的需求获取方法获取用户的需求时，容易让用户产生被动的感觉。采用面向团队的需求获取方法，简易的应用规格说明技术。

开发者与用户

一起标识问题，

共同提出解决方案，讨论不同方案以及共同指定基本需求。

优点：用户与开发者齐心协力、不分彼此、密切配合，

一起完成需求获取工作。

用户很难在一两次的交谈中阐述清楚需求，需要进行多次访问，访问后，

须及时整理并分析用户提供的信息，

排除无关信息以及错误信息，整理有价值内容，便于与用户下一次见面交流时，

由用户确认，

并筹备下次访问用户时，

进一步理清细节。3.2.1常用方法——合作开展需求分析？初步交流，筹备会议①通过一两次的交流，初步明确待解决的问题范围以及解决方案；②用户、开发者分别写出“软件需求”，选定商谈会议时间、地点，指定协调人。严格审查各自需求，确定需求列表在会前几天，每位与会者须仔细审查软件需求，并且详细列出功能列表、约束条件列表和性能列表。经过上会讨论，创建组合列表双方与会者展示列表，经过大家讨论后，共同创建一份组合列表。由指定的协调人主持并讨论这些列表。根据实际情况进行分组，制定更细的规格说明根据需要，将与会者划分成更小的小组，每个小组都要将其制定的小型规格说明向与会者展示，并且供大家讨论。完善并确认标准，草拟需求规格说明报告全体与会者制定软件的确认标准，并提交讨论，拟写完整的《软件需求规格说明书》。3.2.2快速建立软件原型模型来获取需求

在软件开发中，快速原型法是常用的一种用户需求获取方法。快速原型法的基本思路：

在很短时间内建立一个包含基本数据库和基础功能的软件提供用户试用，依据用户意见对原型实施修改，直到用户满意。是否采用快速原型法，采用以下6个问题判断：当前用户的需求已经建立，并且需求是稳定的吗？(×)项目研发人员与用户已理解目标软件的应用场景吗？(√)当前的问题是否可以被模型化？(√)是否用户可以明确系统的基本需求？(√)是否存在模糊的需求？(√)已知的需求中存在矛盾吗？(√)需求分析的常用方法

系统分析员获取用户需求停留在文字、图表阶段，

需用专业方法分析理清楚用户的实际需求转变成逻辑模型。

方法1—功能分解法：将一个软件看作由若干个功能组成的集合，且每个功能又可进一步划分成若干子功能，并且一个子功能又可以继续分解为若干子功能。因此，这种方法最终产生主功能、子功能与功能接口，该方法是最早应用于需求分析的方法。该方法将系统需求当作一棵倒过来的功能树，

其中每个节点代表一个具体的功能，因此，树根是总功能，

而树枝是子功能，最终树叶为子功能的子功能。功能分解法依据“自顶向下、逐步求精”的方式，这也符合传统程序设计人员的思维特征，不过，这种方法很难与系统设计分开，所以，较难适应需求的变化。

方法2—结构化分析方法：普遍采用的一种结构化分析方法，是从问题空间到具体映射方法，软件的功能是由数据流图表示，即由数据流图与数据字典共同组成的逻辑模型。此方法使用起来简单，更适用于数据的处理领域。具体内容将在3.4节中介绍。

方法3—信息建模方法：此方法的基本表达工具是E-R图，由实体、属性与联系组成。此方法从需求资料中找到实体，再用属性描述实体。ER图是面向对象分析技术的基础，不过它的数据是不封闭的无继承机制，也没有消息传递机制的支持。

方法4—面向对象的方法：将E-R图与面向对象的程序设计语言相关概念结合后构成一种新的分析方法。面向对象

分析技术的关键是识别、定义类、对象，并分析出它们的关系，

依据问题域的操作规则及内存性质而建立的模型。（软件项目、毕业设计常用）3.4结构化分析的方法介绍

结构化开发方法是软件研发方法中应用最广泛、最成熟的一种方法。其特点是自然、快速。该方法的思想是“自顶向下、逐步求精”（如图3.1所示），它的基本原则分为两步：

抽象与分解。

（1）分解。面对较复杂的问题，通常将其分解成若干个相对容易的小问题，然后再进

一步解决。

一般情况，

可以忽略细节，

即先考虑问题的本质，

构成问题的高层次概念；

然后再逐步添加细节。

（2）抽象。在分析问题时，事先考虑问题最重要的属性，暂时忽略细节，再逐层增加细节，直到实现全部内容。

对于复杂的软件系统，系统分析工作都可以依据上面的策略进行有计划和按步骤推进。3.4.2面向结构化分析的建模工具

数据流图：

一种图形化的系统模型。运用图形方式描述系统内部的数据流，表达系统的各处理环节之间的数据联系，是结构化系统分析方法的表达工具。

数据字典：对数据流图中的元素进行定义的集合。比如，可以定义数据流图中的“加工”和“数据”。

结构化语言：是一种介于形式语言与自然语言的半形式化语言。结构化语言具有三种形式，分别是顺序结构、循环结构、选择结构。

判定树：又称为决策树，它的思路和结构化语言几乎完全类似，主要用它描述某个功能模块的逻辑处理过程。

判定表即决策表，相对于决策树而言，其优点是可以把所有条件组合完全表达出来。不过，缺点也非常明显，即判定表的创建过程非常复杂，并且表达方式不容易理解。3.4.3数据流图数据流图（DataFlowDiagram，DFD）是一种图形化技术，用于表示系统逻辑模型，它以直观的图形清晰地描述了系统数据的流向与处理的过程。数据流图只能描述部分主要数据在系统中流动与被处理的过程，

哪怕非计算机工作者也很容易理解，

所以，

数据流图是系统

分析员和用户之间非常好的交流工具。画数据流图时，

一般只需考虑软件的逻辑流程，无需考虑如何实现功能。所以，数据流图也是软件设计工作的基础。数据流图是从软件项目中提取四种组成元素的结果，分别是数据源点与终点、处理或加工、数据的存储及数据的流向：（1）数据的源点与终点：通常指的是软件外部的实体，是帮助理解软件接口引入的。

可以是其它的软件、人及物等，

而这些信息在数据流图中无需作进一步说明。通常来讲，

只需要出现在数据流图的顶层图中。（2）处理与加工：即对数据进行加工的单元，并对数据流实施变换，描述要执行的功

能。对于每个加工处理过程都是要求有名字的，

一般是动词短语。通常的做法，

为了便于管理和识别，需要对加工步骤进行编号。（3）数据的存储：

依据“加工”与“数据存储”间的箭头方向，

可以将其分为读数据、写入数据以及既要读数据又要写数据3种情况。（4）数据流：数据在系统内的运动方向。对于每个数据流都必须起一个合适的名字，

然而，

通常对从数据存储流出或者流向数据存储的数据流不需要起名字，

只需要对数据存储起个合适的名字即可。3.4.3数据流图2.原则（1）在数据流图中的符号必须是前面的基本符号和附加符号（2）

顶层图即主图，

须涵盖基本元素中的全部符号（四种），因此，

不能缺少任意一种元素（3）数据流图顶层图上的数据流须封闭在外部实体之间（4）变换处理（加工）至少需要有1个输入数据流与1个输出数据流，才能得到加工的数据来源、加工结果（5）

任意子图须与其上一级父图的某个“加工”对应，

即父图中有多少个“加工”，就可能有几张子图，两者的输入数据流和输出数据流必须一致，这样才达到平衡（6）

一般采用“自顶向下逐层分解”的方法：①不要一下子引入过多细节，应该逐步

增加细节。

一张数据流图包含的处理不能太多,一般不多于5-9（7+2个），

否则难以理解。

需进一步分层。

②分层的DFD图,一般分为顶层、中间层、底层。层次的编号按照顶层、

一层、二层……次序编排的。其中，顶层图和一层图只有一张。3.4.3数据流图3.画数据流图的典型步骤画数据流图的步骤①先找到外部的实体（比如人、物或者其它系统），当找到外部实体后，软件的源点与终点便找到了。②找出与外部实体之间的输入、输出数据流。③在数据流图的边沿处画出软件的外部实体。④从外部实体的源点出发，

依据软件的逻辑需要，

逐渐画出变换数据的加工，直到找到外部实体需要的终点，构成数据流的闭环。⑤按照上述的原则展开检查与修改。⑥按照上述的步骤描绘出所有的子图。3.4.3数据流图4.注意事项（1）当设计数据流图的时候，

一般不考虑数据流的动态关系，而只考虑其静态关系。（2）画数据流图时，只考虑常规状态，不考虑异常状态。（3）

注意数据流图和程序流程图的区别。数据流图不描述做的顺序与“怎么做”，只描述“做什么”。（4）数据流图需要经过多次反复修改才能完成，因此，不要期望一次画成。（5）复杂软件的数据流图都很大，很难用几张纸描绘清楚，

一般采用的方法是分层进行描述这个系统。在进行分层描绘时，必须坚持信息的连贯性，即每次只细画一个加工。3.4.4数据流图实例

某高校“高校实习信息服务平台”分为四个子系统，其用户分为3类：企业的管理员、学校管理员、大学生。该系统分为四个模块。

注册/登录模块

①

用户：企业管理员、学校管理员、大学生

②

功能：注册、登录与验证

招聘模块

①

用户：实践企业

②

功能：企业发布岗位信息、查询学生应聘信息、发面试通知。

应聘管理模块

①用户：大学生

②功能：

使用手机、PAD等移动设备查询企业招聘信息，

发送应聘简历、查询面试通知。

系统管理模块

①

用户：学校管理员

②

功能：对实习企业进行审核、对招聘信息进行统计。

上述系统的数据流图采用“自上而下，

由外到内”的原则，

按照三个层次进行梳理，

其主要的数据流图如图3.2、图3.3、图3.4所示。

（1）首先画顶层数据流图。将该系统看作一个整体，通过查看系统与外部的联系，着

重分析从外部获取的信息就是系统输入信息；若是系统向外部输出的数据就是系统输出信息

（2）画出系统内部的一层数据流图。数据流图主要描述内部处理流程，图3.3是一层数据流图。

（3）画出系统的二层数据流图，如图3.4所示。3.4.4数据流图实例

3.4.4数据流图实例

3.4.5数据字典

针对数据流图中的元素，

需要专门工具解释，

即数据字典。在软件分析与设计中用于给研发人员提供数据描述。数据流图与数据字典的关系密切，

没有数据字典，

人们就看不懂数据流图，

没有数据流图，而数据字典也失去了存在的价值。它们一起构成了软件的逻辑模型内容。数据字典是供软件研发工程师查找数据流图中相关数据项的说明。应该将条目按照规则排列以供查阅。通常，数据字典由四类元素构成：（1）数据流（信息流）；（2）数据流分量；（3）数据存储（文件）；（4）加工（处理）

其中，数据流分量是组成数据流和数据存储的最小单位项；

源点和终点是为了帮助理解系统和外界接口而列入的，不在系统之内，故一般不在字典中说明。对于数据处理的定义，使用PDL或者IPO图描述会更加方便定义数据的方法。3.4.5数据字典3.实例（1）数据流条目：对数据流图中的数据流进行定义，

主要包括：

数据流的名称、简述、数据流的来源、去向、数据的流通量、数据流的构成。例3-1章节3.4.4中“招聘信息”条目数据流的名称：岗位信息简介：公司发布岗位信息来源：获得许可的公司流向：加工处理2“招聘管理”数据量：1000份/month构成：公司编码+公司名称+公司岗位+实习人数+职位条件+实习工资3.4.5数据字典3.实例（2）文件条目：即给定某个文件的定义，

通常列出由文件记录构成的数据流，

还可以指明文件的组织方式例3-23.4.4中企业注册文件数据文件的名称：公司信息表简介：存储公司基本信息构成：公司编号＋名称+性质＋注册资金＋人数＋地址＋企业代表＋主营范围存储方法：顺序方式存储组织方法：以“公司编号”作为关键码频率：5000次/day3.4.5数据字典3.实例（3）数据项条目：提供某数据项的解释，一般是该数据项取值范围、值类型等。

例3-3企业性质的数据项

数据项的名称：企业的性质

简介：略

类型：字符串

取值长度：30

值域:[国有企业|有限责任公司|中外合资企业|外商独资企业|集体企业|个体企业]（4）加工条目

其是对数据流图的补充，事实上是“加工处理的额外说明”。因为“加工处理”是数据

流图非常重要的组成部分，

通常需要单独说明。所以，

数据字典是对数据流图包含的各种元

素，

包括数据项、特征、结构、加工、流向等)的集合。对4类条目描述：

数据流、数据项、文件及基本加工进行描述。3.4.6处理过程描绘

通过数据流图对用户需求进行描述，然而一些详尽的信息无法在DFD中表示，比如业务的详细流程、数据项及相关的数据结构。常用来描述处理过程的方法是：结构化语言、判定树和判定表。1.结构化语言：它是一种半形式化语言，

介于自然语言与形式语言之间。它既具有清晰易读的特点，又具有简单易懂的优势。结构化语言有以下3种形式

（1）顺序结构。一般由一组选择语句、祈使语句及重复语句按照一定规则组成。

（2）选择结构。常用IF-THEN(-ELASE)-ENDIF或CASE-ENDCASE等关键词构成的语句结构

（3）循环结构。常用DO-WHILE-ENDDO或者REPEAT-UNTIL等词例3-4假设某数据流图中有“职工二次分配”的加工（处理），指的是根据企业实际情

况，

对职工的工作进行再分配。规则如下：

按照职工的年龄、性别及学历等情况，

安排不一

样的工作。若年龄小于（含）25岁，初中学历，

将实施脱产学习，

而高中学历安排当普工；

年龄大于25小于等于40岁的，

学历是中学的男性安排当钳工，

若是女性安排做车工，

如果

是大学学历做技术员；

对于年龄大于40小于等于50岁的员工，

初中学历的安排到一线当安检员，大学学历的当技术员。采用结构化语言编写上述规则，描述如下3.4.6处理过程描绘2.判定树判定树又称为决策树。使用判定树描述数据处理过程，类似于结构化语言，不过，判定树更直观，主要用来描述一般组合条件，缺点是不易输入计算机下面以一个实例，说明判定树的组织方式。见图3.5所示：例3-5画出此项处理的判定树某学校的特招笔试考核计算机、英语与数学，

其复试及录取规则约定如下：

①总分大于

等于240时录取。②总分大于等于180

分且小于240分时，若数学、英语成绩均在60分以

上（含），需要参加面试；

如果数学或英语中有1门成绩在60分以下（不含）

的，

需复试该课程后再决定是否录取。③其他情况不录取。3.4.6处理过程描绘

判定表：使用if-then-else就比较困难，即便是可以使用，但对问题的描述不够清晰。对于此类问题，则可以采用另一种描述工具——判定表。判定表采用表格化的形式，应用于含有复杂判断的加工逻辑。条件越复杂规则越多，越适宜用这种表格化的方式描述。判定表由四部分组成判定表也称为决策表，与结构化语言和判定树方法相比，其优点是能够清晰地表示复杂

的条件组合与应做的动作之间的对应关系。缺点是判定表的建立过程较为繁杂，且表达方式不如前两者简便。判定表主要由4个部分构成：

①在左上方列出全部条件

②在左下方是全部可能做的动作

③右上方是把各种条件组合起来的矩阵

④右下方是与每种条件进行组合后对应的动作

判定表的右半部分的每一列，事实上是一条规则，明确了与特定的条件组合相对应的动作以下以行李空运为例说明判定表的使用方法：例3-6某航空公司运价表显示：当行李重量不大于20kg时，免费托运；当行李重量大于20kg时，对乘坐头等舱的乘客超重部分收费4元/千克，对乘坐经济舱的国内乘客超重部分收费6元/千克，对乘坐飞机的外国乘客，每千克收费比国内乘客高一倍，对残疾乘客而言，超重部分收费比普通乘客每千克少一半。用判定表对航空公司运费核算过程进行分析见表3-4所示：

123456789乘客（国内）

TTTTFFFF头等舱乘客

TFTFTFTF乘客（残疾）

FFTTFFTT行李≤20kgTFFFFFFFF免费×

(W-20)×2

×

(W-20)×3

×

(W-20)×4

×

×

(W-20)×6

×

×(W-20)×8

×

(W-20)×12

×

3.4.7状态转换图

在需求分析时，除了建立软件的数据模型与功能模型，还需要建立软件的行为模型，比如，在不同状态下，数据对象会出现各种不同的操作，因此，应分析数据对象的状态，画出状态转换图，便于正确识别数据的状态。该图形工具通过描绘软件系统的状态以及导致系统状态转变的事件，以表示系统当前的行为。图中的状态主要有：初始态、终止态和中间态。在一个图中，只有一个初态，而终止状态有0至多个。①初始态：系统启动时进入的状态；②终止态：运行结束到达的状态；③状态迁移：

从一个状态到另一状态转变。一般用箭头来表示从某一种状态向另一状态转变；④事件：某时刻出现的事情，即从某个状态转变到另一状态的外部事件的抽象。

例3-7

在生活中，经常使用打印机，其工作过程大致如下：

一开始处于Ready状态。复印机工作流程解析：当接到复印命令则进入复印状态，

完成一个复印命令规定的工作后，

又回到Ready状态，

等

待下一个命令；如果执行复印命令时发现缺纸，则进入缺纸状态，并发出警告，等待装纸，

装满纸后继续复议未完成的工作；

若复印时卡纸，

立即停止复印，

并发出警告，

当排除故障后，返回到Ready状态。用状态转换图描述打印机的活动。见图3.6所示：其它工具

文字描述不直观，容易产生二义性。因此，在需求分析文档中常用图形工具代替部分文

字叙述。前面章节已介绍了数据流图、状态图，本节将简单介绍经常用到的其它三种工具，分别是层次方框图、维纳图和IPO图。3.5.1层次方框图

在需求分析阶段，常用层次方框图描述数据的层次结构，用多层矩形框描绘数据信息的层次结构。该图的最上层是一个单独的矩形框，用来表示数据结构的最上层；下面每一层矩形框表示数据子集；最下层的矩形框表示不可再分割的数据元素。由于软件架构的细化，采用层次方框图描述数据结构时需要更详细的信息。该工具比较适合需求分析阶段的需要。系统分析员从最上层开始，顺着每条路径逐步细化，直到数据结构的全部细节确定为止。正如下面的例子，某公司主营以下产品和服务，现尝试构建一个基本的层次方框图，如图3.7所示：3.5.2维纳图（Warnier）Warnier图是由J.D.Warnier提出，用来表示数据层次的一种图形工具。该工具比层次图提供更丰富的描绘手段。在Warnier图中使用以下几种符号：

①大括号{}:用来区分信息的层次；

②异或符号⊕：

指出一个信息类或一个数据元素在一定条件下出现，符号上、下方的名。③圆括号（）：指出这类数据重复出现的次数。例

3-8

设某高校有

10

个学院，学院下设

15

个系，30

个科室，6

个实验中心，每个系

分若干个专业，各个系的专业个数并不相同；校一级机关具有

2

个室、4

个部、5

个处，每个处分别设有若干个科室和中心，如图

3.8

所示。3.5.3IPO图

在需求分析阶段，我们需要对数据的输入、处理、输出过程建模，常用的建模工具是IPO图。IPO图由IBM公司发起并逐步完善的一种图形工具，用来描述数据的输入、处理、

输出过程，其基本形式是3个矩形框，在最左边的矩形中列出需要向软件系统输入的数据，

在中间的矩形框中填入需要对前面的信息做哪些处理，在最右面的矩形中列出产生的结果。在图中需要用粗大箭头指出数据流动的方向。

在需求分析阶段，

软件研发团队总体上理解了用户的具体需求，

核实并汇总软件的功能记录软件所需要的数据来源，

描述处理相关数据的方式。最终，

把这些材料进行整理，

形成《软件需求规格说明书》。例3-9

图3.9所示为某省公务员考试成绩管理系统的IPO图，通过这个简单的例子可以了解IPO图的用法：作业安排第4章

概要设计概要设计01概要设计新课导入

前一阶段的工作中，

已经清楚必须“做什么”了，接下来进入软件的概要设计阶段，即将“做什么”转变成“怎样做”。同时，可以把软件设计阶段的成果写到《软件设计规格说

明书》。概要设计是软件设计阶段的第一步骤，所以，仅描绘软件的整体结构，而在详细设计阶段，才是对软件结构进一步的细化。4.1概要设计阶段的目标与任务

概要设计阶段的目标是整体上软件如何实现？即明确软件是由哪些模块构成，理清每个模块的功能、模块之间的调用关系以及通信接口等软件设计之数据流图基础在进行软件的结构设计时，主要以数据流图作为主要依据进行设计。因此，数据流图是

软件设计人员进行方案设计的基础。

第一，软件分析人员可以在可选择的方案中选择多个可

实现的方案；

第二，

通过比较分析这些方案；

第三，

从这些方案中推荐最佳方案给用户负责人。

用户中的技术专家需要认真审查推荐的最佳方案，

若该方案确实完全符合需要，

而且在目前的条件下完全可以实现，那么，下一步提交使用部门（业务部门）负责人审查。若使用

部门（业务部门）

负责人同意该方案，接下来进入软件的结构设计阶段。需要将较复杂的软

件实施功能分解，即将部分复杂的功能适当分解成较简单的功能，

进而对软件的结构进行设计。4.1概要设计阶段的目标与任务

为了明确软件的结构，第一步，从实现的角度将软件较复杂的功能实施进一步分解。软

件分析人员将结合算法的描述分析数据流图中的每一个处理过程，若一个处理过程过于复杂，须将其进行适当分解，直到分解为若干较简单的功能为止。一般情况，

软件的一个模块

需要实现一个子功能。所以，将软件的模块应该具有较清晰的层次结构，

且顶层的模块通过

调用其下一层的模块，

从而实现软件的完整功能，并且下层模块将继续调用下一层模块，

实现软件的一个子功能，所以，在最下面的模块将实现具体功能。

一般而言，软件都需要与数据库交互，

因此，

对于该类软件，软件研发人员在需求分析

阶段就需要明确软件的数据需求，继而进一步设计数据库。最终通过制定软件的测试计划书写《软件概要设计规格说明书》并组织相关人员进行复审。4.2.1软件结构设计的准则

经过长期积累，在软件开发过程中人们总结了大量的经验，即得到了下面关于软件设计方面的准则：

关于软件结构设计的准则如下：

（1）软件的体系结构是对复杂软件的抽象。较好的软件结构可有效地处理多种个体需求。

（2）在一定时间内，软件的体系结构需要保持稳定。从而有效地确保软件接口的一致性。

（3）软件体系结构的好坏决定了未来软件是否高效、稳定、可靠。4.2.2模块设计的准则

当软件结构初步设计方案完成后，

为了实现模块的独立性，

须对软件结构进行审查与分

析，

经过一系列分解、合并模块操作，

以降低耦合度，

从而起到提高模块内聚性的要求。比

如，

若干模块共享某个子功能，

此时，

建议分解出来一个公共子模块，

来定义一个内聚度更

高的模块，

便于其它模块调用；

有时候，

可以将耦合度较高的模块施行合并，

从而降低模块接口的复杂度，正如图4.1所示。1.提高软件模块的内聚性，同时降低软件模块间的耦合性4.2.2模块设计的准则

2.软件应该保持合理的深度、宽度以及扇入与扇出

软件深度是指软件结构中模块层次的数量，

其在一定意义上讲，

可以反映软件的规模与复杂度。若软件的深度过大，则表明软件的层数太多，须审查某些模块是否可以合并软件的宽度是指在同一层次中存在的最大的模块数。通常来说，

宽度越大的系统，

软件的结构也越复杂。模块的扇出是影响软件宽度的最大因素。软件扇出是指某个模块可以直接调用的模块数量。一般而言，

一个较好的软件结构，

其

平均扇出数不会大于9。因为扇出太大表明模块过多，此时可适当提高中间层次的模块数；

若扇出过小也不行。如果扇出太小，

可将下级模块进行分解成若干子模块，

或者将其合并到上级模块。软件扇入是指某个模块被若干上级模块调用的数目。若某个模块的扇入过大，表明共享

该模块的上层模块数量越多，

这种情况是比较认可的。不过，

一般不要违背软件模块的独立性原理，过分追求高扇入。通常来讲，

一个较好的软件结构，

一般是第一层扇出要高，

中间的层次扇出少，

下面