软件工程重点（5篇）

第一篇：软件工程重点

软件是计算机系统中与硬件相互依存的另一部分，它是包括程序，数据及其相关文档的完整集合。注意与广义软件概念的区别（P1）。程序是按事先设计的功能和性能要求执行的指令序列数据是使程序能正常操纵信息的数据结构 文档是与程序开发，维护和使用有关的图文材料

软 件的特点.软件是一种逻辑实体，而不是具体的物理实体。因而它具有抽象性 软件的生产与硬件不同，在它的开发过程中没有明显的制造过程，可以复制，软件的开发和运行常受到计算机系统的限制，对计算机系统有着不同程度的依赖性 软件的开发至今尚未完全摆脱手工艺的开发方式 本身复杂 且 成本昂贵。

软件功能分：系统，支撑，应用软件。

软件生存期的六个步骤，即制定计划（确定要开发软件系统的总目标，给出功能、性能、可靠性以及接口等方面的要求，完成该软件任务的可行性研究，制定出完成开发任务的实施计划）、需求分析（对待开发软件提出的需求进行分析并给出详细 的定义）、设计（把各项需求转换成软件的体系结构，对每个模块要完成的工作进行具体的描述，为源程序编写打下基础）、程序编码（把软件设计转换成计算机可 以接受的程序代码）、测试（通过单元模块测试和组装测试，对各项需求进行有效性测试）及运行维护（改正性维护 适应性维护 完善性维护）

软件：程序和所有使程序正确运行所需要的相关文档和配置信息。

软件工程：是一门工程学科，不仅涉及软件开发，也涉及软件项目管理、支持软件生产的工具、方法和理论的开发等活动。

软件过程：指制作软件产品的一组活动及其结果。包括软件描述（对软件及其操作的一些约束）软件开发（软件设计和编程实现）软件有效性验证（检查保证客户所需）软件进化（随不同客户和变化市场做修改）

软件过程模型:从一特定角度提出的软件过程的简化描述。1工作流模型（描述软件过程中各种活动的序列及其输入输出和相互依赖性）2数据流或活动模型（软件过程描述成一组活动，每个活动完成一定数据转换）3角色/动作模型（描述参与人员的不同角色和各自负责的活动）

CASE是计算机辅助软件工程的简写。它包括很多种类的软件工具，覆盖面很广，包括支持阮娟过程活动，如需求分析、系统建模、调试和测试等。瀑布模型：采用一些基本过程活动，并且使用单独的过程阶段表现活动。包括：需求分析和定义（通过咨询系统用户建立系统的服务、约束和目标）系统和软件设计（系统设计区分硬件和软件系统的需求，软件设计包括识别和描述一些基本的软件系统的抽象及其之间的关系）实现和单元测试（检验每个单元是否符合描述）集成 和系统测试（对系统整体测试确保满足需求）运行和维护。优势在于每个阶段生成文档，并且与其他模型相一致，问题在于将项目生硬分解成这些确切的阶段。委托 事项一定要在过程的早期阶段清晰给出，意味它难以响应用户需求的变更。

2迭代式模型：是软件描述、开发和有效性验证活动交替进行的开发方 法。先开发出一个原型给用户使用，通过用户反馈意见不断修改系统直到最后成熟。基本类型（探索式开发和抛弃式原型）优势在于让开发活动都能得到快速的反馈 信息，缺点在于1过程不可见（管理者要经常性交付把握进度）2系统结构通常较差（连续的变更损坏系统结构）

3基于组件的软件工程（CBSE）假定系统的各个组件已经存在，开发过程焦点在于集成这些组件。阶段：组件分析（给出需求描述，然后搜索能满足需求的组件）需求修改（修改需求以反映可得 到的组件）使用复用的系统设计（开始设计系统的框架）开发和集成（集成开发的组件和现成的组件使之成为整体）优势在于减少需要开发的软件数量，降低软件开 发成本和风险。缺点在于需求妥协的不可避免，对系统进化的控制不起作用。

Rational统一过程：是一个阶段化了的模型，识别出软件过程 当中的四个阶段——开端（目标是建立系统的一个业务案例）细化（增进对问题域的理解，建立系统的体系框架）构造（关心系统设计、编程和测试）转换（关注如 何将系统从开发单位转移到用户单位使之在真实环境工作）九个工作流——业务建模（用业务用例对业务过程建模）需求（完成对系统需求的建模）分析和设计（使用体系结构模型、组件模型、对象模型和序列模型来创建并记录设计模型）实现（实现系统中的组件并将他们合理安排在子系统中）测试（它的执行与实现紧密 联系）部署（创建和分发产品版本并安装到他们的工作场所）配置和变更管理（支持工作流管理对系统的变更）项目管理（支持工作流管理系统开发）环境（用于提 供软件开发团队可用的合适软件工具）六个基本实践（反复的开发软件、管理需求、使用基于组件的体系结构、可视化模型软件、验证软件质量、控制对软件的变 更）

软件系统需求常常分为功能需求、非功能需求和领域需求。1功能需求——包括对系统应该提供的服务、如 何对输入作出反应以及系统在特定条件下的行为的描述。应该即、既全面（用户所需服务都给出描述）又具有一致性（描述不能前后矛盾）2非功能需求——对系统 提供的服务或功能给出的约束。分类：产品需求（叙述产品行为的需求，包括可移植性和可用性需求）机构需求（起源于客户所在的机构和开发者所在的机构中的政 策和规定）外部需求（包括所有系统外部因素和开发过程，如操作、法律、道德需求）3领域需求——来自系统的应用领域的需求，反映该领域的特点。

用 户需求是从用户角度来描述系统功能和非功能需求，以便让不具备专业技术知识的用户能看懂。编写用户需求的一些原则：1设计一个标准的格式，保证所有的需求 定义按照该格式书写。2使用一致的语言。定义强制性需求要使用“必须”；定义希望性需求时使用“应该”。3对文本加亮来突出显示关键性需求。4尽量避免用 计算机专业术语。

系统需求：是用户需求的扩展版，是软件工程师开始系统设计的起点。仅仅描述系统的外部行为和对它的操作上的限制，而不包括系统应该如何设计和实现。

信息持有者（对系统需求有直接或间接影响力的人）

需 求导入和分析：软件开发技术人员要和客户及系统最终用户一起调查应用领域。包括：需求发现（收集准备建立的系统和正在使用的系统的信息，并从这些信息当中 提取用户和系统的需求）需求分类和组织、优先排序和冲突解决、需求文档编制（记录需求并将它作为螺旋下一循环的输入，产生形式化的或非形式化的需求文档）

视点：需求工程的面向视点的方法将导出过程和需求本身都用视点来组织。1交互者视点（代表与系统直接交互的人或其他系统）2间接视点（代表那些不使用系统本身但是以某种方式影响需求的信息持有者）3领域视点（代表领域和影响系统需求的那些约束）

场景：描述人如何与一个软件系统交互。

用例：是一种基于场景的需求导出技术，识别与系统的单个交互。

需求管理是一个对系统需求变更了解和控制的过程，需要跟踪各个需求并维护他们与所依赖需求之间的关联关系。分持久和易变的需求。

在 需求管理阶段，必须决定一下内容——需求识别、需求管理过程、可追溯策略、CASE工具支持。3类可追溯信息：1源可追溯性信息连接需求到提出需求的信息 持有者和这些需求的基本原理2需求可追溯性信息连接需求文档中 依赖的需求3设计可追溯性信息连接需求到其实现的设计模块。需求变更管理三个阶段：1问题分析和变更描述阶段（要对问题或变更提议进行分析以检查它的有效 性）2变更分析和成本计算（对被提议的变更产生的影响进行评估并且估计系统设计和实现的成本）3变更实现。体系结构设计是设法建立一个系统组成来满足功能性和非功能性需求。所 开发的体系结构模型会包括：静态结构模型（给出子系统或组件，将其作为一个个独立的单元开发）动态过程模型（给出系统在运行时的过程组成）接口模型（定义 每个子系统从它们的公共接口能得到服务）关系模型（给出如子系统间的数据流这样的关系）分布模型（给出子系统在多台计算机上是如何分布的）模 块化分解：将子系统分解为模块，有两种策略：1 面向对象的分解（将系统分解为一组相互通信的对象）一个面向对象的系统体系结构模型是将系统看成一组松散的对象结合，这些对象都有良好的接口定义，对象请 求其他对象提供的服务。优势在于其对象间是松散耦合的，对对象实现的修改可以不影响其他对象，缺点在于对象必须明确地给出引用的其他对象的名字及其接口。2 面向功能的流水线操作（将系统分解为一些功能模块，这些功能模块接受输入并转换它们为输出数据）好处在于1支持换换的复用2直观，能将它们的工作理解成输 入输出处理3可以简单的再系统中增加新的转换4无论作为顺序的还是并发的系统，其实现容易。其主要缺点是需要一种适合于所有转换的通用格式。

数据处理系统是批处理系统，数据的输入和输出时成批地从文件或数据库中取出或存入，而不是对用户终端进行输入和输出。形成输入—处理—输出结构。事务处理系统是设计用来处理用户对数据库信息的查询或者请求更新数据库的。

快速软件开发的原因：新的软件需要快速开发来顺应新的的机遇，响应竞争压力。事实上很多业务都宁愿牺牲一些软件的质量并降低某些需求来赢得快速软件移交。还因为业务运营于一个变化的环境中，因此实际上通常不可能导出一个完全的稳定的软件需求。

基本特征：1描述、设计和实现过程是并发的2系统通过一系列增量开发出来3系统用户界面通常是采用交互式开发系统开发的。

敏 捷方法的基本原则：客户参与（客户应该在开发过程中始终紧密参与其中）增量式移交（软件以增量的方式进行开发，客户指定每个增量中的包含需求）人非过程（开发团队的技术应该得到承认和发扬）接收变更（设计系统使之适应这些变更）保持简单性（致力于所开发的软件和开发过程的简单性）

极限编程 的经验：增量式规划（需求记录在脚本上，开发者将脚本分解为开发任务）小版本（首先开发能提供业务价值的一个最小有用集合）简单设计（只进行有限需求设 计）测试优先开发（功能实现之前，采用一个自动单元测试框架来书写此新功能的测试）重构（保持代码简单和可维护性）结对编程（检查彼此工作提供支持）集体 所有（配对的开发人员参与系统的所有方面，所有开发者享有全部代码）连续集成（任务一完成，就将它集成到大系统中）可忍受速度（不能接受大量超时）在场客 户（系统最终用户的代表应该全程满时配合XP团队）

检验和有效性验证：实现过程之后，必须对所开发的程序进行验证，它是对 这些检查和分析过程的总称。检验的作用是检查软件是否符合它的描述。应该检查系统是否满足了需求所定义的功能的和非功能的需求。有效性验证却是一个更一般的过程，其目标是保证软件系 统能满足客户的期待。

V&V过程中，系统检查和分析有两种互补的方法：1软件审查或配对审查——审查可以辅之以某些对系统源文本或 者是相关文档的自动分析，是一种静态的V&V技术，因为你无需再计算机上运行系统。2包括使用测试数据来运行软件的实现，检验软件的输出和它的操 作行为，测试是一种动态的V&V技术。在软件过程的不同阶段，有2中截然不同的测试类型：1有效性测试——试图证明软件是用户所期望的即满足需求 2缺陷测试——试图使缺陷暴露出来，而不是要仿真它在实际中的使用。发现程序和描述的不一致。

检验和有效性验证过程试图确定软件系统中存在缺陷，程序调试时一个对缺陷定位和修正的过程。

软件测试的目标：1向开发者和用户展示软件满足它的需求。2为了找出软件中的缺陷和不足，即软件的活动室不正确的、所不希望的或不符合它的描述的。测试过程：组件测试（单个程序组件的测试）—系统测试（对一组组件集成的系统进行测试）

系统测试：两个阶段1集成测试（测试小组可以深入到系统源代码）自上而下集成：首先开发系统的框架，然后将组件加入到框架中。自下而上集成：集成基础设施组件，然后添加功能组件.2发布测试（对要发布给用户的系统版本进行测试）测试原则：是给测试团队提示，以帮助他们选择将揭示系统中的缺陷测试。接口测试：目标是为了检测由于接口的错误或无效的接口假设所造成的故障.接口类型1参数接口（数据从一个过程传到另外一个过程）.2共享内存接口（内存块为过程或函数所共享.）3程序接口（子系统封装一组程序，这些程序为其他子系统调用.）4消息传递接口（子系统通过传递消息请求其他子系统上的服务）划分测试：由于类中成员的这些等价行为，这些类通常叫做等价划分或者域.结构化测试（白盒测试）：根据软件的结构知识和实现知识导出测试的测试用例设计方法。路径测试：目标是要练习组件或程序中的每一条执行路径。

要 点：测试只能证明系统中存在错误，它不能说明系统中不再有缺陷.；组件测试是组件开发者的责任，独立的测试团队通常执行系统测试.；集成测试是最初的系统 测试活动，发布测试关心的是测试客户版本，应该验证所要发布的系统满足了它的需求.；在缺陷测试时，应根据经验和准则来设计测试用例.；接口测试是要发现 组合组件的接口中的缺陷.；等价划分是导出测试用例的一个方法，需要找出输入和输出数据集合上的划分并用这些划分中的数据执行系统.；结构化分析依赖于分 析一个程序由此来确定路径.；测试自动化通过使用一系列软件工具支持测试过程，以减少测试过程的花费.什么是黑盒测试和白盒测试？ 任何工程产品（注意是任何工程产品）都可以使用以下两种方法之一进行测试。黑盒测试：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。白盒测试：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否以经过检查。软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需 求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。黑盒测试主要是为了发现以下几类错误：

1、是否有不正确或遗漏的功能？

2、在接口上，输入是否能正确的接受？能否输出正确的结果？

3、是否有数据结构错误或外部信息（例如数据文件）访问错误？

4、性能上是否能够满足要求？

5、是否有初始化或终止性错误？ 软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选 择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。白 盒测试主要是想对程序模块进行如下检查：

1、对程序模块的所有独立的执行路径至少测试一遍。

2、对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍。

3、在循环的边界和运行的界限内执行循环体。

4、测试内部数据结构的有效性，等等。以上事实说明，软件测试有一个致命的缺陷，即测试的不完全、不彻底性。由于任何程序只能进行少量（相对于穷举的巨大数量而言）的有限的测试，在未发现错误 时，不能说明程序中没有错误。

配置管理的重要性：涉及程序和标准的发展和应用来管理不断发展的软件产品；配置管理有时候被看做是软件质量管理过程的一部分；当进行配置管理时，受控系统有时也称为基线，因为它们是受控进化的一个起点.四种主要配置管理活动： 配置管理规划：描述配置管理应该使用的标准和规划。1配置项识别（应该定义文档命名规则，以便类型相同的文档命名也类似）2配置数据库（用于记录与配置有关的所有信息）

变更管理：需求不断发生变化，系统也相应作出变更。关注的是对变化保持跟踪，并确保它们用最具成本效益的方式实施.变更请求表（记录了变更的建议、变更的请求、变更的原因以及变更的迫切性.它还记录了变更评估、影响分析、变更成本和建议.）

版本和发布管理：是识别和追踪一个系统的各个版本和发布的过程。版本 一个系统版本就是一个系统实例，在某种程度上有别于其他系统实例.变体 有一些版本可能在功能上没有什么区别，只是为了不同的硬件或软件配置而设计.发布版本： 一个系统的发布版本就是要分发给客户的版本.版本管理规程应该规定明确的标识每个组件版本的方法.三种基本的版本标识方法 1版本编号;2基于属性的标识;3面向变更的标识.系统构建：把软件组件编译和连接成一个程序并在特定目标配置上运行的过程.CASE工具可用于支持所有的配置管理活动.支持配置管理的CASE工具可以是一些独立的工具分别用来支持变更管理、版本管理和系统构建，也可以是集成的系统，为所有的配置管理支持提供一个一致的接口.

第二篇：软件工程重点总结

1、什么是软件危机？

软件危机泛指在计算机软件的开发和维护过程中所遇到的一系列严重问题。

2、软件危机的主要表现

（1）对软件开发成本和进度的估计常常很不准确

（2）用户对“已完成的”软件系统不满意现象经常发生

（3）软件产品质量往往靠不住

（4）软件往往是不可维护的（5）软件通常没有适当的文档资料

（6）软件成本在计算机系统总成本中所占的比例逐年上升

（7）软件开发生产效率提高的速度，远远跟不上计算机应用迅速普及深入的趋势

3、软件危机产生的原因

(1)来自软件自身的特点

是软件系统的逻辑部件，缺乏可见性，管理和控制软件开发过程相当困难；规模庞大、复杂，修改、维护困难。

(2)软件开发与维护的方法不当

忽视需求分析；认为软件开发等于程序编写；轻视软件维护。

4、如何消除软件危机？

（1）对计算机软件有一个正确的认识(软件≠程序）

（2）必须充分认识到软件开发不是某种个体劳动的神秘技巧，而应该是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目

（3）推广使用在实践中总结出来的开发软件的成功技术和方法

（4）开发和使用更好的软件工具

5、面向对象的三种模型：对象模型 动态模型 功能模型 P2166、模块独立性的两个标准：耦合 内聚 P977、软件测试方法：黑盒测试 白盒测试 P1518、软件调试的途径：蛮干法 回溯法 原因排除法 P1789、可行性研究：确定问题是否有行得通的解决办法 P3510、需求分析：准确地回答“系统必须干什么”这个问题 P5511、软件成分的重用级别：代码重用 设计结果重用 分析结果重用

可被重用的软件成分有：项目计划，成本估计，体系结构，需求模型和规格说明，设计，源代码，用户文档和技术文档，用户界面，数据，测试用例。

12、软件可靠性的定义：软件在给定的时间间隔内，按照规格说明书的规定成功地运行的概率。

软件可用性的定义：程序在给定的时间点，按照规格说明书的规定，成功地运行的概率。可靠性与可用性之间的主要差别是，可靠性意味着在0到t这段时间内系统没有失效，而可用性只意味着在时刻t，系统是正常运行的。P17913、白盒测试：逻辑覆盖 控制结构测试 P162

黑盒测试：等价划分 边界值分析 调试 P171

环形复杂度的计算：复杂度=边数-点数+2P13714、面向对象的3个子模式：对象模型 动态模型 功能模型 P232

对象模型的5个层次：主题层 类与对象层 结构层 属性层 服务层 P23215、软件定义阶段干什么事：确定软件开发工程必须完成的总目标；确定工程的可行性；导

出实现工程目标应该采用的策略及系统必须完成的功能；估计完成该工程需要的资源和成本，并制定工程进度表。

16、类和对象的关系：类是具有相同数据和相同操作的一组相似对象的定义，也就是说，类

是对具有相同属性和行为的一个或多个对象的描述。类是支持继承的抽象数据类型，而对象就是类的实例。P21117、UML有哪些图？ P2171、用例图：展示系统外部的各类执行者与系统提供的各种用例之间的关系

2、类图：展示系统中类的静态结构

3、对象图：是类图的一种实例化图

4、状态图：描述一类对象具有的所有可能的状态及其转移关系

5、时序图：展示对象之间的一种动态协作关系

6、合作图：从另一个角度展示对象之间的动态协作关系

7、活动图：展示系统中各种活动的执行流程

8、构件图：展示程序代码的物理结构

9、配置图：展示软件在硬件环境中的配置关系

18、能力成熟度模型（CMM）：初始级 可重复级 已定义级 已管理级 优化级 P31119、什么是软件生命周期模型?试比较瀑布模型、快速原型模型、增量模型和螺旋模型的优

缺点，说明每种模型的适用范围。P33习题1.720、软件的可维护性定义：维护人员理解、改正、改动或改进这个软件的难易程度。决定可维护性的因素：可理解性 可测试性 可修改性 可移植性 可重用性。

文档是影响可维护性的决定性因素。P19521、如何评价软件规格说明书？

从四个方面：一致性 完整性 现实性 有效性 P7022、层次图 P10223、深度：软件结构中控制的层数 P100

宽度：软件结构中同一个层次上的总数的最大值

扇出：一个模块直接控制（调用）的模块数目

散入：一个模块被多少个上级模块直接调用

24、面向数据流的设计方法 P10425、类构件的重用方式：实例重用 继承重用 多态重用

1.什么是软件工程？软件工程和计算机科学有何区别？

软件工程是指导计算机软件开发和维护的一门工程学科。

计算机科学研究的是构成计算机和软件系统基础的有关理论和方法，而软件工程则是研究软件制作中的实际问题。

2、流程图与数据流图有什么主要区别？

（1）数据流图（date flow diagram , DFD），是SA方法中用于表示系统逻辑模型的一种工具，它以图形的方式描绘数据在系统中流动和处理的过程，由于它只反映系统必须完成的逻辑功能，所以它是一种功能模型，是从数据的角度来描述一个系统的；而流程图则是从对数据加工的角度来描述系统的；

（2）数据流图中的箭头是数据流，而流程图中的箭头则是控制流,它表达的是程序执行的次序；

（3）数据流图适合于宏观地分析一个组织业务概况,而程序流程图只适合于描述系统中某个加工的执行细节。

（4）数据流程图应该重点描述了数据加工的过程，主要是模块内部，数据流图则是描述模块之间的关系。

3．软件需求分析的任务是什么？有哪些主要步骤？

需求分析的基本任务是深入描述软件的功能和性能、确定软件设计的约束和软件同其它系统元素的接口细节、定义软件的其它有效性需求，总之，需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的 “做什么” 的问题。

主要步骤：

1.问题识别

(1)功能需求：明确所开发的软件必须具备什么样的功能。

(2)性能需求：明确待开发的软件的技术性能指标。

(3)环境需求：明确软件运行时所需要的软、硬件的要求。

(4)用户界面需求：明确人机交互方式、输入输出数据格式。

2.分析与综合，导出软件的逻辑模型

分析人员对获取的需求，进行一致性的分析检查，在分析、综合中逐步细化软件功能，划分成各个子功能。用图文结合的形式，建立起新系统的逻辑模型。

3.编写文档

(1)编写“需求规格说明书”，把双方共同的理解与分析结果用规范的方式描述出来，作为今后各项工作的基础。

(2)编写初步用户使用手册，着重反映被开发软件的用户功能界面和用户使用的具体要求，用户手册能强制分析人员从用户使用的观点考虑软件。

(3)编写确认测试计划，作为今后确认和验收的依据。

(4)修改完善软件开发计划。在需求分析阶段对待开发的系统有了更进一步的了解，所以能更准确地估计开发成本、进度及资源要求，因此对原计划要进行适当修正。

4．简述结构化分析、设计的要点：

结构化分析方法适合于数据处理类型软件的需求分析。

其要点是“自顶向下” 地开发系统,由整体到各组成部分,由表及里,由抽象到具体,逐步求精.(1)模块化

(2)由顶向下,逐步求精.(3)上层模块分解为下层模块,有三种不同的结构形式,即顺序结构,选择结构和循环结构.5．数据字典包含哪些主要内容？

数据字典通常包括数据项、数据结构、数据流、数据存储和处理过程五个部分.据字典内容包括：

数据库中所有模式对象的信息，如表、视图、簇、及索引等。

分配多少空间，当前使用了多少空间等。

列的缺省值。

约束信息的完整性。

用户的名字。

用户及角色被授予的权限。

用户访问或使用的审计信息。

其它产生的数据库信息。

6．软件测试的目标是什么，有哪几种主要有测试方法？

软件测试的目标：

(1)测试是为了发现程序中的错误而执行程序的过程；

(2)好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案；

(3)成功的测试是发现了至今为止尚未发现的错误的测试。

软件测试的方法有黑盒测试、白盒测试。

7．白盒测试主要有哪些覆盖？

语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、点覆盖、边覆盖、路径覆盖

8、选择一种程序设计语言的主要有哪些依据？

为了使程序容易测试和维护以减少生命周期的总成本，选用的高级语言应该有理想的模块化机制，以及可读性好的控制结构和数据结构；为了便于调试和提高软件可靠性，语言特点应该使编译程序能够尽可能多地发现程序中的错误；为了降低软件开发和维护的成本，选用的语言应该有良好的独立编译机制。上述这些要求是选择语言的理想标准，但是在实际选用语言时不能仅仅考虑理论上的标准，还必须同时考虑实用方面的各种限制。

(1)系统用户的要求

(2)可以使用的编译程序

(3)可以得到的软件工具

(4)系统规模

(5)程序员的知识

(6)软件可移植性要求

(7)软件的应用领域

9．软件的维护的目标是什么，有哪几种维护类型？

纠正在使用过程中暴露出来的错误而进行的改进性维护，适应外部环境的变化而进行的适应性维护，改进原有的软件而进行的完善性维护，以及改进将来的可维护性和可靠性而进行的预防性维护。

软件维护主要划分为纠错性维护、适应性维护和完善性维护。

(1)纠错性维护。由于前期的测试不可能揭露软件系统中所有潜在的错误，用户在使用软件时仍将会遇到错误，诊断和改正这些错误的过程称为纠错性维护。

(2)适应性维护。由于新的硬件设备不断推出，操作系统和编译系统也不断地升级，为了使软件能适应新的环境而引起的程序修改和扩充活动称为适应性维护。

(3)完善性维护。在软件的正常使用过程中，用户还会不断地提出新的需求。为了满足用户新的需求而增加软件功能的活动称为完善性维护。

10．简述提高软件质量的主要措施。

复审：是在软件生命周期每个阶段结束之前，都采用一定的标准对该段产生的软件配置成分进行严格的正式或非正式的检测。

复查：是检查已有的材料，以断定在软件生命周期某个阶段的工作是否能够开始或继续。管理复审：是向开发组织或使用部门的管理人员提供有关项目的总体状况、成本和进度等方面的情况，以便他们从管理角度对开发工作进行审查。

测试：包括测试计划、测试过程和测试结果3个阶段。

11．面向对象如何实现模块独立性，其偶合和内聚的含义是什么？

因为对象是由数据及可以对这些数据施加的操作所组成的统一体，而且对象是以数据为中心的，操作围绕对其数据所需做的处理来设置，没有无关的操作。因此，对象内部各种元素彼此结合得很紧密。内聚性相当强，由于完成对象所需要的元素（数据和方法）基本上都被封装在对象内部，它与外界的联系自然就比较少。因此，对象之间的耦合通常比较松。总之，面向对象使用对象、类、继承和消息的方法，既使用类和继承等机制，而且对象之间仅能通过传递消息实现彼此通信来实现模块的独立性。

12．面向对象和面向过程软件工程有哪些区别？

（1）面向过程就是分析出解决问题所需要的步骤，然后用函数把这些步骤一步一步实现，使用的时候一个一个依次调用就可以了。面向对象是把构成问题事务分解成各个对象，建立对象的目的不是为了完成一个步骤，而是为了描叙某个事物在整个解决问题的步骤中的行为。（2）面向过程是把一件事一项工程分解成为一个个小的功能,用一个个函数来实现.面向对象是把事情看成是一个个小的对象组成的,或者说一个个小部分组成的,这些对象之间的相互关系,构成了整个项目.在面向对象的思想中，万物皆对象。而“类”，就是对象的抽象或者说是概括。

13.简述对象、类、消息、方法的基本概念。

(1)对象是人们要进行研究的任何事物，从最简单的整数到复杂的飞机等均可看作对象，它不仅能表示具体的事物，还能表示抽象的规则、计划或事件。

(2)类是具有相同或相似性质的对象的抽象。对象的抽象是类，类的具体化就是对象，也可以说类的实例是对象。类具有属性，它是对象的状态的抽象，用数据结构来描述类的属性。类具有操作，它是对象的行为的抽象，用操作名和实现该操作的方法来描述。

(3)对象之间进行通信的结构叫做消息。在对象的操作中，当一个消息发送给某个对象时，消息包含接收对象去执行某种操作的信息。发送一条消息至少要包括说明接受消息的对象名、发送给该对象的消息名（即对象名、方法名）。一般还要对参数加以说明，参数可以是认识该消息的对象所知道的变量名，或者是所有对象都知道的全局变量名。

(4)类中操作的实现过程叫做方法，一个方法有方法名、参数、方法体。

14．简述面向对象分析设计的三个模型。

答：三个模型：对象模型、动态模型、功能模型

（1）对象模型描述系统的静态结构，包括类和对象，它们的属性和操作，以及它们之间的关系。构造对象模型的目的在于找出与应用程序密切相关的概念。对象模型用包含对象及对象的关系图表示。

（2）动态模型着重于系统的控制逻辑，考察在任何时候对象及其关系的改变，描述这些涉及时序和改变的状态。动态模型包括状态图和事件跟踪图。状态图是一个状态和事件的网络，侧重于描述每一类对象的动态行为。事件跟踪图则侧重于说明系统执行过程中的一个特点“场景”，也叫做脚本(scenarios)，是完成系统某个功能的一个事件序列。脚本通常起始于一个系统外部的输入事件，结束于一个系统外部的输出事件。

（3）功能模型着重于系统内部数据的传送和处理。功能模型表明，通过计算，从输出数据能得到什么样的输出数据，但不考虑参加计算的数据按什么时序执行。功能模型由多个数据流图组成，它们指明从外部输出，通过操作和内部存储，直到外部输出的整个数据流情况。功能模型还包括了对象模型内部数据间的限制。功能模型中的数据流图往往形成一个层次结构，一个数据流图的过程可以由下一层的数据流图作进一步的说明。

第三篇：软件工程 重点归纳

程序：能够完成预定功能、并满足性能要求的可执行的指令序列。

软件:计算机程序以及开发、使用和维护程序所需要的所有文档,是包括程序、数据及其相关文档的完整集合。

软件=知识+程序+文档+数据

1、程序设计时期（1946～1956）软件=程序

开发方式：个体

主要特征：计算机硬件=计算机

用途少，规模小；不作为商品；

开发者=使用者：自己开发，自己使用。

2、程序系统时期（1956～1968）软件=程序+说明

开发方式：作坊式

主要特征：程序规模增大，多人分工合作。

软件作为商品，即程序设计者≠使用者；

程序开发和使用的文档资料已不可缺少。

3、软件工程时期（1968～现在）软件=程序+数据+文档

开发方式：工程化

主要特征：按工程管理的方法管理整个软件开发过程。

软件生产的进度、数量、质量、成本与社会对软件的需求量和希望要求甚远，开发成本和进度难以控制，指令难以保证，与硬件发展形成强烈反差。这就是所谓的“软件危机”。--现实与希望形成的巨大落差 产生软件危机的原因 ●客观原因：

软件是手工劳动，是智力产品----生产率低。

软件是逻辑实体，出错容易，纠错困难。

软件的复杂性使得仅靠人的智力难以驾驭。●主观原因

开发方式：认为开发软件就是写程序。

组织方式：作坊式的生产方式；开发无计划、开发过程无规范、开发过程难控制。

用户方面：对软件需求描述不精确。

开发人员方面：对用户需求的理解与用户本来愿望有差异，相互之间的信息交流不及时、不准确、有误解。

成本、进度和质量

软件工程三要素：过程、方法和工具

软件生存周期包括三个时期：

软件定义

问题定义、可行性研究、需求分析

• 需求规格说明书 • 初步用户手册 • 软件初步测试计划

软件开发 概要设计、详细设计、编码及模块测试、综合测试

软件使用和维护 改正性维护、适应性维护、完善性维护、预防性维护

软件过程模型--瀑布模型

软件过程模型—螺旋模型

数据字典的内容：

数据流

数据元素

数据存储

处理

数据结构的定义：描述数据结构的组成（1）定义式

数据结构名=数据项1+数据项2+……+数据项n 数据定义使用的符号： = 定义为

+ 和：连接两个分量 [ ] 选择：表示从中选择一项。{ } 重复：表示由0个或多个组成。

m{ }n 重复：表示至少出现m次，至多出现n次。

（）可选：表示其中的内容可出现，也可不出现。

IPO（Input/process/output）图是输入/处理/输出的简称，是由IBM公司发展完善起来的一种图形工具，能方便地描绘输入数据、数据的处理和输出数据之间的关系。

ER模型包括“实体”、“联系”和“属性”三个基本部分。

实体：是客观世界中存在的且可以相互区分的 物。如：职工、教师、产品等 联系：客观世界中事物间的联系。往往表示实体间发生的某种行为。属性：是实体或联系具有的性质，通常一个实体由若干个性质来刻画。

通常用“范式”（Normal Formas）定义消除数据的冗余的程度。

总体设计过程

一、系统体系结构设计

二、软件结构设计

三、数据库设计

四、制定测试计划

五、书写文档

六、审核和复审

软件设计原理

 抽象——抽出事物的本质特征而暂不考虑它们的细节。

 抽象和求精是一对互补的概念。求精则是帮助设计者逐步揭示出低层细节。这两个概念都有助于帮助设计者在设计演化过程中构造出完整的设计模型。

 模块化

 信息隐蔽（和局部化）——信息隐蔽是模块设计的基本原则，局部化是实现信息

隐蔽的重要方法。 模块独立

 模块的独立程度的度量标准——内聚:衡量一个模块内部各个元素彼此结合的紧密程度；耦合:衡量不同模块彼此间互相依赖（连接）的紧密程度。

层次图：描述软件的层次结构（H图）。

层次图中每个矩形框代表一个模块，矩形框之间的连线表示模块调用关系。

层次图适合用来描绘软件的层次结构。HIPO图：层次图+IPO图

对H图的每个方框，都有一张IPO图与之对应，来描述方框所代表的模块的处理过程。并且对每个IPO图都对应H图中方框相同的标记和编号，便于追踪。

面向数据流的设计方法

 概念

 变换流分析设计  事物流分析设计  混合流分析设计  设计优化

PAD是问题分析图（Problem Analysis Diagram）

变换流：

事务流：

概要设计小结

一、任务

1、系统体系结构设计：确定系统的总体物理实现方案。

2、软件结构设计：确定模块和模块间的动态调用管理。

3、数据结构设计（或数据库设计）：确定系统中数据的总体结构。（数据库：逻辑设计、物理设计、安全性设计）。

4、接口设计：外部接口、人机界面设计

二、设计原理

1、模块独立性原理：信息隐蔽、耦合、内聚

2、思维工具：抽象

3：启发式规则：改进软件结构，提高系统质量

三、设计工具： HIPO图、结构图

四、面向数据流的设计方法----结构化设计方法

1、从分析型的数据流图向软件结构的转换

2、从事务型的数据流图向软件结构的转换

详细设计工具分为图形、表格和语言三类。主要工具有： ■程序流程图 ■盒图（N-S图）■PAD图 ■判定表 ■判定树

■过程设计语言（PDL）

McCabe方法根据程序控制流的复杂程度来定量度量程序的复杂程度，这样度量出的结果称为程序的环行复杂度。

用户界面设计原则

1、置用户于控制之下。用户界面能够对用户的操作做出恰当的反应，并帮助用户完成需要的工作。

2、减少用户的记忆负担。系统应该“记住”有关的信息，通过默认项、快捷方式或界面视觉减少用户的记忆负担。

3、保持界面的一致性。用户应该以一致的方式展示和获取信息。问题：

●系统响应时间 ●用户帮助设施 ●错误信息处理 ●命令交互

界面设计包括：

●界面对话设计

●数据输入界面设计

●数据输出设计（屏幕显示设计）。

常用的界面设计元素有：

●问题描述语言

●数据表格

●图形与图标

●菜单

●对话框

●窗口

G.J.Myers关于软件测试的观点:

1、测试是为了发现程序中的错误而执行程序的过程。

2、好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案。

3、成功的测试是发现了迄今为止尚未发现的错误的测试。

E.D.Dijkstra:程序测试能证明程序中的错误，是为了证明程序有错，而不是证明程序无错。必须记住：测试无法说明错误不存在，它只能表示软件错误已经出现。

软件测试准则

1、以用户需求为基准

2、严格执行测试计划

3、测试中的群集现象

2-8原理：80%的错误可能集中在20%的模块中。

4、程序逻辑覆盖程度

5、第三方独立进行测试

6、合理的输入和不合理的输入

7、预期输出结果

步骤：

1、模块测试

2、子系统测试

3、系统测试

4、验收测试

5、平行运行

确认测试包括：

●软件有效性测试——运用黑盒测试方法，验证软件是否满足需求规格说明书列出的需求。

●软件配置复审——保证软件配置的所有成分都齐全，质量符合要求，文档与程序一致，具有完成软件维护所必须的细节，并且已经编排好分类的目录。、●α和β测试

●验收测试。

白盒测试：按照程序内部逻辑测试程序。检查程序中的每条通路是否都能按照预定要求正常工作。这种测试完全了解程序的结构和处理过程。因此，白盒测试又称为结构测试或逻辑驱动测试。黑盒测试主要是为了发现一下几类错误： ●是否有不正确或遗漏了的功能；

●界面错误：输入能否正确地接受？能否输出正确的结果？ ●是否有数据结构或外部信息（如数据文件）访问错误； ●性能上是否能够满足要求； ●是否有初始化或终止性错误。

软件工程的主要目的就是要提高软件的可维护性，减少软件维护所需要的工作量,降低软件系统的总成本。

软件维护——软件投入运行后，解决发生的各种故障，增强其功能，使之适应新的环境的活动。

1、改正性维护

2、适应性维护

3、完善性维护

4、预防性维护

维护工作量： M=p+k*exp(c-d)

P:生产性工作量：分析、评价、设计、修改和编码。K:经验系数

C:程序复杂性系数：文档少都会引起复杂程度增加。D:维护人员对软件的熟悉程度

维护过程

 维护组织

 维护报告

 维护的事件流

 保存维护记录

 评价维护活动

为了确定软件维护的有效程度，确定软件产品的质量，同时确定维护活动的开销，详细记录维护中进行的工作及工作量。主要内容包括（18项）

 程序标识  源程序语句数

 机器指令条数  使用的程序设计语言  程序安装的日期

 安装以来运行的次数  安装以来的失效次数  程序变动的层次和标识  每个改动耗费的人时数  程序改动的日期  程序变动增加的源语句数  维护人员名字

 程序变动而删除的源语句数  维护要求表的标识

软件配置管理（SCM）

 维护类型  维护开始时间和完成时间  累计用于维护的人时数

 与完成的维护相联系的纯效益

软件维护和软件配置管理之间的区别是：维护是一组软件工程活动，它们发生于软件已交付用户并已投入运行之后；软件配置管理是一组跟踪和控制活动，它们开始于软件开发项目开始之时，结束于软件被淘汰之时。

软件配置管理的主要目标是使变更更容易地被适应，并减少当变化必须发生时所需花费的工作量。

对维护活动进行度量。内容包括：

（1）每次程序运行平均失效次数（2）用于每一类维护活动的总人时数

（3）平均每个程序、每种语言、每种维护类型所作的程序变动次数（4）维护过程中增加或删除一个源语句平均花费的人时数。（5）维护每种语言花费的人时数（6）一张维护要求表的平均周转时间（7）不同维护类型所占的百分比

第四篇：软件工程重点整理

可以把软件开发的本质概括为：不同抽象层术语之间，以及不同抽象层处理逻辑之间的映射 需求分析产生的正式文档是需求规约

在结构化分析方法中，表示“数据的静态结构”的术语是数据存储

对模块的宽度影响最大的因素是模块的扇出 下列术语，可用于抽象客观世界中事物的是类

大学由若干专业系构成，则大学与专业的关系是组合

下列软件测试技术中，依据程序逻辑结构的是白盒测试技术 单元测试期间，通常考虑模块的重要的执行路径

软件基本过程指那些与软件生产直接相关的活动集，可分为供应过程、开发过程、运行过程、维护过程和获取过程

在常见的软件开发模型中，适用于项目的开发风险很大或客户不能确定系统需求的模型是螺旋模型

CMMI 能力等级中的 3 级是已定义级

软件生产率、软件质量满足不了社会发展的需求，并成为其发展的制约因素，这一现象被称为软件危机

对于单一的一个需求，必须具有的基本性质：必要的、无歧义的、可测试的、可跟踪的以及可测量的。

需求规约的基本性质包括重要性和稳定性程度、可修改的、完整的和一致的

在结构化分析方法中，可采用结构化自然语言、判定表和判定树描述加工

用于定义数据流图包含的所有数据流和数据存储的数据结构，直到给出构成以上数据的各数据项的基本数据类型的工具是数据字典

在 UML 中，用于描述关联的一定“内涵”的术语是关联名 RUP 利用 UML 提供的术语和工具定义了需求获取层、系统分析层、设计层和实现层，并给出了实现各层模型之间映射的基本活动以及相关的指导

软件测试是一个有程序的过程，包括测试设计、测试执行以及测试结果比较等

由于软件错误的复杂性，在软件工程测试中，应综合运用测试技

术，并且应实施合理的测试序列：

单元测试、集成测试、有效性测试和系统测试

《IS0/IEC 软件生存周期过程 12207—1995》标准按过程主体把软件生存周期过程分为基本过程、支持过程和组织过程 针对开发的 CMMI 是一个有关产品和服务的过程改善的成熟度模型，集成了 3 个源模型：软件 CMM、系统工程 CMM和产品集成开发 CMM

CMMI 中，遵循一个过程可达到的预期结果的程度是指过程能力

CMMI 模型基于过程途径思想，通过过程把软件质量的 3 个支撑点：受训的人员、规程和方法、工具和设备进行集成，以开发所期望的系统/产品

请简述计算机软件的概念以及提出软件工程概念的目的

（1）计算机软件一般是指计算机系统中的程序及其文档（2）其中，程序是计算机任务的处理对象和处理规则的描述（3）文档是为了理解程序所需的阐述性资料（4）软件工程概念的提出，其目的是倡导以工程的原理、原则和方法进行软件开发，以解决出现的软件危机。

请简述初始发现需求的常用技术（1）自悟（2）交谈（3）观察（4）小组会（5）提炼

请叙述信息隐藏的概念及其意义

（1）信息隐藏是指在每个模块中所包含的信息不允许其他不需要这些信息的模块访问（2）它是实现模块低耦合的一种有效途径（3）但是，如果一个模块是“绝对”信息隐藏的，那么这种模块对系统而言是毫无意义的

什么是验证和确认？请叙述它们的区别

（1）验证就是证实一个过程或项目的每一软件工作产品/服务是否正确地反映了所规约的需求（2）确认就是证实所期望使用的软件工作产品是否满足其需求（3）区别：验证是通过提供的客观证据，证实规约的需求是否得以满足；确认是通过提供的客观证据，证实有关特定期望的使用或应用的需求是否得以满足

第五篇：软件工程重点总结

软件工程复习重点总结

1.(P-2)

Analysis:

decompose a large problem into smaller, understandable pieces，(一个大问题分解成更小的、可以理解部分)abstraction is the key Synthesis:

build(compose)software from smaller building blocks,(生成撰写软件从较小的构造块)composition is challenging 2Software Engineering Solving Problems(continued)：(P-4)

method： refers to a formal procedure（指的是一个正式的程序）

tool：an instrument or automated system for accomplishing something in a better way procedure（过程）：a combination of tools and techniques to produce a product（工具和技术来生产一种产品的组合）

paradigm（范例）：philosophy or approach for building a product 3.(P-6)

A fault: occurs when a human makes a mistake, called an error, in performing some software activities（在执行某些软件活动）;

A failure: is a departure（偏差）from the system’s required behaviour;

Error can lead to fault；fault can lead to failure。4.participates in a project：(P-15)

Customer:

the company, organization, or person who pays for the software system Developer:

the company, organization, or person who is building the software system User: the person or people who will actually use the system

5.Activities and objects(P-16)– An activity is an event initiated by a trigger（活动是由一个触发器的事件）– Objects or entities are the elements involved in the activities（Objects 或实体是要素参与活动的）

6.Relationships and the system boundaries(P-17)– A relationship defines the interaction among entities and activities（A 关系定义实体和活动的相互作用）

– System boundaries determine the origin of input and destinations of the output（边界确定输入的来源与目的地的输出）

7.a system as a collection of things :(P-17)a set of entities(一组实体), a set of activities , a description of the relationships among entities and activities and a definition of the system.8.The development of software includes the following activities(P-24)• • • • Requirements analysis and definition System design Program design Writing the programs • Unit testing • Integration testing • System testing • System delivery • Maintenance 9.developer roles(P-26)Analyst

Designer

Programmer

Tester

Trainer 10.(P-45)A process: a series of steps involving activities, constrains, and resources that produce an intended output of some kind（一系列步骤涉及活动，受到了限制，及资源，产生一预期的输出）

A process involves a set of tools and techniques 11.(P-46)

Software life cycle:

Implementation ,delivery ,use, and maintenance（实施、发布、使用及维修）

When a process involves building a software, the process may be referred to as software life cycle – – – – – – – Requirements analysis and definition System(architecture)design Program(detailed/procedural)design Writing programs(coding/implementation)Testing: unit, integration, system System delivery(deployment)Maintenance

12．software process models：（P-48）

Waterfall model

V model Prototyping model(原型化)Operational specification model Transformational model（转化）

Phased development（阶段化开发）: increments and iterations（反复递增）Spiral model（螺旋模型）Agile methods（敏捷方法）

13.Prototyping is useful for verification(确认)and validation（验证）（P-51）14.Elements of a process are viewed in terms of seven types（P-64）

Activity – Sequence – Process model 过程模型 – – – – Resource Control Policy Organization

15.Project schedule(P-83)Describes the software-development cycle for a particular project by

enumerating the phases or stages of the project(枚举阶段或项目的阶段)

breaking each phase into discrete tasks or activities to be completed(每个阶段分成离散任务或活动，以完成)

Portrays(描绘)the interactions(相互影响)among the activities and estimates(估算)the times that each task or activity will take

16.Activity and milestone(P-83)Activity: takes place over a period of time

Milestone: completion of an activity--a particular point in time

17.Critical Path Method(CPM)(P--87)

见作业

18.Key activities requiring personnel（P-95）

requirements analysis system design program design program implementation（实现，执行）testing training maintenance

quality assurance（保证）

19.risk（P—119）

is an unwanted event that has negative consequences(消极结果)

20.Risk impact(影响):（P--120）

the loss associated with the event与该事件关联的损失

Risk probability(概率):

the likelihood that the event will occur事件发生的可能性

Risk control(控制):

the degree to which we can change the outcome我们可以更改结果的程度

Quantify(量化)the effect of risks：

Risk exposure =(risk probability)x(risk impact)

21.Risk management：（P--121）

risk assessment（评估）

risk control

22.（P--143）

A requirement：

is an expression of desired behaviour是所需行为的表达式 A requirement deals with ：

objects or entities，the states they can be in，and the functions that are performed to change states or object characteristics

23.Process for Capturing Requirements（P--144）

Elicitation（引入）

Analysis

Specification Validation（验证）

////构成了software requirements specification(说明书)

24.functional requirement（P---148）

describes required behavior in terms of required activitie描述所需的活动所需的行为s Quality requirement or nonfunctional requirement describes some quality characteristic that the software must possess(拥有)

Design constraint(约束):

a design decision such as choice of platform or interface components设计的平台或界面组件如选择决策 Process constraint: a restriction on the techniques or resources that can be used to build the system 对技术或可用于构建系统的资源限制

25.Prioritization might separate requirements into three categories（P--152）

Essential(基本): absolutely must be met绝对需要满足的需求

Desirable(合意): highly desirable but not necessary非常理想，但不必须的 Optional(可选): possible but could be eliminated但可能被淘汰

26.Requirements definition:（P--154）

a complete listing of everything the customer wants to achieve完整列表的客户希望实现的一切

Describing the entities in the environment where the system will be installed

描述在将安装在系统环境中的实体 Requirements specification:

restates（重申）the requirements as a specification of how the proposed（提出）system shall behave

27.ER diagram have three core constructs（P--158）ER 图表有三个核心构造

An entity: depicted as a rectangle, represents a collection of real-world objects that have common properties and behaviors描述为一个的矩形表示一个实际

的对象的集合 具有公共属性和行为

A relationship: depicted as an edge between two entities, with diamond in the middle of the edge specifying（指定）the type of relationship描述为一个两个实体之间的边缘

An attribute: an annotation(注解)on an entity that describes data or properties associated with the entity描述数据或与该实体相关联的属性的实体上的注释

28.（P--172）

A data-flow diagram(DFD)models functionality and the flow of data from one function to another数据流关系图 DFD 模型的功能和数据到另一个函数的流

– A buble represents a process一个 buble 表示一个流程 – An arrow represents data flow一个箭头表示数据流量

– A data store: a formal repository(仓库)or database of information –

Rectangles represent actors: entities that provide input data or receive the output result矩形表示参与者： 实体提供输入的数据或接收输出结果

–

29.(P--223)Design: is the creative process of transforming the problem into a solution The description of a solution is also known as design 是创造过程的问题转化为解决方案的描述称为设计

30.Design is a two-part interactive process(P—224)– Conceptual design(system design)(概念性设计)– Technical design(技术性设计)

–

31.(P—228)Modules or components: 组件

composite parts of design A system is modular when

– each activity of the system is performed by exactly one component活动的系统由一个组件执行

– inputs and outputs of each component are well-defined

• all inputs to it are essential to its function输入其功能至关重要

• all outputs are produced by one of its actions输出由其动作之一制作

32.Architectural Styles and Strategies Three Design Levels:(P—229)

Architecture（系统结构）

Code design

Executable design（执行设计）

33.Architectural Styles and Strategies Design Styles（P—230）

Pipes and filters(管道/过滤器)Object-oriented design Implicit invocation(隐式调用)Layering（分层设计）Repositories(数据仓库)Interpreters(解释器)Process control(过程控制)Client-server(客户/服务器)

34.Component independence（P--248）

Coupling(耦合度)Cohesion(内聚度)Highly coupled when there is a great deal of dependencies Loosely coupled components have some dependency, but the interconnections among components are weak（大多数采用松散）

Uncoupled components have no interconnections at all

35.We can measure coupling along a range of dependence（P--249）

Characteristics of Good Design Coupling: Types of Coupling

Content(内容)coupling

Common(公共)coupling Control(控制)coupling Stamp(标记)coupling Data(数据)coupling 36.Exceptions can be handled in one of three ways：（P—255）异常处理

– Retry(重试)– Correct(更正)– Report(报告)

37.program component involves at least three major aspect:(P---340)

Control structures ,algorithms,and data structure 38.making the codeefficiency(效率)may have hidden costs(代价)(P--342)– cost to write the code faster – cost to test the code – cost to understand the code – cost to modify the code

39.Software Faults and Failures types of Faults(P--367)软件故障及故障的类型的故障

Algorithmic fault算法

Computation and precision fault 计算和精度 Documentation fault Stress or overload faults Capacity or boundary faults 容量边界 Timing or coordination faults(协调)Throughput(吞吐量)or Performance faults Recovery fault 恢复故障

Hardware and system software fault Standards and procedures fault

40.Testing Organization（P—371.）

Module testing, component testing, or unit testing(单元测试)Integration testing(集成测试)The next step is ensuring that the interfaces among the components are defined and handled properly.Performance testing(性能测试)Compares the system with the remainder of these software an hardware requirements.41.Testing steps（P--372）

42.Integration Testing集成测试（P--390）具体实例见作业

Bottom-up(自底向上)

Merging components to test the larger system

Top-down(自顶向下)

Big-bang(大棒)

Sandwich testing(多层结构测试)

Modified top-down(改性自上而下)

Modified sandwich(改性多层结构测试)

43.Principles of System Testing Regression Testing Steps（P—425）系统测试回归测试步骤的原则

• Inserting the new code • Testing functions known to be affected by the new code • Testing essential function of m to verify that they still work properly整体 • Continuing function testing m + 1

44.Types of Performance Tests（P--436）性能测试

Stress tests(压力)Volume tests(容量)Configuration tests(配置)Compatibility tests(兼容)

Regression tests(回归)Security tests(安全)Timing tests(响应时间)Environmental tests(环境)Quality tests(质量)Recovery tests(恢复)Maintenance tests(可维护性)Documentation tests(文档)Human factors(usability)tests(使用)

45.Software reliability:

operating without failure under given condition for a given time interval 无故障下经营给予指定的时间间隔内的条件 Software availability:

operating successfully according to specification at a given point in time 成功经营，依法规范在指定点的时间 Software maintainability:

for a given condition of use, a maintenance activity can be carried out within stated time interval, procedures and resources 为给定的使用条件，维护活动可以内进行既定的时差 过程资源

注意：作业是重点，必考！这个翻译（长字段的）仅供参考，要结合软件工程的角度加以分析理解！