软件工程 - 万水书苑-出版资源网

第1 章 软件工程综述  本章要点：  软件工程及其发展  软件特点与分类  软件危机现象与原因  工程技术与工程管理  主流工程方法学

1. 什么是软件工程 软件工程是关于软件开发、使用与维护的工 程方法学，是一门涉及工程技术、工程管理与 工程经济等诸多内容的综合性工程学科。软件 工程建立在与软件有关的工程概念、原理与方 法基础上，它是对现实软件问题的工程方法探 索，具有鲜明的工程实用性。

2. 软件有什么特点  计算机系统由硬件、软件两部分组成。硬 件是物理部件，如：处理器、存储器、主板总 线，具有一定的物理形态，能够独立存在。软 件则是物理硬件以外的逻辑部件，如：程序、 数据、文档，抽象无形，不能独立存在。  软件工程需要研究如何更有成效地研发软 件、维护软件，要达到这个目标，则必然需要 对软件有很好的认识。

1. 软件研发团队

 需要组建优秀的软件研发团队，以生产出高质量的 软件产品。  软件研发机构应该有健康的可适应软件研发任务的 组织机体。项目小组则是最小的因项目任务组建的 研发团队，要求小而精，成员大多限制在 8 人以内。 主要成员有：项目负责人、开发人员、资料管理员 、软件测试员。  项目小组有多种管理机制，如：民主分权制、主程 序员负责制、职业项目经理负责制、层级负责制。

3. 为什么会发生软件危机

 20 世纪 60 年代中期，软件开发者遭遇到了 软件危机。主要危机现象有：软件开发成本进 度难估算、软件质量没有保证、软件不能满足 应用需要、软件缺乏可维护性。  危机客观原因：软件的逻辑隐蔽性、软件 的复杂性、软件的低产业发展水平。  危机主管原因：漠视用户需求、重结果轻 过程、个人英雄理念。

4. 软件工程技术、管理与目标

软件工程涉及的技术问题有： 软件过程：实现软件的步骤与工程框架； 工程方法：实现软件的技术性要素，如：工程规范、工程策 略、技术手段等。 软件工具：对工程方法与软件过程的自动化或半自动化支持 。 软件工程涉及的管理问题有：项目管理、人员管理、过程管 理、 产品管理。 软件工程还必须考虑工程目标，以体现其工程价值。一些主 要的工程目标是：降低成本、满足需求、改善性能、提高质 量、及时交付。

5. 主流工程方法学

 结构化方法学是传统的主流方法学，以功能为基本 元素，包括结构化分析（ SA ）、结构化设计（ S D ）与结构化实现 (SP) ，可对整个软件生命周期提 供方法学支持。  面向对象方法学则是目前的主流方法学，包括面向 对象分析（ OOA ）、面向对象设计（ OOD ）与面向 对象实现（ OOA ），可对整个软件生命周期提供方 法学支持。其以实体为基本元素，如：类体、对象 ，并可使程序系统基于现实实体构建，更加接近现 实环境。

6. 常用软件工具

 软件工程的还需要有软件分析设计工具的 支持。一些常用的软件分析设计工具有：  Microsoft Visio ：通用图形建模工具，可支 持结构化分析设计建模。  Sybase PowerDesigner ：专门的数据库建 模工具。

 IBM Rational Rose ：专门的 UML 建模工具 。

第 2

章 软件项目管理

 软件研发团队  软件项目计划  软件项目成本估算  软件项目风险  软件项目文档、配置与质量管理

1. 软件研发团队

 需要组建优秀的软件研发团队，以生产出高质量的 软件产品。  软件研发机构应该有健康的可适应软件研发任务的 组织机体。项目小组则是最小的因项目任务组建的 研发团队，要求小而精，成员大多限制在 8 人以内。 主要成员有：项目负责人、开发人员、资料管理员 、软件测试员。  项目小组有多种管理机制，如：民主分权制、主程 序员负责制、职业项目经理负责制、层级负责制。

2. 软件项目计划

 为使软件开发各项工作有秩序地进行，项目管理者必 须事先制定项目开发计划。  任务分配：进行任务分解，然后合理地、适度地给每 个成员分配项目任务。  进度安排：对项目任务及其资源按时序进行合理部署。 可基于里程碑制定项目进度计划，一些关键性成果， 如：需求规格说明书，可作为项目进度里程碑标志。  有许多工具可用来帮助建立项目进度计划，如：甘特 图、任务网络图。项目计划书则是项目计划的具体体 现，可作为软件开发的工作指南。

3. 软件项目成本估算

 软件项目有来自多方面的成本，如：工资开支 、场地费、差旅费、设备费、资料费。但项目 最主要成本是人员工资成本。软件成本估算， 主要就是是对人力成本的估算。  常用的人力成本成本估算方法有：程序代码行 成本估算、软件功能点成本估算、软件过程成 本估算。

4. 软件项目风险

 软件开发涉及诸多不确定性，用户需求的不确定性，技术策略的不确定 性，等等。这些不确定因素的存在，使得软件开发有了这样那样的风险 ，如：计划风险、管理风险、需求风险、技术风险、人员风险、产品风 险、用户风险、商业风险，等等。  值得注意的是，风险所影响的是项目的未来结果，我们只能判断其今后 的发生概率，而并不能够百分之百地确定其影响。因此，需要对风险实 施有效的管理，以降低风险事件的发生概率。风险管理主要任务有：  风险识别：调查是识别项目风险的有效途径。可以依据风险类别进行风 险调查，以对项目风险有较全面的把握。  风险评估：风险有多大的发生概率？风险有多大的影响力？  风险防范：可以从风险规避、风险监控与风险应急这三个方面进行风险 防范。

第 4

章 计算机系统工程

 计算机系统结构  软件系统前期分析  项目可行性分析

1. 计算机体系结构

 几种典型的计算机体系结构：  中央主机结构：主机集中了全部智能，并依靠终端 接口与外部设备连接。  客户机 / 服务器结构：智能分布于服务器与客户机 ，并依靠网络连接成系统。其中，服务器处于核心 位置，提供被动核心服务；客户机处于边缘位置， 可主动访问服务器，寻求服务支持。  浏览器 / 服务器结构：一种更适合互联网远程交互 的基于 Web 应用的特殊的客户机 / 服务器结构。

2. 软件系统前期分析

 可从以下方面进行软件高层分析：  软件系统的业务领域、业务边界与业务流程。  软件系统对硬件设施、网络环境、数据环境的 依赖。  软件系统的安全层级、措施与防范机制。  软件系统与其它相关系统之间的协作关系。  软件系统与用户组织及其工作任务的协调性与 适应性。

3. 项目可行性分析

以少量的时间及人力成本，对项目是否可着 手实施作出有依据的判断，以避免因项目实施 条件不具备而造成的大量的人力、物力与时间 的浪费。可从技术、经济、应用等几个方面进 行可行性分析，分析结论则需要撰写成可行性 分析报告，并提交有关部门确认。

5. 软件文档管理

 软件文档是工程模式软件开发的成果体现。然 而，软件文档要能产生很好的工程效应，则还 必须要有管理规范的支持。  开发时必须建立的技术资料、管理资料为正式 文档，通常需要专门归档。而根据需要随时创 建的并且无须归档的模型或工作表格则为非正 式文档。  按照文档使用范围，则又可分为：技术文档、 管理文档与用户文档。

6. 软件配置管理

 所谓软件配置，也就是基于软件生产轨迹进行 过程控制与产品追踪。其贯穿于整个软件生命 周期，因此可使软件开发中产生的各种成果具 有一致性。  软件配置的主要任务有：软件配置规划、软件 变更控制、软件版本控制。

7. 软件质量管理

 所谓软件质量，也就是对软件品质的优劣评价 。  软件开发者应该开发出高质量的软件产品，以 更好地满足用户应用。来自经验的结论是：严 格有效的软件质量管理，可带来高质量的软件 产品。  软件质量管理涉及问题有：质量标准、质量计 划与质量控制。

第 3

章 软件工程过程模式

 软件生命周期

 瀑布模式、原型进化模式、增量模式  螺旋模式、迭代模式、组件复用模式

1. 软件生命周期

 软件生存周期是软件由提出到开发到投入应用 的全过程，基于开发者立场一般划分为三个生 命段：定义期、开发期、运行维护期，每个生 命段又包含若干个阶段任务。

2. 瀑布模式

 瀑布模式是最传统的过程模式， 瀑布 形象表“ ” 达了其自顶向下、逐级细化的过程特征。  瀑布模式的特点是：（ 1 ）线性化过程； （ 2 ）里程碑管理；（ 3 ）阶段评审； （ 4 ）文档驱动。对于需求明确的软件项目 ，瀑布模式有较好的适应性。然而，如果需求 不明确或需求易变更，则瀑布模式就显现出了 不适应性。

3. 原型进化模式

 原型进化模式的开发流程是：开发者先建立原 型系统供用户评价或使用，然后根据用户的意 见反馈，对原型系统不断修正，由此使它逐步 接近并最终达到目标系统的要求。  原型进化模式可较好适应用户的需求变更，但 却因缺乏里程碑管理机制，而不能很好支持大 型项目。

4. 增量模式

 增量模式是瀑布模式与原型进化模式优点的结 合，其将系统分解为多个增量构件，然后以增 量构件为原型部件，逐步创建、集成与完善。  增量模式在整体上具有瀑布模式的里程碑特点 ，可适应大型项目。但系统的局部构建上，则 体现为基于增量构件的原型进化，可适应用户 的需求变更。

5. 螺旋模式

 螺旋模式是一种可较好规避开发风险的过程模 式。螺旋模式的特点是项目基于任务域螺旋式 递进，每一个任务域都需要进行风险评估，并 需要根据评估结论制定有效的风险规避措施。

6. 迭代模式

 迭代模式是软件的分析、设计与实现可交替反 复进行的过程模式。迭代模式有对面向对象方 法更好的过程支持，可使面向对象方法获得更 有成效的工程应用。

7. 组件复用模式

 组件复用模式是对基于组件的系统集成的过程 支持。组件复用可带来了流水线软件装配，系 统所需组件大多无须专门开发，而可通过专业 制作机构提供，由此可提高软件开发效率，并 可提高软件产品质量。

第 5

章 软件需求分析

本章要点：  需求分析任务  获取用户软件需求  软件需求建模  软件需求验证

1. 分析任务与过程

 需求分析是为有效解决用户需求问题而需要进行 的一项工程活动，所需考虑的需求问题有：功能 需求、数据需求、性能需求、接口需求。  开发者与用户都将参与需求分析活动。开发者承 担分析任务，但活动核心则是用户。  需求分析任务需要由熟悉用户业务的系统分析师 承担。  需求分析步骤是：获取用户需求、创建需求模型 、确定软件规格、进行需求验证。

2. 获取用户需求

 用户泛指一切可从软件获得服务的对象。可以 是某个人，但也可以是人以外的机构、部门、 其他系统或设备。  可通过调查而获取用户需求。然而，有效的需 求收集则依赖于有效的调查提问，并依赖于合 适的调查方法。一些常用调查方法是：访谈、 座谈、问卷、跟班、收集资料。  来自用户的需求将体现为需求规约，其可表达 用户的软件价值。

3. 建立需求模型

需求建模是用户需求问题图解，一些常用模 型有：业务树图、用例图、活动图。其中，业 务树是结构化需求建模，用例图是系统业务举 例，活动图则反映系统工作流程。

4. 进行需求验证

 需求验证是指对需求分析成果的检查与确认。 主要的需求验证内容有：有效性验证、一致性 验证、完整性验证、现实性验证、可检验性验 证。  可通过需求原型确认或需求评审，而实现需求 验证。

第 6

章 软件概要设计

本章要点：  概要设计任务  系统构架设计  数据结构设计  程序结构设计

1. 设计任务与过程

 概要设计也叫总体设计，需要确定软件系统总 体构造，涉及系统构架、程序结构、数据结构 、安全防范、故障处理等诸多方面的设计，以 对软件系统做出总的设计规划。  概要设计以需求规格定义为依据，首先要确定 的是系统构架，然后以系统构架为基础，确定 系统全局数据结构、程序结构，考虑系统安全 防范、故障处理措施。

2. 系统构架

 系统构架是软件系统的基础框架，需要考虑问 题有：系统支持环境、系统体系结构。  系统支持环境是构建软件大厦的地基，涉及硬 件环境、软件环境、网络环境。  系统体系结构则为软件系统总体结构。分层体 系是具代表性的软件体系结构。

3. 数据结构

 数据结构是指数据元素之间的逻辑关系。  程序设计中的数据结构，一般是动态数据结构 ，以服务功能为设计目标。概要设计中，需要 考虑的是影响诸多功能、跨越多个模块的全局 性程序数据。  数据库设计中的数据结构则一般是静态结构， 以建立合理存储为设计目标，所涉及元素有： 数据表、数据视图、数据索引。

4. 程序结构

 概要设计需要抽象模块，并从功能、数据、接口等诸多方面定义模块。  结构化程序中的模块是程序函数。面向对象程序中的模块是类体。在基 于组件的系统集成中，组件则被看做是模块。  高质量程序模块应该有很好的独立性，这样的模块通常更加安全、稳定 、可靠，也更加便于维护改造。内聚度与耦合度这两个技术指标可用于 判断模块是否有较好的独立性。  概要设计还需要确定模块之间的任务协作与控制，并设计一个合理的可 控制的可扩充的程序结构，以使诸多模块能够集成为一个整体。  结构化程序的控制是自顶向下的。总控模块对程序进行顶层整体控制， 下级模块则实现对具体任务的控制与操作。  面向对象程序则由类图、构件图说明结构。类图用于描述面向对象程序 逻辑结构，构件图用于描述面向对象程序物理结构。

第 7

章 程序算法设计与编码

本章要点：

 结构化流程控制  算法设计工具

1. 程序结构化流程控制

 程序结构化流程控制是高清晰度的控制。程序 如果能满足单人口、单出口的要求，则程序是 结构化控制。顺序、选择、循环等控制结构是 结构化控制。  GOTO 语句则是非结构化控制的代表。可使一 个程序块有多个出入口，可降低程序的稳定性 、可靠性与可维护性。

2. 程序算法设计工具

程序流程图、 NS 图、 PAD 图、 PDL 语言， 是与结构化控制相适应的算法设计工具。

3. 算法复杂度评估

 算法复杂度是对程序算法是否复杂的量化说明。 通常，可以从时间和空间两个方面，对程序算 法进行复杂度评价。  时间复杂度：由算法执行所耗费时间决定。通 常，算法中语句的执行次数越多，其花费时间 就越多，则时间复杂度就越高。  空间复杂度：由算法所需存储空间决定。通常 ，程序中定义的数据元素越少，采用的数据类 型越简单，则空间复杂度就越低。

MCCABE 方法

 这是一种基于控制流的广泛应用的程序算法复 杂度评估方法。其定义程序算法复杂度为强连 通程序图中线性无关的有向环的个数。计算公 式是：  V （ G ） = m – n + 1 ，其中， V 是强连通程 序图中的环数， m 是弧数， n 是节点数。

5. 程序编码

 编程语言可分为机器语言、汇编语言、传统高级语 言、结构化语言、面向对象语言、第四代程序语言。 有必要根据问题性质选择合适的程序语言，以提高 编程质量。  编程规范即是为提高程序可读性、可理解性而需要 遵守的约定。一些常用的编码规范有：程序注释、 标识符命名、程序编排格式。  程序算法设计还必须考虑程序的运行效率，其由程 序的算法复杂度、程序中数据的类型、程序编译的 优化程度等诸多因素决定。

第 8

章 软件测试

本章要点：  测试方法与过程  测试用例  面向对象测试  程序调试  测试工具

1. 测试目的、计划与方法

 软件测试之根本目的在于发现软件错误。软件 测试需要事先制定计划，如：测试时间、测试 任务、测试目标、责任人等，即需要通过测试 计划提前确定下来。  有黑盒测试与白盒测试两种基本测试方法。黑 盒测试以概要设计中的模块定义为测试内容， 主要用于系统确认测试、系统集成测试。白盒 测试则以详细设计中的程序算法说明为测试内 容，主要用于程序单元测试。

2. 测试任务

 软件测试任务有：单元测试、集成测试、确认测试。  单元测试是以基本单元模块为测试对象。一般以白盒测试为主， 以黑盒测试为辅。主要测试内容有：模块接口、局部数据结构、 执行路径、出错处理、条件边界等。  诸多单元模块可按照设计好的体系结构进行装配，在此过程中需 要集成测试，以发现模块之间是否有连接错误。  系统有非渐增集成与渐增集成测试两种集成策略。非渐增集成是 一次性把所有模块组合在一起。渐增集成测试则是每个单元模块 逐个地集成到系统中去。  在系统完成集成之后，接着需要进行确认测试，以确认用户需求 是否得以实现。测试内容有：软件有效性验证、软件配置复查。 测试方法有： Alpha 测试、 Beta 测试。

3. 测试用例

设计测试用例，就是为测试准备测试数据。 白盒测试用例为逻辑覆盖，主要有：语句覆盖 、判定覆盖、条件覆盖、判定条件覆盖、条件 组合覆盖和路径覆盖等几种覆盖形式。黑盒测 试用例则有等价类划分、边界值分析、错误推 测等几种设计方法。

4. 面向对象程序测试

面向对象程序涉及单元测试、集成测试、确 认测试，但测试内容不同。在进行面向对象程 序单元测试时，已经不能孤立地测试单个操作 ，而应该把操作作为类的一部分来测试。集成 测试则反映为基于线程的测试或基于使用的测 试。确认测试则体现为用例驱动。

5. 程序调试

 诊断发现错误并修正排除错误，这即是程序调 试。其中，诊断是关键。如果错误的性质与位 置被诊断出来，则改错只是一件相对简单的工 作。  主要诊断方法有：①在程序中插入输出语句； ②使用自动调式工具。  程序调试策略有：试探法、回溯法、对分查找 法、归纳法、演绎法。

6. 测试工具

 测试数据生成程序：用于自动生成测试用例。  动态分析程序：用于分析被测程序中某语句的 动态执行情况，如：执行次数、执行频率。  静态分析程序：用于扫描被测试程序正文，并 从中发现程序错误。

第 9

章 软件维护与再工程

 软件维护分类  软件可维护性  软件维护实施  软件再工程

1. 软件维护分类

 改正性维护  完善性维护  适应性维护  预防性维护

2. 软件可维护性

 软件可维护性是指维护人员对软件系统进行修 正、改进的难易。  影响软件可维护性的因素有：系统大小、系统 文档、系统年龄。  可通过软件的易理解性、可靠性、易修改性、 易移植性的评价，而对软件系统进行可维护性 综合评估。

3. 软件维护实施

 开发组可承担软件初期维护，但当软件转入正 常使用以后，其维护工作则一般由专门的维护 机构承担。软件维护机构人员组成有：维护负 责人、系统监督员、配置管理员、维护工程师。 其中，维护负责人全权负责维护任务，包括技 术与管理两个方面的工作。  维护将由申请报告启动，其一般由软件用户提 出。维护机构则对维护申请进行评审。维护活 动需要记录存档，需要进行评价。

4. 软件再工程

 软件再工程是指对已存在软件系统的重构与扩 充。

 再工程主要用于一些老系统改造，所涉及活动 有：逆向工程、重构工程、正向工程。

第 10

章 结构化分析建模

 分析建模特点

 数据、功能与行为建模  数据、功能与行为定义

1. 功能建模

 功能建模是对系统数据加工的图解。数据流图是最 常用的结构化功能建模工具，涉及数据接口、数据 处理、数据流、数据存储等图形元素，用于描述系 统数据加工细节。  数据流可以逐层细化，由此可逐步深入地解剖数据 处理过程。数据流细化一般自顶层业务环境开始， 然后到 1 层、 2 层，由此而逐步深入到系统内部获 取功能细节。  前期分析中的业务树可用于支持数据流功能细化， 以方便对功能的逐层解剖。

2. 行为建模

 行为模型用于说明软件系统与环境的交互。  状态转换图是最常用的软件行为建模工具，涉

3. 数据字典

 数据字典用于定义软件元素，以使软件元素获 得严密的、详细的、精确的规格说明。  早期软件开发中，数据字典需要使用手工方式 创建与维护。目前软件开发中，数据字典可依 靠 CASE 工具自动生成与维护。  需求分析模型中的数据、功能、行为等诸多方 面的元素，都有必要通过数据字典给予细节说 明，以达到对系统较完整全面的规格定义。

第 11

章 结构化设计建模

 程序结构建模语言

 基于数据流的程序结构映射  程序结构优化

1. 建模语言

 常用的结构化图形建模语言是：程序结构图、 H-IPO 图。  程序结构图比较适合设计者构思程序结构，但模块功 能特征较难由模型体现，因此在模型之外还需要有对 模块的详细说明。  H-IPO 图则可带来较高的建模清晰度，其由 H ” ““ 图 与 I PO ”图 组合。 H 图表示程序结构， IPO 图则定义模块 ，描述模块：输入、处理、输出。  程序结构还可表示为框架伪码，以方便由结构设计到 算法设计的过渡。

2. 结构化程序结构映射

 基于数据流的结构映射，是以功能为目标的结 构化建模方法的延伸，可达到由功能分析到功 能设计的有效转换。  数据流可分为变换流与事务流，并可根据其特 征，分别按不同方法进行结构映射。

3. 程序结构优化

 通过数据流映射只能获取程序的基本框架，一 般还需要对程序结构进行结构优化。  可从模块独立性、模块接口复杂度、程序过程 流畅性、程序构造简洁性等诸多方面，对程序 结构进行优化。  一些源于经验的启发性原则，可为程序结构优 化提供指导性参考。

第 12

章 面向对象分析建模

 UML 特点  用例建模  活动建模  类分析建模

1. UML 特点

 UML 是统一建模语言，有统一的语法规则、 语义规则与语用规则，并可从多个不同视角建 立软件模型。  UML 的建模的过程特点是：用例驱动、以构 架为中心、增量迭代。  UML 通过包实现了对模型的有效的一体化的 管理。

2. 用例建模

 用例建模是面向用户需求的，能够反映系统的用户价值 。  用例图中的基本元素有：  用例：用户业务级程序实例，使用椭圆图标表示。  参与者：可与系统进行主动交流的外部环境元素，使用 人形图标表示。  交流：系统与用户之间的交互或通信，使用连线表示。  参与者之间可建立泛化关系。用例之间有泛化、延伸、 包含关系。

3. 活动建模

 活动图用于描述系统动态过程，主要图形元素 有：活动、转换、起点、终点、判断、并发、 同步、泳道等。  可使用活动图说明高层业务级活动，这通常涉 及整个业务流程。也可针对每个用例进行活动 建模，以反映用例内部活动细节。

4. 类分析建模

 面向对象程序涉及控制类、边界类、实体类， 分析中主要考虑的是实体类。  类分析建模首要工作是发现实体类。可使用名 词搜索法发现候选类，然后再从候选类中筛选 出实体类。  实体类所代表的数据相互之间通常有一定的关 系。依靠这种关系可形成有组织的程序数据结 构。实体类之间的主要数据关系有：关联、聚 集、泛化。

第 13

章 面向对象设计建模

 设计建模步骤  程序静态结构  程序动态过程

1. 面向对象设计方法

 结构化程序设计以功能为依据，并以实现功能为目标。面 向对象程序则有与结构化程序不同的内部构造与运行机制 ，因此需要有不同于结构化程序的专门的设计方法的支持 。  面向对象程序是以实体为依据，并基于实体及其控制确定 程序结构，并还需要考察对象行为，说明对象动态行为过 程。  UML 可提供面向对象设计建模。所涉及模型有：设计类图 、状态图、协作图、时序图、构件图、部署图。设计建模 应是合乎逻辑的推论，并需要从逻辑结构、动态过程与物 理结构这三个方面的建模。

2. 逻辑结构设计

 系统构架是构造程序系统的基本框架，需要优 先考虑。分层构架则是一种常用的构架模式， 其特点是程序系统按功能支持分层构建，如： 应用层、中间件层、系统层等。  应用程序框架则涉及程序构造。一个复杂的程 序系统，可被划分为诸多相对简单的任务子系 统。这样的任务子系统，大多有一定的独立性 ，并是搭建程序框架的基本元素。

3. 动态过程设计

 动态过程模型有：协作图、时序图、状态图。  协作图可说明对象之间的动态交互。协作图建模也将依靠 用例驱动。已经获得的基于用例的类关系模型，可作为协 作建模的结构背景，由此可获取到有关对象的协作框架。  时序图也是针对对象的动态行为建模，但基于对象生命线 说明对象交互，因此有比协作图更加直观清晰的时序说明 。  状态图可描述对象状态及其迁移。通常，状态图中的对象 是一个取自系统的个体元素。因此，在对某个对象进行状 态考察时，并无须过多考虑它与其他对象的交互。

4. 物理装配与部署

 构件图是软件系统物理建模，用于反映软件系 统基于构件的物理集成与装配。  部署图可说明程序系统的安装部署，可反映程 序系统运行时，各种将驻留或执行程序的计算 机设备之间的物理关联。

第 14

章 数据库分析与设计

 数据库体系架构  数据分析与建模  数据库结构设计  数据库访问设计

1. 数据库体系架构

 数据库可划分为外模式、模式、内模式这三层模式。 基于数据库三层模式，可建立外模式到模式、模式 到内模式两级映像，并由此能获得数据的逻辑独立 与数据的物理独立。  大型数据库系统一般基于数据库服务器构建，其特 点是：后台数据库服务器处理数据、前端客户机表 现数据。  通常情况下，如果一个系统既要基于互联网进行远 程通信，又要基于内部网进行数据传送，则可能需 要采用数据分布处理。

2. 数据库分析建模

 实体关系图是应用得最广泛的数据库分析建模 方法，涉及实体、关系、属性等图形元素 .

3. 数据库结构设计

 数据表：数据库中数据的逻辑存储结构，由字段 、主键并确定。  数据关联：用于在两个数据表之间建立联系，其 中一个为主表，另一个则为从表。  数据索引：建立对数据表中数据按字段或字段集 的有序检索。  数据完整性：涉及数据表内部的实体完整性，数 据表之间的参照完整性，以及其它方面约束的自 定义完整性。

4. 数据库访问设计

 数据视图：是建立于数据库内的可供访问的数 据关系类型变量，由逻辑层的数据表经由一定 的关系运算（如：并、交、积、投影、选择） 映射而成，并由 SQL 创建。  存储过程：建立于数据库内的程序函数，可供 访问者外部调用。  数据事务：用于定义一个完整的数据操作任务 ，以确保对数据的处理的可预见性。

第 15

章 非主流工程方法

 敏捷工程方法  净室工程方法

 Jackson 程序设计方法  Z 语言形式化规格说明

1. 敏捷工程方法

敏捷价值观  个体与交互胜于过程和工具。  可工作软件胜于宽泛的文档。  客户合作胜于合同谈判。  响应变化胜于遵循计划。

2. 净室工程方法

净室工程策略  基于增量的软件开发  基于盒结构的软件建模  基于函数理论的程序正确性验证  基于统计理论的软件测试

3. JACKSON 设计方法

 一种基于数据结构的算法设计方法 .

 可依据输入输出数据结构，而映射处理数据的 程序结构，涉及顺序、选择、重复三种结构映 射。

4. Z 语言形式化规格说明

 一种获得了最广泛使用的形式化规格说明语言 ，以集合运算与谓词逻辑演算为数学语言，并 以模式图形符号组织形式化说明。  有基于数学的形式化说明的严密性，又有基于 模式图形符号的直观性，在提供形式化说明的 同时，能带来较好的可读性。