第一章 概论
1.在《计算机科学百科全书》中，对计算机软件作如下定义：计算机软件指计算机系统中的程序及其文档。程序是计算任务的处理对象和处理规则的描述，任何以计算机为处理工具的任务都是计算任务。处理对象是数据（如数据、文字、图形、图像、声音等，它们只是表示，而无含义）或信息（数据及有关的含义）。处理规则一般指处理的动作和步骤。程序必须装入计算机内才能工作。文档是为了便于了解程序所需的阐明性资料，文档一般是给人看的，不一定装入计算机。
2.软件的特点：（1）软件是一种逻辑实体，而不是有形的系统元件，其开发成本和进度难以准确地估算（2）软件是被开发的或被设计的，它没有明显的制造过程，一旦开发成功，只需复制即可，但其维护的工作量大（3）软件的使用没有硬件那样的机械磨损和老化问题
3.在《计算机百科全书》中，将软件分为系统软件、支撑软件、应用软件3类
4.设计性语言用来书写软件设计规约（design specification），典型的设计性语言有PDL语言（Program Design Language）。实现性语言是用来书写计算机程序的语言。
（1）按用户要求分：过程式语言和非过程式语言。过程式语言有FORTRAN、Java、C等。非过程式语言如PROLOG。
（2）按应用范围分：通用语言和专用语言：通用语言如FORTRAN、Java、C等，专用语言如自动数控程序APT。
（3）按使用方式分：交互式语言和非交互式语言，交互式语言如BASIC。非交互式语言如FORTRAN、COBOL。
（4）按成分性质分：顺序语言、并发语言、分布语言。顺序语言如FORTRAN、C。并发语言如Modula、Ada、并发Pascal。分布语言指考虑到分布计算要求的语言，如Modula。
5.软件工程定义：
（1）Fritz Bauer：软件工程是为了经济地获得可靠的和能在实际机器上高效运行的软件而建立和使用的好的工程原则
（2）软件工程是（1）将系统化的、规范的、可度量的方法应用于软件的开发、运行和维护的过程，即将工程化应用于软件中
（3）《计算机科学技术百科全书》：软件工程是应用计算机科学、数学及管理科学等原理，以工程化的原则和方法制作软件的工程
6.软件工程的框架可概括为：目标、过程、原则
7.软件生存周期大致分为如下6个阶段计算机系统工程、需求分析、设计、编码、测试、运行和维护
8.软件过程是生产一个最终满足需求且达到工程目标的软件产品所需的步骤。《计算机科学百科全书》中指出：软件过程是软件生存周期中的一系列相关的过程。过程是活动的集合，活动是任务的集合。
9.软件过程成熟度等级有5个：如右图所示————
10.成熟度等级表明了一个软件组织的过程能力的水
平。除初始级外，每个成熟度等级都包含若干个关键过程
域（Key Process Area，简称KPA）。CMM提供了18个关
键过程域，每个关键过程域都有一组对改进过程能力非常
重要的目标，并确定了一组相应的关键实践，关键实践描
述了建立一个过程能力必须完成的活动和必须具备的基础
设施，完成了这些关键实践就达到了相应关键过程域的目
标，该关键过程域也就得到了满足。每个关键过程域的关
键实践都是按照五个共同特性（执行约定，执行能力，执行活动，测量和分析，验证实现）进行组织的，主要解决关键实践的实施或制度化问题。
11.CMMI模型为每个学科的组合都提供两种表示法：阶段式模型和连续式模型
12.瀑布模型的特征：（1）接受上一阶段的结果作为本阶段的输入（2
）利用这一输入实施本阶段应完
成的活动（3）对本阶段的工作进行评审（4）将本阶段的结果作为输出，传递给下一阶段
13.原型：为了减少因为对需求的了解不确切而给
软件开发带来的风险，可以在获取了一组基本的需求
后，通过快速分析，而构造处的关于该软件的一个初
始可运行版本。
14.原型模型根据使用原型的目的不同分为：探索
型、实验型、演化型
15.螺旋模型沿着螺线自内向外旋转，在四个象限
上分别表达四个方面的任务，即：（1）制定计划：确
定软件目标，选定实施方案，弄清项目开发的限制条
件（2）风险分析：评价所选的方案，识别风险，消除风险（3）工程实施：实施软件开发，验证工作产品
（4）客户评估：评价开发工作，提出修正建议
16.喷泉模型
“喷泉”一词体现了面向对象方法的迭代和无间隙特性，迭代是指各开发
活动需要多次重复，无间隙是指开发活动之间不存在明显的边界。
17.敏捷软件开发的价值观：（1）个人和交互高于过程和工具（2）可运行
软件高于详尽的文档（3）与客户协作高于合同（契约）谈判（4）对变更及时
做出反应高于遵循计划
18.（1）最优先的是通过尽早地和不断地提交有价值的软件使客户满意（2）
欢迎变化的需求，即使该变化出现在开发的后期，为了提升对客户的竞争优势，
Agile过程利用变化作为动力（3）以几周到几个月为周期，尽快、不断地发布
可运行软件（4）在整个项目过程中，业务人员和开发人员必须天天一起工作（5）以积极向上的员工为中心建立项目组，给予他们所需的环境和支持，对他们的工作予以充分的信任（6）项目组内效率最高、最有效的信息传递方式是面对面的交流（7）测量项目进展的首要依据是可运行的软件（8）敏捷过程提倡可持续的开发，项目发起者、开发者和用户应能长期保持恒定的速度（9） 应时刻关注技术上的精益求精和好的设计，以增强敏捷性（10）简单化是必不可少的，这是尽可能减少不必要工作的艺术（11）最好的构架、需求和设计出自于自我组织的团队（12）团队要定期反思怎样才能更有效，并据此调整自己的行为
19.XP方法称为极限编程。XP方法由Kent Beck提出，适用于软件需求模糊且挥发性强、开发团队人数在10人以下、开发地点集中的场合
XP方法的4个价值观：交流、简单、反馈、勇气
XP方法的12各核心实践：完整的团队、计划对策、系统比喻、小发布、测试、简单设计、结对编程、设计改进、持续集成、代码全体共有、编码标准、可持续步调
20.XP方法的开发过程：（1）探索阶段：主要工作是开发初始的用户故事和体系结构骨架（2）计划阶段：是根据用户故事描述的需求、系统体系结构骨架和系统比喻来制订迭代计划和发布计划（3）迭代到发布阶段：根据迭代和发布计划，开发满足指定用户故事需求的软件，并与前面已完成的软件版本集成，得到软件的一个新版本（4）产品化阶段：主要工作是确认迭代开发的软件已经做好进入产品化的准备。可能要写的文档：系统文档、操作文档、支持文档、用户文档、维护阶段
第二章 系统工程
1.基于计算机的系统是指：通过处理信息来完成某些预定义目标而组织在一起的元素的集合或排列。组成基于计算机系统的元素主要有：软件、硬件、人员、数据库、文档和规程
2.系统工程的任务：（1）识别用户的要求（2）系统建模和模拟：包括硬件系统模型、软件系统模型、人机接口模型、数据模型；（3）成本估算及进度安排（4）可行性分析（5）生成系统规格说明
3.可行性分析考虑：成本、效益、货币的时间价值、投资回收期、纯收入
技术可行性分析包括：风险分析、资源分析、技术分析
法律可行性分析：1990年我国颁布了《中华人民共和国著作权法》，1991年国务院颁布了《计算机软件保护条例》
方案的选择和折衷：由于系统的功能和性能受到多种因素的影响，某些因素之间相互关联和制约。在必要时应进行折衷
第三章 需求工程
1.将软件需求工程细分为：需求获取、需求分析与协商、系统建模、需求规约、需求验证和需求管理六个阶段
2.软件需求的具体内容包括：功能需求、性能需求、用户或人的因素、环境需求、界面需求、文档需求、数据需求、资源使用需求、安全保密要求、可靠性需求、软件成本消耗与开发进度需求、其他非功能性要求
3.需求获取方法与策略：建立顺畅通信途径、访谈与调查、观察用户操作流程、组成联合小组、用况
4.信息域包括：信息内容、信息流以及信息结构
5.需求规约包括：引言、信息描述、功能描述、行为描述、检验描述、参考书目、附录
6.需求验证目的是要检验需求是否能够反映用户的意愿。评审人员评审时往往需要检查以下内容：
（1）系统定义的目标是否与用户的要求一致
（2）系统需求分析阶段提供的文档资料是否齐全；文档的描述是否完整、清晰、准确反映用户要求
（3）被开发项目的数据流与数据结构是否确定且充足
（4）主要功能是否已包括在规定的软件范围之内，是否都已充分说明
（5）设计的约束条件或限制条件是否符合实际
（6）开发的技术风险是什么
（7）是否详细制定了检验标准，它们能否对系统定义是否成功进行确认
第四章 设计工程
1.软件设计开始于软件需求的分析和规约之后，位于软件工程过程中的技术核心位置，是把需求转化为软件系统的最重要环节
2.软件设计是把软件需求变换成软件表示的过程，它主要包含两个阶段：软件体系结构设计阶段和部件级设计，前者也被称为概要设计，后者被称为详细设计。软件体系结构设计将软件需求转化为数据结构和软件的系统结构。部件级设计将软件体系结构性元素转化为软件部件的过程性描述，得到软件详细的数据结构和算法。
3.软件设计原则：抽象、逐步求精、模块化、信息隐藏
4.模块的独立性可以由两项指标来衡量：内聚度与耦合度。内聚度衡量一个模块内部各个元素彼此结合的紧密程度，耦合度衡量不同模块之间相互依赖的紧密程度
5.内聚：是一个模块内部各个元素彼此结合的紧密程度的度量。内聚可以分为以下7中类型：
1）巧合内聚（偶然内聚）：将几个模块中没有明确表现出独立功能的相同程序代码段独立出来建立的模块称为巧合内聚模块
2）逻辑内聚 ：指完成一组逻辑相关任务的模块，调用该模块时，由传送给模块的控制型参数来确定该模块应执行哪一种功能
3）时间内聚：指一个模块中的所有任务必须在同一时间段内执行。例如初始化模块和终止模块
4）过程内聚 ：指一个模块完成多个任务，这些任务必须按指定的过程（procedural）执行
5）通信内聚 ：指一个模块内所有处理元素都集中在某个数据结构的一块区域中
6）顺序内聚：指一个模块完成多个功能，这些功能又必须顺序执行
7）功能内聚 ：指一个模块中各个部分都是为完成一项具体功能而协同工作，紧密联系，不可分割的
6.耦合：是模块之间的相对独立性的度量。耦合取决于各个模块之间接口的复杂程度、调用模块的方式以及通过接口的信息类型。耦合方式有其中类型：
1）内容耦合 ：如果一个模块直接访问另一个模块的内部数据；或者一个模块不通过正常入口转到另
一模块内部；或者两个模块有一部分程序代码重迭；或者一个模块有多个入口，则两个模块之间就发生了内容耦合
2）公共耦合 ：若一组模块都访问同一个公共数据环境，则它们之间的耦合就称为公共耦合。公共的数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等
3）外部耦合 ：指模块间通过软件之外的环境联结（如I/O将模块耦合到特定的设备、格式、通信协议上）时，称为外部耦合
4）控制耦合：如果一个模块传送给另一个模块的参数中包含了控制信息，该控制信息用于控制接收模块中的执行逻辑，则称为控制耦合
5）标记耦合：两个模块之间通过参数表传递一个数据结构的一部分（如某一数据结构的子结构），就是标记耦合
6）数据耦合：两个模块之间仅通过参数表传递简单数据，则称为数据耦合
7）非直接耦合 ：如果两个模块之间没有直接关系，即它们中的任何一个都不依赖于另一个而能独立工作，这种耦合称为非直接耦合
7.耦合与内聚都是模块独立性的定性指标，都反映了模块独立性的良好程度。但耦合是直接的主导因素，内聚则辅助耦合共同对模块独立性进行衡量
8.当人们提到软件的体系结构会考虑到软件是单主机结构、客户/服务器结构还是浏览器/服务器结构
9.软件体系结构的风格，每种风格描述一种系统范畴，范畴包括：
①一些实现系统所需的功能的部件（如数据库、计算模块）
②一组用来连接部件“通信、协调和合作”的“连接件”
③定义部件之间怎样整合的系统约束
④使设计者能够理解整个系统属性并分析已知属性的语义模型
10.数据为中心体系结构，在这种体系结构中，一些数据（比如一个文件或者数据库）保存在整个结构的中心，并且被其他部件频繁地使用、添加、删除、或者修改。在一些情况下客户端部件独立于对数据的任何改变或其他客户部件的动作而访问数据，折衷方法的一个变种是将存储中心变换为“黑板”，当客户感兴趣的数据变化时，由黑板向客户端部件发送通知。在这种结构中，现有的客户端部件可以被修改，而且新的数据可以被方便的加入系统而无需考虑其他客户
11.数据流风格的体系结构，这种结构适用于输入数据被一系列的计算或者处理部件变换成输出数据。这种结构由管道和过滤器组成。过滤器之间由传送数据的管道联通。每个过滤器在上下管道间独立工作，被设计成某种特定形式的预期数据输入，并产生数据输出。但是，过滤器并不需要知道相邻其他过滤器是如何工作的
12.调用和返回风格的体系结构，这种风格使一个软件设计者设计出非常容易修改和扩充的体系结构。包含：主程序/子程序风格体系结构和远程过程调用风格的体系结构。其中，主程序/子程序风格体系结构：面向结构化分析与设计方法中，把功能分解为控制层次，体系结构反映系统中模块的相互调用关系：顶层模块调用它的下层模块以实现程序的完整功能，每个下层模块再调用更下层的模块，最下层的模块完成最具体的功能。远程过程调用风格的体系结构是主程序/子程序风格体系结构的扩展，再这种结构中被主程序调用的部件被分布在网络上不同的计算机中
13.面向对象风格的体系结构：系统部件封装数据和操作数据的方法。部件之间的交互和协调通过消息来传递
14.层次式风格的体系结构：在这种结构中，定义不同的层次，每层都完成了相对外层更靠近机器指令的操作。再最外面的层中，部件向用户提供接口操作。在最内不的层中，部件使用系统接口。每个中间层都是对内层接口的封装
15.部件级设计技术：部件在不同的分析设计方法中对应不同的名称。在结构化分析和设计方法时部件往往被称为模块。在面向对象分析和设计时部件被称为类：在基于构件的开发方法中，部件被称为构件。
第五章 结构化分析与设计
1.结构化分析过程分为以下4个步骤：（1）理解当前的现实环境，获得当前系统的具体模型(物理模型)
（2）从当前系统的具体模型抽象出当前系统的逻辑模型（3）分析目标系统与当前系统逻辑上的差别，建立目标系统的逻辑模型（4）为目标系统的逻辑模型作补充
2.数据流图（DFD）：描述输入数据流到输出数据流的变换（即加工）过程，用于对系统的功能建模
3.数据流图的基本图形元素包括：数据流、加工、文件、源和缩
4.值得注意的是：在数据流图DFD中描述的是数据流，而不是控制流
5.数据流图的扩充符号：星号(＊)：表示数据流之间存在“与”关系；加号(＋)：表示数据流之间存在“或”关系；异或(⊕)：表示数据流之间存在“异或”(互斥)关系
6.分层数据流图的完整性包括以下4个方面：（1）每个加工至少有一个输入数据流和一个输出数据流
（2）在整套分层数据流中，每个文件应至少有一个加工读该文件，有另一个加工写该文件（3）分层数据流图中的每个数据流和文件都必须命名(除了流入或流出文件的数据流)，并保持与数据字典的一致 （4）分层DFD中的每个基本加工(即不再分解子图的加工)都应有一个加工规约
7.构造分层数据流图DFD时需注意的问题：适当命名；化数据流而不是画控制流；避免一个加工有过多的数据流；分解尽可能均匀；先考虑稳定状态，忽略琐碎的枝节；随时准备重画
8.在自顶向下画数据流图时，可参照以下几条与分解有关的原则：7加减2；分解应自然，概念上合理、清晰；只要不影响DFD的易理解性，可适当多分解几个加工，以减少层数；一般说来，上层分解得快些(即多分解几个加工)，下层分解得慢些(即少分解几个加工)；分解要均匀
9.数据字典，字典条目分为：数据流、文件、数据项（组成数据流和文件的数据）、加工、源和宿
10.判断表的组成：条件桩、条件条目、动作桩、动作条目
11.结构图的基本成分有：模块、调用和数据
12.结构图的几个概念：
深度：程序结构图中控制的层数
宽度：程序结构图中同一层次上模块总数的最大值
扇出：该模块直接调用的模块数目
深度和宽度在一定程度上反映了程序的规模和复杂程度。相对而言，如果程序结构图的深度和宽度较大，则说明程序的规模和复杂程度都较大。模块的扇入扇出会影响结构图的深度和宽度，例如减少模块的扇出，可能导致宽度变小而深度增加。一个模块的扇出过大通常意味着该模块比较复杂，然而扇出太少，可能导致深度的增加。一般情况，一个模块的扇出以3～9为宜。一个模块的扇入表示有多少模块可直接调用它，它反映了该模块的复用(reuse)程度，因此模块的扇入越大越好
13.为了有效的模块化，给出以下启发式设计策略：
（1）改造程序结构图，降低耦合度，提高内聚度
（2）避免高扇出，并随着深度的增加，力求高扇入
（3）模块的影响范围应限制在该模块的控制范围内
（4）降低模块接口的复杂程度和冗余程度，提高一致性
（5）模块的功能应是可预测的，避免对模块施加过多的限制
（6）尽可能设计单入口和单出口的模块
14.通常，一个模块的大小以50—100行程序代码为宜，即一个模块的程序代码可写在1—2页纸上
15.结构化程序设计是将结构画分析的结果（数据流图）映射成软件的体系结构（结构图）。根据信息流的特点，可将数据流图分为变换型数据流图和事务型数据流图，对应的映射分别为变换分析和事务分析
16.信息流可分为变换流和事务流
第六章 面向数据结构的分析与设计
1.面向数据结构的需求分析与设计方法，其典型方法有：Jackson方法和Warnier方法。这类方法有如下特点：（1）以信息对象及其操作为核心进行需求分析（2）认为复合信息对象具有层次结构，并且可按顺序、选择、重复三种结构分解为成员信息对象（3）提供由层次信息结构映射为程序结构的机制，从
而为软件设计奠定良好的基础
2.面向数据的分析和设计方法是以数据结构为中心，从输入/输出的数据结构到处程序结构
1. 第七章 面向对象的分析与设计 面向对象 = 对象+ 分类+ 继承+ 通过消息的通信
2.重载：父类中定义了其所有子类的公共属性和操作，在子类中除了定义自己特有的属性和操作外，还可以对父类（或祖先类）中的操作重新定义其实现方法
3.多态性：是指同一个操作作用于不同的对象上可以有不同的解释，并产生不同的执行结果
4.动态绑定：是指在程序运行时才将消息所请求的操作与实现该操作的方法连接起来
5.面向对象分析的一般步骤如下：（1）获取客户对系统的需求：包括标识场景和用况，以及建造需求模型；（2）用基本的需求为指南，来选择类和对象（包括属性和操作）；（3）定义类的结构和层次；（4）建造对象—关系模型；（5）建造对象—行为模型；（6）利用用况/场景来复审分析模型
6.面向对象设计（OOD）的一般步骤如下：（1）系统设计：将子系统分配到处理器；选择实现数据管理、界面支持和任务管理的设计策略；为系统设计合适的控制机制；复审并考虑权衡（折衷）。（2）对象设计：在过程级别（procedural lavel）设计每个操作，定义内部类；为类属性设计内部数据结构。（3）消息设计：使用对象间的协作和对象--关系模型，设计消息模型（4）复审设计模型并在需要是迭代
7.UML的组成：基本构造块、组织构造块的规则、运用于整个UML的公共机制
8.类图：展示了系统中类的静态结构，即类与类之间的相互联系。类之间有多种联系方式，如关联（相互连接）、依赖（一个类依赖或使用另一个类）、泛化（一个类是另一类的特殊情况）等。
9.对象图：是类图的实例，它展示了系统执行在某一个时间点上一个可能的快照。对象图使用与类图相同的符号，只是在对象名下面加上下划线，同时它还显示了对象间的说有实例连接（link）关系。
10.内部结构图：展示了类的分解，给出了组成一个结构化类元的相互连接的部分、端口和连接器
11.协作图：展示了写作的定义，是一种合成的结构图
12.构件图：展示了系统中的给构件（即来自应用的软件单元），构件间通过接口的连接，以及构件之间的依赖关系
13.用况图：展示了各类外部执行者与系统所提供的用况之间的连接。一个用况是系统所提供的一个功能（也可以说是系统提供的某一特定用法）的描述，执行者是指那些可能使用这些用况的人或外部系统，执行者与用况的连接表示该执行者使用了那个用况
14.状态机图：通常是对类描述的补充，它说明该类的对象说有可能的状态以及哪些事件将导致状态的改变
15.活动图：展示了连续的活动流。活动图通常用来描述完成一个操作所需要的活动。活动图由动作状态组成，它包含完成一个动作的活动的规约
16顺序图：展示了几个对象之间的动态交互关系。它主要是用来显示对象之间发送消息的顺序，它还显示了对象之间的交互，即系统执行的某一特定点所发生的事
17.通信图：用几何排列来表示交互作用的角色，它显示了所有协作关系的复合结构组成部分或角色范围内的交互。它明确地显示元素之间的协作关系，而不显示作为独立维的时间，消息的顺序和并发线程必须由顺序号确定
18.部署图：展示了运行时处理结点和在结点上生存的制品的配置。结点是运算事的计算资源，制品是物理实体，如构件、文件。部署图中显示部署在结点上的制品和它们之间的关系，以及结点之间的连接和通信方式
19.包图：是由包和它们之间的关系组成的结构图
20.类图+对象图=静态图；状态机图+活动图=行为图；顺序图+协作图=交互图；部署图+构件图=实现图
21.创建用况模型的步骤包括：1）定义系统；2）确定执行者；3）确定用况；4）描述用况；5）定义用况间的关系；6）确认模型
22.用况图之间的关系：关联、扩展、包含、用况泛化
23.类—责任—协作者（CRC）技术。实际上是一组表示类的索引卡片，每张卡片分成三部分，它们分别描述类名、类的责任和类的协作者
24.标识属性：“+”：任何能看到这个类的类都能看到该属性；“#”：这个类或者它的任何子孙类都能看到该属性 ；“-”：只有这个类自身能看到该属性 “～”：在同一个包中的任何类能看到该属性
25.类之间的关系：关联、依赖、泛化、实现
26.关联的实例是链，链由对象元组组成，二元关联的链就是由一对对象组成的表
27.聚集：聚集是表示整体与部分关系的一种关联，图电脑与鼠标，协会与个人
28.组合：组合是一种更强形式的关联，代表整体的组合对象有管理它的部分对象的特有责任，如窗口与对话框，人体与器官
29.依赖关系用一个虚线箭头表示，箭头上可附加含关键字的版型，关键字用来指明依赖的种类。
30.约束是用自然语言或特定的形式语言正文表示的语义条件或限制，它用“｛正文字符串｝”形式表示。
31.派生：是一个元素与另一个元素之间的关系，前者能通过后者计算得到，计算派生元素的公式可以由约束给出，派生元素用元素名前加斜线（/）表示
32.画状态机图的步骤：
1）列出对象具有的所有状态：状态分为起始状态、结束状态和中间状态。一张状态机图可以有一个起始状态和若干个（可以为0）结束状态。
2）标识导致状态转换的事件：当一个对象接收到某个事件时，会导致从一个状态转换到另一个状态，称为状态迁移（transition）。
3）为状态和迁移定义状态变量和动作：在状态迁移和/或处于某个状态中时都可能需要执行一些相应的动作，综合这些动作，使得对象完成相应的功能。
33.一个状态由状态名、状态变量和活动三部分组成。
34.一个简单状态没有子结构，一个组合状态被分解成区域，每个区域中包含一或多个直接子状态。
35.一个非正交的组合状态可以拥有一或多个直接子状态，当该组合状态活跃时，该组合状态在同一时刻中只有一个子状态是活跃的
36.非正交状态（非并发）：一个包含一或多个直接子状态的组合状态，当该组合状态活跃时，在同一时刻组合状态中只有一个子状态是活跃的
37.简单状态：一个没有子结构的状态
38.正交状态（并发）：一个被分成多个区域的状态，当该状态活跃时，每个区域中的一个直接子状态并发地活跃
40.活动图使用状态机图的符号表示，活动图中的状态称为动作状态，用圆角矩形表示，动作状态之间的迁移用箭头表示，迁移上可以附加警戒条件、发送子句和动作表达式。与状态机图不同的是，活动图中动作状态之间的迁移不是靠事件触发的，当动作状态中的活动完成时迁移就被触发
41.一张活动图可划分成若干个矩形区，每个矩形区为一个泳道，泳道名放在矩形区的顶端
42.顺序图有两种形式：一般形式和实例形式
43.系统的体系结构用来描述系统各部分的结构、接口以及它们用于通信的机制。
物理体系结构涉及系统的详细描述，它显示了硬件的结构，包括不同的结点和这些结点之间如何连接，它还表示了代码模块的物理结构和依赖关系，并展示了对进程、程序、构件等软件在运行时的物理分配
44.物理体系结构应回答以下问题：
（1）类和对象物理上位于哪个程序或进程？
（2）程序和进程在哪台计算机上执行？
（3）系统中有哪些计算机和其它硬件设备？它们如何相互连接？
（4）不同的代码文件之间有什么依赖关系？如果一个指定的文件被改变，那么哪些其它文件要重新编译？
45.构件图显示构件类型的定义、内部结构和依赖。构件是系统设计的模块化部分，它给出一组外部的
接口，而隐藏了它的实现。在系统中满足相同接口的构件可以自由地替换
46.构件的接口有二种：
供应接口（provided interface）:供应接口声明该构件为其它请求者提供某种服务
请求接口（required interface）:请求接口声明该构件请求其它供应者为其提供某种服务，以完成其功能需求
47.部署图的基本元素有结点、连接、构件、对象、依赖等
48.制品是一个物理实现单元，如文件。可以用版型来区分不同种类的制品
第八章 基于构件的软件开发
1.Pressman书中的定义：构件是某系统中有价值的、几乎独立的并可替换的一个部分，它在良好定义的体系结构语境内满足某种清晰的功能
Brown的定义：构件是一个独立发布的功能部分，可以通过其接口访问它的服务
“计算机科学技术百科全书”的定义：软件构件是软件系统中具有相对独立功能，可以明确标识，接口由规约指定，与语境有明显依赖关系，可独立部署，且多由第三方提供的可组装软件实体；软件构件须承载有用的功能，并遵循某种构件模型；可复用构件是指具有可复用价值的构件
2.构件的要素：规格说明、一个或多个实现、受约束的构件标准、包装方法、部署方法
3.常用的构件标准：CORBA（公共对象请求代理体系结构）、COM+、EJB（一种基于Java的构件标准）
4.领域工程步骤：
• 领域分析：首先要进
行领域分析，收集领域中有
代表性的应用样本，分析应
用中的公共部分或相似部
分，抽取该领域的应用体系
结构
• 建立领域特定的基
准体系结构模型：在领域分
析的基础上，构造该领域的
基准体系结构，这个基准体
系结构应是可以裁剪和扩
充的，并可供该领域的应用
复用
• 标识候选构件：在领
域分析和领域基准体系结
构模型的基础上标识该领域的候选构件
• 泛化(generalization)和可变性(variability)分析：提高其通用性，同时寻找候选构件在不同应
用中的变化点(variation point)，通过设置参数、继承或其它手段，使可变部分局部化
• 重建构件：在泛化和可变性分析的基础上，重建构件，使它成为可复用构件
• 构件的测试：对重建的可复用的构件要严格测试，以提高其可靠性
• 构件的包装：经测试的构件应根据构件库的要求，对它进行包装，以便构件库对它分类储
存和检索
• 构件入库：包装后的构件即可存入构件库
5.应用系统工程的步骤：
• 建立应用系统的体系结构模型：可以使用构件生产者提供的领域特定的基准体系结构经裁
剪和/或扩充而获得
•
寻找候选构件：根据应用系统的体系结构模型，从构件库或其它可利用的构件源中寻找候
选构件
• 评价和选择合适的构件：评价候选构件以判断是否适合于待开发的软件
• 构件的修改(modify)和特化(specialize)：在复用时对构件进行特化以满足特定应用的需要
• 开发未被复用的部分：对新系统中未复用的部分进行开发
• 构件的组装：将特化和修改后的可复用构件和新开发的部分组装成一个新的软件系统
• 集成测试：对组装后的软件系统进行集成测试
• 评价被复用的构件，并推荐可能的新构件
6.构件的设计应具有较高的可复用程度；构件应易于调整和定制；构件应易于组装；构件必须具有可检索性；构件必须经过充分的测试
7.典型的可变型机制有：继承、扩展、参数化
8.大多数的构件分类模式可分为3类：枚举分类、刻面分类、属性值分类
第九章 人机界面设计
1.主要的可测的人性因素：用户时间、基准时间、基准出错率、任务出错率、学习能力、记忆能力、主观看法
2.人机界面设计过程：用户、任务和环境分析及建模；界面设计；界面构造；界面确认
3.人机界面设计中涉及的模型：软件工程师创建的设计模型；人机工程师创建的用户模型；终端用户在脑海里对界面产生的映象，称为用户的模型（user´s model）或系统感觉（system perception）；系统实现者创建的系统映象
4.界面设计过程可以按照以下方式进行
1）建立任务的目标和意图。
2）将每个目标或意图映射为一系列特定的动作。
3）按在界面上执行的方式说明这些动作的顺序。
4）指明系统状态，即执行动作时的界面表现。
5）定义控制机制，即用户可用的改变系统状态的设备和动作。
6）指明控制机制如何影响系统状态。
7）指明用户如何通过界面上的信息解释系统状态
5.人机界面设计的黄金原则：让用户拥有控制权；减少用户的记忆负担；保持界面一致
第十章 程序设计语言和编码
1.程序设计语言是指用于书写计算机程序的语言，它是一种实现性的软件语言。包括：语法、语意和语用
2.语法（syntax）用来表示构成语言的各个记号之间的组合规则，它是构成语言结构正确成分所需遵循的规则集合
3.语义（semantic）用来表示按照各种表示方式所表示的各个记号的特定含义，但它不涉及到使用者
4.语用（pragmatic）用来表示构成语言的各个记号和使用者的关系
5.影响程序员心理的语言特性有：一致性、二意性、紧致性、局部性、线性和传统性
6.在源程序中的内部文档主要包括：标识符的命名；注解；程序的视觉组织
7.标识符的命名：选择含义明确的名字，使其能正确提示标识符所代表的实体；名字不要太长，太长会增加打字量，且易出错。必要时可使用缩写；不用相似的名字，相似的名字容易混淆，不易发现错误；不用关键字作标识符；同一个名字不要有多个含义；名字中避免使用易混淆的字符
8.程序的注释包括以下内容：模块的功能；模块的接口；重要的局部变量；开发历史：包括模块的设计者、评审者、评审日期、修改日期以及对修改的描述
9.书写功能性注释时应注意的问题：
注释要正确，错误的注释比没有注释更坏；
为程序段作注释，而不是为每一个语句作注释；
用缩进和空行，使程序与注释容易区分；
注释应提供一些从程序本身难以得到的信息，而不是语句的重复。
10.通过在程序中添加一些空格、空行和缩进等技巧，可以帮助人们从视觉上看清程序的结构。常用的技巧规则如下：自然的程序段之间可用空行隔开；可通过添加空格使语句成分清晰；放置大括号，一般首选的方法是K&R方法：把左括号放在行尾，右括号放在行首
11.在交互式输入时，要在屏幕上使用提示符明确提示交互输入的请求，指明可使用选择项的种类和取值范围。同时，在数据输入的过程中和输入结束时，也要在屏幕上给出状态信息
第十一章 软件测试
“程序测试是证明程序正确地执行了预期的功能”。 1.有关软件测试的错误观点：“软件测试是为了证明程序是正确的，即测试能发现程序中所有的错误”，
2.白盒测试（又称为结构测试）：这种方法把测试对象看作一个透明的盒子，测试人员根据程序内部的逻辑结构及有关信息设计测试用例，检查程序中所有逻辑路径是否都按预定的要求正确地工作。主要用于对模块的测试
3.黑盒测试（又称行为测试）把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能需求。它可用于各种测试
4.常用的白盒测试方法有：逻辑覆盖测试、基本路径覆盖测试、数据流测试、循环测试
5.主要的逻辑覆盖测试标准有：语句覆盖、判定覆盖、条件覆盖、判定－条件覆盖、条件组合覆盖、路径覆盖
6.语句覆盖：是指选择足够的测试用例，使得运行这些测试用例时，被测程序的每个可执行语句都至少执行一次
7.判定覆盖（也称分支覆盖）是指选择足够的测试用例，使得运行这些测试用例时，被测程序的每个判定的所有可能结果都至少执行一次（即判定的每个分支至少经过一次）
8.条件覆盖是指选择足够的测试用例，使得运行这些测试用例时，被测程序的每个判定中的每个条件的所有可能结果都至少出现一次
9.判定/条件覆盖是指选择足够的测试用例，使得运行这些测试用例时，被测程序的每个判定的所有可能结果都至少执行一次，并且，每个判定中的每个条件的所有可能结果都至少出现一次
10.条件组合覆盖是指选择足够的测试用例，使得运行这些测试用例时，被测程序的每个判定中条件结果的所有可能组合都至少出现一次
11.路径覆盖是指选择足够的测试用例，使得运行这些测试用例时，被测程序的每条可能执行到的路径都至少经过一次（如果程序中包含环路，则要求每条环路至少经过一次）
12.主要的黑盒测试方法有：等价类划分、边界值分析、比较测试、错误猜测、因果图
13.看因果图实例:284页
14.测试策略的V模型：
15.单元测试的内容：模块接口、局部数据结构、边
界条件、独立路径、错误处理路径
16.自顶向下集成测
试：如右图：
深度优先测试次序：M1、
M2、M5、M8、M6、M3、
M7、M4
广度优先测试次序：M1、M2、M3、M4、M5、M6、M7、M8
17.α测试：是由一个用户在开发者的场所进行的，软件在开发者对用户的“指导下”进行测试。经α测试后的软件称为β版软件
18.β测试是由软件的最终用户在一个或多个用户场所进行，与α测试不同，开发者通常不在测试现场
19.常用的系统测试包括：
恢复测试安全测试：恢复测试是通过各种手段，强制软件发生故障，然后来验证系统能否在指定的时间间隔内恢复正常，包括修正错误并重新启动系统。如果恢复是由系统自身来完成的，那么，需验证重新初始化、检查点机制、数据恢复和重启动等的正确性。如果恢复需要人工干预，那么要估算平均修复时间MTTR（mean time to repair）是否在用户可以接受的范围内
安全测试：安全测试用来验证集成在系统中的保护机制能否实际保护系统不受非法侵入。
在安全测试过程中，测试者扮演一个试图攻击系统的角色，采用各种方式攻击系统。例如，截取或破译密码；借助特殊软件攻击系统；“制服”系统，使他人无法访问；故意导致系统失效，企图在系统恢复之机侵入系统；通过浏览非保密数据，从中找出进入系统的钥匙等等。一般来说，只要有足够的时间和资源，好的完全测试一定能最终侵入系统。系统设计者的任务是把系统设计成：攻破系统所付出的代价大于攻破系统后得到信息的价值
压力测试：压力测试也称强度测试，它是在一种需要非正常数量、频率或容量的方式下执行系统，其目的是检查系统对非正常情况的承受程度。例如：（1）当系统的中断频率是每秒1或2个时，执行每秒10个中断的测试用例；（2）将输入数据的数量提高一个数量级来测试输入功能如何响应；（3）执行需要最大内存或其它资源的测试用例；（4）执行可能导致大量磁盘驻留数据的测试用例
性能测试：性能测试用来测试软件在集成的系统中的运行性能。它对实时系统和嵌入式系统尤为重要。性能测试可以发生在测试过程的所有步骤中单元测试时，主要测试一个独立模块的性能，如算法的执行速度。软件集成后，进行软件整体的性能测试。计算机系统集成后，进行整个计算机系统的性能测试。性能测试常常需要与压力测试结合起来进行，而且常常需要一些硬件和软件测试设备，以监测系统的运行情况
20.由于面向对象软件把类作为面向对象软件的单元，传统的单元测试等价于面向对象中的类测试，也称类内测试。它包括类内的方法测试和类的行为测试
21.面向对象中的类间测试（interclass testing）相当于面向对象的集成测试。它有两种集成策略：基于线程的测试和基于使用的测试
22.执行测试用例错误时要进行调试，主要的调试方法有：蛮力法、回溯发、原因排除法
第十二章 Web工程
1.基于Web系统和应用（称为WebApp）的属性：网络集约 、并发、不可预测的登陆、性能、可用性、数据驱动、内容敏感、持续演化、数据库访问、数据仓库型
2.WebApp的开发具有如下特点：WebApp常常以增量的方式去开发；变化经常发生；期限较短
3.整个Web工程过程框架包括：客户交流、计划、建模、构建、部署。其中，计划，由一个任务定义和一个时间表组成
4.Web工程方法一般包括如下几种：沟通方法、需求分析方法、设计方法、测试方法
5.Web设计主要可分为：体系结构设计、导航设计、界面设计3个部分
6.一个良好的Web设计需要满足以下要求：设计要尽可能简单；布局要尽可能没换；整体的一致性
7.体系结构主要分为：线性结构、网格结构、层次结构3种
8.WEB工程自己的设计原则：页面速度；页面正确；所有的才打和界面的风格应该统一；链接指示应明显；界面功能明显清晰；通常都需要使用表格等工具
第十三章 软件维护与再工程
1.软件演化是指软件在交付以后，对软件进行的一系列活动的总称
2.软件演化包括：软件维护和软件再工程。其中软件维护阶段覆盖了从软件交付使用到软件被淘汰为止的整个时期。再工程的主要目的是为了遗留系统转化为可演化系统提供一条显示可行的途径
3.软件维护：是指软件系统交付使用以后，为了改正错误或满足新的需要而修改软件的过程
4.软件维护可以分为纠错性维护、适应性维护、改善性维护和预防性维护四类
• 纠错性维护：为了改正软件系统中的错误，使软件能够满足预期的正常运行状态的要求而
进行的维护
• 适应性维护：为了使软件适应内部或外部环境变化，而去修改软件的过程
• 改善性维护：满足使用过程中用户提出增加新功能或修改已有功能的建议维护
• 预防性维护：为了提高软件的可维护性、可靠性等，为以后进一步改进软件打下良好基础
而修改软件的活动
在几种维护活动中，改善性维护占的比重最大，来自用户要求扩充、加强软件功能、性能的维护活动中占整个维护工作的50%
5.和软件维护有关的部分问题：
（1）理解别人的代码通常是非常困难的，而且难度随着软件配置成分的缺失而迅速增加（2）需要维护的软件往往没有文档、或文档资料严重不足、或软件的变化未在相应的文档中反映出来（3）当软件要求维护时，不能指望由原来的开发人员来完成或提供软件的解释。由于维护持续时间很长，因此当需要解释软件时候，往往开发人员已经不在附近了（4）绝大多数软件在设计时没有考虑到将来的修改问题（5）软件维护这项工作毫无吸引力。一方面是因为软件维护，看不到什么“成果”，但工作量很大，更重要的是维护工作难度大，软件维护人员经常遭受挫折
6.软件维护活动包括：建立维护组织；确定维护过程；保管维护记录；进行维护评价
7.对软件可维护性影响的主要因素有：可理解性；可测试性；可修改性和可一致性
8.提高软件可维护性的方法：确定质量管理目标和优先级；规范化程序设计风格；选择可维护性高的程序设计语言；改进程序文档；保证软件质量审查方法
9.逆向工程（reverse engineering）：指在软件生存周期中，将软件的某种形式描述转换成更抽象形式的活动
重构（restructuring）：指在同一抽象级别上转换系统的描述形式。如把C++ 程序转换成Java程序 设计恢复（design recovery）：指借助工具从已有程序中抽象出有关数据结构设计、总体结构设计和过程设计的信息
再工程（reengineering）：指在逆向工程所获信息的基础上修改或重构已有的系统，产生系统的一个新版本
10.再工程的主要目的：为遗留系统转化为可演化系统提供一条现实可行的途径
11.通常再工程包含：业务过程再工程、软件再工程
12.业务过程再工程（BPR）：应该自顶向下进行，是迭代的，没有开始和结束，只有不断的演化，整个业务再工程模型如图P328
13.指导BRP活动的原则：围绕结果而不是任务进行组织；让那些使用过程结果的人来执行；将信息处理工作合并到生产原始信息的现实工作中；将地理分散的资源视为好像它们是集中的；连接并行的活动以代替集成它们的结果；在工作完成的地方设置决策点，并将控制加入过程中；在其源头一次性获取数据
14.软件再工程包含库存目录分析、文档重构、逆向工程、代码重构和数据重构以及正向工程。这一部分通常由软件工程师完成
15.逆向工程导出的信息可分为四个抽象层次：实现级、结构级、功能级、领域级
16.根据源程序的类别不同，逆向工程还可以分为：对用户界面的逆向工程、对数据的逆向工程和对理解的逆向工程
17.逆向工程中用于恢复信息的方法主要有四类：用户指导下的搜索与变换；变换方法；基于领域知识的方法；铅板恢复
第十四章 软件项目管理
1.项目管理是通过项目经理和项目组织的努力，运用系统理论的方法对项目及其资源进行计划、组织、协调、控制，旨在实现项目的特定目标的管理方法体系
2.(软件)项目管理的基本内容：项目定义、项目计划、项目执行、项目控制、项目结束
3.软件项目管理的关注点：
人员(People)：人员是软件工程项目的基本要素和关键因素在对人员进行组织时，有必要考虑参与软件过程(及每一个软件项目)的人员类型
产品(Product)：定义项目范围，其中包括建立产品的目的和范围、可选的解决方案、技术或管理的约束等
过程(Process)：通常将项目分解为任务—子任务等，其分解准则是基于软件工程的过程
项目(Project)：采用科学的方法及工具对项目基本内容进行管理
4.软件度量是指计算机软件范围内的测量，主要是为产品开发的软件过程和产品本身定义相关的测量方法和标度
5.需要考虑：合适的度量是什么；所收集的数据如何使用；用于比较个人、过程或产品的度量是否合理
6.度量对象：软件产品、软件过程、资源
7.软件度量有两种分类方法：第一种是将软件度量分为面向规模的度量、面向功能的度量和面向人的度量；第二种分类方法是软件度量分为生产率的度量、质量度量和技术度量。
8.功能点（FP）度量的5个信息域特征及其含义：
用户输入数：对每个用户输入进行计数，它们向软件提供不同的面向应用的数据
用户输出数：对每个用户输出进行计数，它们向用户提供不同的面型应用的信息
用户查询书：一个查询被定义为一个联机输入，它导致软件以联机输出的方式产生适时的响应。每个不同的查询都要计算
文件数：对每个逻辑上的主文件进行计算
外部接口数：对说有机器可读的接口进行计数，利用这些接口可以将信息从一个系统传到另一个系统
9.软件质量定义：
– ISO/IEC 9126《信息技术 软件产品质量评价 质量特性及其使用指南》中定义为：
与软件产品满足明确或隐含需求的能力有关的特征和特性的总和
– GB/T 13423《工业控制用软件评定准则》：软件产品中能满足给定需求的性质和
特性的总和，例如符合规格说明的程度；软件具有所期望的各种属性的组合程度；客户
或用户觉得软件满足其综合期望的程度；软件的综合特性，它确定软件在使用中将满足
客户预期要求的程度
10.McCall等人1987年提出一个包括软件质量要素、评价准则和度量3个层次的软件质量度量模型框架
11.软件质量的11个要素：正确性、可靠性、效率、完整性、可用性、可维护性、灵活性、可测试性、可移植性、可复用性、可互操作性
12.软件质量要素评价的21个准则：可审计性、准确性、通信机制通用性、完备性、简洁性、一致性、数据通用性、容错性、执行效率、可扩展性、通用性、硬件独立性、自检测性、模块性、可操作性、安全性、自文档性、简单性、软件系统独立性、可追踪性、易培训
13.ISO/IEC 9126质量模型：由质量特性、子特性和度量三个层次组成；第一层有6个质量特性；第二层有21个质量子特性；第三层是由度量者定义的可定量化度量指标
14.典型的程序复杂性度量：McCabe环形复杂性度量、Halstead的复杂性度量
15.Halstead认为程序是由操作符和操作数组成的符号序列。设n1为程序中不同操作符的个数，n2为程序中不同操作数的个数、N1为程序中操作符的总数、N2为程序中操作数的总数，则Halstead度量公式如下：
程序的符号长度：N = N1 + N2
程序的词汇量：n=n1+n2
程序量(指存储容量)：V=N log2 (n1 +n2)=(N1+ N2 ) log2 (n1 +n2)，习惯上，称该公式为长度方程 最小程序量：可以认为，最小的程序只有两个操作符：函数调用和赋值，即n1＝N1=2，而操作数n2*
就是赋于函数值的变量和函数调用时的参数，即n2*= n2= N2代入长度方程，可得最小程序量为：V*＝(2+n2*)log2(2+n2*)
预测程序长度：V*＝n1 log2 n1 +n2 log2 n2
预测程序潜在的错误数：B’=V/3000
16.软件可靠性通常用下列公式进行计算：
MTBF＝MTTF＋MTTR。其中：MTBF(mean time between failer)是平均故障间隔时间，MTTF(mean time to failer)是平均故障时间，MTTR(mean time to repair)是平均修复时间
17.软件可靠性估算：与软件可靠性密切相关的程序中残留错误数的估算和平均故障间隔时间的估算方法：错误植入法；分别测试法；软件平均故障间隔时间估算
18.指导软件项目进度安排的基本原则：划分、相互依赖性、时间分配、工作量确认、定义责任、定义结果、定义里程碑
19.根据软件工程过程的不同，可确定其相应的任务的工程量分配。常用的有40-20-40规则：在整个软件开发过程中，编码工作量仅占20%，编码前工作量占40%，编码后工作量占40%
20.甘特图：也称时间表(Timeline chart)，用来建立项目进度表，在甘特图中，每项任务的完成以必须交付的文档和通过评审为标准
21.用于软件开发的项目进度安排方法：计划评审技术和关键路径方法，它们是安排开发进度、制定软件开发计划的最常用的方法
22.风险：在给定情况下和特定时间内，那些可能发生的结果与预期结果之间的差异，差异越大，风险越大。
风险应该具备以下因素：事件、事件发生的概率、事件的影响、风险的原因
风险可表示成不确定和后果的函数：风险＝f(事件，不确定性，后果)
23.风险管理就是识别评估风险，建立、选择、管理和解决风险的可选方案和组织方法。包括了风险标识、风险预测、风险评估和风险管理与监控四个活动
24.风险可以分为：项目风险；技术风险和商业风险3类
25风险预测也称风险估算，风险预测.评价每种风险发生的可能性或概率以及当该风险发生时所导致的后果。以中间大的风险预测技术是建立风险表，风险表的第1列列出所有的风险，第2至4列列出每个风险的种类(项目风险、技术风险、商业风险等)、发生的概率以及所产生的影响
26.软件项目组织的组织原则有以下3条：尽早落实责任、减少交流接口、责权均衡
27.程序设计小组的组织形式有：主程序员制小组、民主制小组、层次式小组
28.人员配备的原则：重质量、重培训、双阶梯提升
29.技术评审的指导原则：
• 评审产品，而不是评审生产者
• 制定议事日程且遵守日程
• 限制争论和辨驳
• 对各个问题都发表见解，但不要试图解决所有记录的问题
• 做书面笔记
• 限制参与者人数并坚持事先做准备
• 为每个可能要评审的工作制品建立一个检查表
• 为正式技术评审分配资源和时间
• 对所有评审者进行有意义的培训
• 评审以前所做的评审
30.配置状态报告，也称为状态记录，它回答下列问题：发生了什么事；谁做的此事；此事是什么时候发生的；将影响别的什么
第一章 概论
1.在《计算机科学百科全书》中，对计算机软件作如下定义：计算机软件指计算机系统中的程序及其文档。程序是计算任务的处理对象和处理规则的描述，任何以计算机为处理工具的任务都是计算任务。处理对象是数据（如数据、文字、图形、图像、声音等，它们只是表示，而无含义）或信息（数据及有关的含义）。处理规则一般指处理的动作和步骤。程序必须装入计算机内才能工作。文档是为了便于了解程序所需的阐明性资料，文档一般是给人看的，不一定装入计算机。
2.软件的特点：（1）软件是一种逻辑实体，而不是有形的系统元件，其开发成本和进度难以准确地估算（2）软件是被开发的或被设计的，它没有明显的制造过程，一旦开发成功，只需复制即可，但其维护的工作量大（3）软件的使用没有硬件那样的机械磨损和老化问题
3.在《计算机百科全书》中，将软件分为系统软件、支撑软件、应用软件3类
4.设计性语言用来书写软件设计规约（design specification），典型的设计性语言有PDL语言（Program Design Language）。实现性语言是用来书写计算机程序的语言。
（1）按用户要求分：过程式语言和非过程式语言。过程式语言有FORTRAN、Java、C等。非过程式语言如PROLOG。
（2）按应用范围分：通用语言和专用语言：通用语言如FORTRAN、Java、C等，专用语言如自动数控程序APT。
（3）按使用方式分：交互式语言和非交互式语言，交互式语言如BASIC。非交互式语言如FORTRAN、COBOL。
（4）按成分性质分：顺序语言、并发语言、分布语言。顺序语言如FORTRAN、C。并发语言如Modula、Ada、并发Pascal。分布语言指考虑到分布计算要求的语言，如Modula。
5.软件工程定义：
（1）Fritz Bauer：软件工程是为了经济地获得可靠的和能在实际机器上高效运行的软件而建立和使用的好的工程原则
（2）软件工程是（1）将系统化的、规范的、可度量的方法应用于软件的开发、运行和维护的过程，即将工程化应用于软件中
（3）《计算机科学技术百科全书》：软件工程是应用计算机科学、数学及管理科学等原理，以工程化的原则和方法制作软件的工程
6.软件工程的框架可概括为：目标、过程、原则
7.软件生存周期大致分为如下6个阶段计算机系统工程、需求分析、设计、编码、测试、运行和维护
8.软件过程是生产一个最终满足需求且达到工程目标的软件产品所需的步骤。《计算机科学百科全书》中指出：软件过程是软件生存周期中的一系列相关的过程。过程是活动的集合，活动是任务的集合。
9.软件过程成熟度等级有5个：如右图所示————
10.成熟度等级表明了一个软件组织的过程能力的水
平。除初始级外，每个成熟度等级都包含若干个关键过程
域（Key Process Area，简称KPA）。CMM提供了18个关
键过程域，每个关键过程域都有一组对改进过程能力非常
重要的目标，并确定了一组相应的关键实践，关键实践描
述了建立一个过程能力必须完成的活动和必须具备的基础
设施，完成了这些关键实践就达到了相应关键过程域的目
标，该关键过程域也就得到了满足。每个关键过程域的关
键实践都是按照五个共同特性（执行约定，执行能力，执行活动，测量和分析，验证实现）进行组织的，主要解决关键实践的实施或制度化问题。
11.CMMI模型为每个学科的组合都提供两种表示法：阶段式模型和连续式模型
12.瀑布模型的特征：（1）接受上一阶段的结果作为本阶段的输入（2
）利用这一输入实施本阶段应完
成的活动（3）对本阶段的工作进行评审（4）将本阶段的结果作为输出，传递给下一阶段
13.原型：为了减少因为对需求的了解不确切而给
软件开发带来的风险，可以在获取了一组基本的需求
后，通过快速分析，而构造处的关于该软件的一个初
始可运行版本。
14.原型模型根据使用原型的目的不同分为：探索
型、实验型、演化型
15.螺旋模型沿着螺线自内向外旋转，在四个象限
上分别表达四个方面的任务，即：（1）制定计划：确
定软件目标，选定实施方案，弄清项目开发的限制条
件（2）风险分析：评价所选的方案，识别风险，消除风险（3）工程实施：实施软件开发，验证工作产品
（4）客户评估：评价开发工作，提出修正建议
16.喷泉模型
“喷泉”一词体现了面向对象方法的迭代和无间隙特性，迭代是指各开发
活动需要多次重复，无间隙是指开发活动之间不存在明显的边界。
17.敏捷软件开发的价值观：（1）个人和交互高于过程和工具（2）可运行
软件高于详尽的文档（3）与客户协作高于合同（契约）谈判（4）对变更及时
做出反应高于遵循计划
18.（1）最优先的是通过尽早地和不断地提交有价值的软件使客户满意（2）
欢迎变化的需求，即使该变化出现在开发的后期，为了提升对客户的竞争优势，
Agile过程利用变化作为动力（3）以几周到几个月为周期，尽快、不断地发布
可运行软件（4）在整个项目过程中，业务人员和开发人员必须天天一起工作（5）以积极向上的员工为中心建立项目组，给予他们所需的环境和支持，对他们的工作予以充分的信任（6）项目组内效率最高、最有效的信息传递方式是面对面的交流（7）测量项目进展的首要依据是可运行的软件（8）敏捷过程提倡可持续的开发，项目发起者、开发者和用户应能长期保持恒定的速度（9） 应时刻关注技术上的精益求精和好的设计，以增强敏捷性（10）简单化是必不可少的，这是尽可能减少不必要工作的艺术（11）最好的构架、需求和设计出自于自我组织的团队（12）团队要定期反思怎样才能更有效，并据此调整自己的行为
19.XP方法称为极限编程。XP方法由Kent Beck提出，适用于软件需求模糊且挥发性强、开发团队人数在10人以下、开发地点集中的场合
XP方法的4个价值观：交流、简单、反馈、勇气
XP方法的12各核心实践：完整的团队、计划对策、系统比喻、小发布、测试、简单设计、结对编程、设计改进、持续集成、代码全体共有、编码标准、可持续步调
20.XP方法的开发过程：（1）探索阶段：主要工作是开发初始的用户故事和体系结构骨架（2）计划阶段：是根据用户故事描述的需求、系统体系结构骨架和系统比喻来制订迭代计划和发布计划（3）迭代到发布阶段：根据迭代和发布计划，开发满足指定用户故事需求的软件，并与前面已完成的软件版本集成，得到软件的一个新版本（4）产品化阶段：主要工作是确认迭代开发的软件已经做好进入产品化的准备。可能要写的文档：系统文档、操作文档、支持文档、用户文档、维护阶段
第二章 系统工程
1.基于计算机的系统是指：通过处理信息来完成某些预定义目标而组织在一起的元素的集合或排列。组成基于计算机系统的元素主要有：软件、硬件、人员、数据库、文档和规程
2.系统工程的任务：（1）识别用户的要求（2）系统建模和模拟：包括硬件系统模型、软件系统模型、人机接口模型、数据模型；（3）成本估算及进度安排（4）可行性分析（5）生成系统规格说明
3.可行性分析考虑：成本、效益、货币的时间价值、投资回收期、纯收入
技术可行性分析包括：风险分析、资源分析、技术分析
法律可行性分析：1990年我国颁布了《中华人民共和国著作权法》，1991年国务院颁布了《计算机软件保护条例》
方案的选择和折衷：由于系统的功能和性能受到多种因素的影响，某些因素之间相互关联和制约。在必要时应进行折衷
第三章 需求工程
1.将软件需求工程细分为：需求获取、需求分析与协商、系统建模、需求规约、需求验证和需求管理六个阶段
2.软件需求的具体内容包括：功能需求、性能需求、用户或人的因素、环境需求、界面需求、文档需求、数据需求、资源使用需求、安全保密要求、可靠性需求、软件成本消耗与开发进度需求、其他非功能性要求
3.需求获取方法与策略：建立顺畅通信途径、访谈与调查、观察用户操作流程、组成联合小组、用况
4.信息域包括：信息内容、信息流以及信息结构
5.需求规约包括：引言、信息描述、功能描述、行为描述、检验描述、参考书目、附录
6.需求验证目的是要检验需求是否能够反映用户的意愿。评审人员评审时往往需要检查以下内容：
（1）系统定义的目标是否与用户的要求一致
（2）系统需求分析阶段提供的文档资料是否齐全；文档的描述是否完整、清晰、准确反映用户要求
（3）被开发项目的数据流与数据结构是否确定且充足
（4）主要功能是否已包括在规定的软件范围之内，是否都已充分说明
（5）设计的约束条件或限制条件是否符合实际
（6）开发的技术风险是什么
（7）是否详细制定了检验标准，它们能否对系统定义是否成功进行确认
第四章 设计工程
1.软件设计开始于软件需求的分析和规约之后，位于软件工程过程中的技术核心位置，是把需求转化为软件系统的最重要环节
2.软件设计是把软件需求变换成软件表示的过程，它主要包含两个阶段：软件体系结构设计阶段和部件级设计，前者也被称为概要设计，后者被称为详细设计。软件体系结构设计将软件需求转化为数据结构和软件的系统结构。部件级设计将软件体系结构性元素转化为软件部件的过程性描述，得到软件详细的数据结构和算法。
3.软件设计原则：抽象、逐步求精、模块化、信息隐藏
4.模块的独立性可以由两项指标来衡量：内聚度与耦合度。内聚度衡量一个模块内部各个元素彼此结合的紧密程度，耦合度衡量不同模块之间相互依赖的紧密程度
5.内聚：是一个模块内部各个元素彼此结合的紧密程度的度量。内聚可以分为以下7中类型：
1）巧合内聚（偶然内聚）：将几个模块中没有明确表现出独立功能的相同程序代码段独立出来建立的模块称为巧合内聚模块
2）逻辑内聚 ：指完成一组逻辑相关任务的模块，调用该模块时，由传送给模块的控制型参数来确定该模块应执行哪一种功能
3）时间内聚：指一个模块中的所有任务必须在同一时间段内执行。例如初始化模块和终止模块
4）过程内聚 ：指一个模块完成多个任务，这些任务必须按指定的过程（procedural）执行
5）通信内聚 ：指一个模块内所有处理元素都集中在某个数据结构的一块区域中
6）顺序内聚：指一个模块完成多个功能，这些功能又必须顺序执行
7）功能内聚 ：指一个模块中各个部分都是为完成一项具体功能而协同工作，紧密联系，不可分割的
6.耦合：是模块之间的相对独立性的度量。耦合取决于各个模块之间接口的复杂程度、调用模块的方式以及通过接口的信息类型。耦合方式有其中类型：
1）内容耦合 ：如果一个模块直接访问另一个模块的内部数据；或者一个模块不通过正常入口转到另
一模块内部；或者两个模块有一部分程序代码重迭；或者一个模块有多个入口，则两个模块之间就发生了内容耦合
2）公共耦合 ：若一组模块都访问同一个公共数据环境，则它们之间的耦合就称为公共耦合。公共的数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等
3）外部耦合 ：指模块间通过软件之外的环境联结（如I/O将模块耦合到特定的设备、格式、通信协议上）时，称为外部耦合
4）控制耦合：如果一个模块传送给另一个模块的参数中包含了控制信息，该控制信息用于控制接收模块中的执行逻辑，则称为控制耦合
5）标记耦合：两个模块之间通过参数表传递一个数据结构的一部分（如某一数据结构的子结构），就是标记耦合
6）数据耦合：两个模块之间仅通过参数表传递简单数据，则称为数据耦合
7）非直接耦合 ：如果两个模块之间没有直接关系，即它们中的任何一个都不依赖于另一个而能独立工作，这种耦合称为非直接耦合
7.耦合与内聚都是模块独立性的定性指标，都反映了模块独立性的良好程度。但耦合是直接的主导因素，内聚则辅助耦合共同对模块独立性进行衡量
8.当人们提到软件的体系结构会考虑到软件是单主机结构、客户/服务器结构还是浏览器/服务器结构
9.软件体系结构的风格，每种风格描述一种系统范畴，范畴包括：
①一些实现系统所需的功能的部件（如数据库、计算模块）
②一组用来连接部件“通信、协调和合作”的“连接件”
③定义部件之间怎样整合的系统约束
④使设计者能够理解整个系统属性并分析已知属性的语义模型
10.数据为中心体系结构，在这种体系结构中，一些数据（比如一个文件或者数据库）保存在整个结构的中心，并且被其他部件频繁地使用、添加、删除、或者修改。在一些情况下客户端部件独立于对数据的任何改变或其他客户部件的动作而访问数据，折衷方法的一个变种是将存储中心变换为“黑板”，当客户感兴趣的数据变化时，由黑板向客户端部件发送通知。在这种结构中，现有的客户端部件可以被修改，而且新的数据可以被方便的加入系统而无需考虑其他客户
11.数据流风格的体系结构，这种结构适用于输入数据被一系列的计算或者处理部件变换成输出数据。这种结构由管道和过滤器组成。过滤器之间由传送数据的管道联通。每个过滤器在上下管道间独立工作，被设计成某种特定形式的预期数据输入，并产生数据输出。但是，过滤器并不需要知道相邻其他过滤器是如何工作的
12.调用和返回风格的体系结构，这种风格使一个软件设计者设计出非常容易修改和扩充的体系结构。包含：主程序/子程序风格体系结构和远程过程调用风格的体系结构。其中，主程序/子程序风格体系结构：面向结构化分析与设计方法中，把功能分解为控制层次，体系结构反映系统中模块的相互调用关系：顶层模块调用它的下层模块以实现程序的完整功能，每个下层模块再调用更下层的模块，最下层的模块完成最具体的功能。远程过程调用风格的体系结构是主程序/子程序风格体系结构的扩展，再这种结构中被主程序调用的部件被分布在网络上不同的计算机中
13.面向对象风格的体系结构：系统部件封装数据和操作数据的方法。部件之间的交互和协调通过消息来传递
14.层次式风格的体系结构：在这种结构中，定义不同的层次，每层都完成了相对外层更靠近机器指令的操作。再最外面的层中，部件向用户提供接口操作。在最内不的层中，部件使用系统接口。每个中间层都是对内层接口的封装
15.部件级设计技术：部件在不同的分析设计方法中对应不同的名称。在结构化分析和设计方法时部件往往被称为模块。在面向对象分析和设计时部件被称为类：在基于构件的开发方法中，部件被称为构件。
第五章 结构化分析与设计
1.结构化分析过程分为以下4个步骤：（1）理解当前的现实环境，获得当前系统的具体模型(物理模型)
（2）从当前系统的具体模型抽象出当前系统的逻辑模型（3）分析目标系统与当前系统逻辑上的差别，建立目标系统的逻辑模型（4）为目标系统的逻辑模型作补充
2.数据流图（DFD）：描述输入数据流到输出数据流的变换（即加工）过程，用于对系统的功能建模
3.数据流图的基本图形元素包括：数据流、加工、文件、源和缩
4.值得注意的是：在数据流图DFD中描述的是数据流，而不是控制流
5.数据流图的扩充符号：星号(＊)：表示数据流之间存在“与”关系；加号(＋)：表示数据流之间存在“或”关系；异或(⊕)：表示数据流之间存在“异或”(互斥)关系
6.分层数据流图的完整性包括以下4个方面：（1）每个加工至少有一个输入数据流和一个输出数据流
（2）在整套分层数据流中，每个文件应至少有一个加工读该文件，有另一个加工写该文件（3）分层数据流图中的每个数据流和文件都必须命名(除了流入或流出文件的数据流)，并保持与数据字典的一致 （4）分层DFD中的每个基本加工(即不再分解子图的加工)都应有一个加工规约
7.构造分层数据流图DFD时需注意的问题：适当命名；化数据流而不是画控制流；避免一个加工有过多的数据流；分解尽可能均匀；先考虑稳定状态，忽略琐碎的枝节；随时准备重画
8.在自顶向下画数据流图时，可参照以下几条与分解有关的原则：7加减2；分解应自然，概念上合理、清晰；只要不影响DFD的易理解性，可适当多分解几个加工，以减少层数；一般说来，上层分解得快些(即多分解几个加工)，下层分解得慢些(即少分解几个加工)；分解要均匀
9.数据字典，字典条目分为：数据流、文件、数据项（组成数据流和文件的数据）、加工、源和宿
10.判断表的组成：条件桩、条件条目、动作桩、动作条目
11.结构图的基本成分有：模块、调用和数据
12.结构图的几个概念：
深度：程序结构图中控制的层数
宽度：程序结构图中同一层次上模块总数的最大值
扇出：该模块直接调用的模块数目
深度和宽度在一定程度上反映了程序的规模和复杂程度。相对而言，如果程序结构图的深度和宽度较大，则说明程序的规模和复杂程度都较大。模块的扇入扇出会影响结构图的深度和宽度，例如减少模块的扇出，可能导致宽度变小而深度增加。一个模块的扇出过大通常意味着该模块比较复杂，然而扇出太少，可能导致深度的增加。一般情况，一个模块的扇出以3～9为宜。一个模块的扇入表示有多少模块可直接调用它，它反映了该模块的复用(reuse)程度，因此模块的扇入越大越好
13.为了有效的模块化，给出以下启发式设计策略：
（1）改造程序结构图，降低耦合度，提高内聚度
（2）避免高扇出，并随着深度的增加，力求高扇入
（3）模块的影响范围应限制在该模块的控制范围内
（4）降低模块接口的复杂程度和冗余程度，提高一致性
（5）模块的功能应是可预测的，避免对模块施加过多的限制
（6）尽可能设计单入口和单出口的模块
14.通常，一个模块的大小以50—100行程序代码为宜，即一个模块的程序代码可写在1—2页纸上
15.结构化程序设计是将结构画分析的结果（数据流图）映射成软件的体系结构（结构图）。根据信息流的特点，可将数据流图分为变换型数据流图和事务型数据流图，对应的映射分别为变换分析和事务分析
16.信息流可分为变换流和事务流
第六章 面向数据结构的分析与设计
1.面向数据结构的需求分析与设计方法，其典型方法有：Jackson方法和Warnier方法。这类方法有如下特点：（1）以信息对象及其操作为核心进行需求分析（2）认为复合信息对象具有层次结构，并且可按顺序、选择、重复三种结构分解为成员信息对象（3）提供由层次信息结构映射为程序结构的机制，从
而为软件设计奠定良好的基础
2.面向数据的分析和设计方法是以数据结构为中心，从输入/输出的数据结构到处程序结构
1. 第七章 面向对象的分析与设计 面向对象 = 对象+ 分类+ 继承+ 通过消息的通信
2.重载：父类中定义了其所有子类的公共属性和操作，在子类中除了定义自己特有的属性和操作外，还可以对父类（或祖先类）中的操作重新定义其实现方法
3.多态性：是指同一个操作作用于不同的对象上可以有不同的解释，并产生不同的执行结果
4.动态绑定：是指在程序运行时才将消息所请求的操作与实现该操作的方法连接起来
5.面向对象分析的一般步骤如下：（1）获取客户对系统的需求：包括标识场景和用况，以及建造需求模型；（2）用基本的需求为指南，来选择类和对象（包括属性和操作）；（3）定义类的结构和层次；（4）建造对象—关系模型；（5）建造对象—行为模型；（6）利用用况/场景来复审分析模型
6.面向对象设计（OOD）的一般步骤如下：（1）系统设计：将子系统分配到处理器；选择实现数据管理、界面支持和任务管理的设计策略；为系统设计合适的控制机制；复审并考虑权衡（折衷）。（2）对象设计：在过程级别（procedural lavel）设计每个操作，定义内部类；为类属性设计内部数据结构。（3）消息设计：使用对象间的协作和对象--关系模型，设计消息模型（4）复审设计模型并在需要是迭代
7.UML的组成：基本构造块、组织构造块的规则、运用于整个UML的公共机制
8.类图：展示了系统中类的静态结构，即类与类之间的相互联系。类之间有多种联系方式，如关联（相互连接）、依赖（一个类依赖或使用另一个类）、泛化（一个类是另一类的特殊情况）等。
9.对象图：是类图的实例，它展示了系统执行在某一个时间点上一个可能的快照。对象图使用与类图相同的符号，只是在对象名下面加上下划线，同时它还显示了对象间的说有实例连接（link）关系。
10.内部结构图：展示了类的分解，给出了组成一个结构化类元的相互连接的部分、端口和连接器
11.协作图：展示了写作的定义，是一种合成的结构图
12.构件图：展示了系统中的给构件（即来自应用的软件单元），构件间通过接口的连接，以及构件之间的依赖关系
13.用况图：展示了各类外部执行者与系统所提供的用况之间的连接。一个用况是系统所提供的一个功能（也可以说是系统提供的某一特定用法）的描述，执行者是指那些可能使用这些用况的人或外部系统，执行者与用况的连接表示该执行者使用了那个用况
14.状态机图：通常是对类描述的补充，它说明该类的对象说有可能的状态以及哪些事件将导致状态的改变
15.活动图：展示了连续的活动流。活动图通常用来描述完成一个操作所需要的活动。活动图由动作状态组成，它包含完成一个动作的活动的规约
16顺序图：展示了几个对象之间的动态交互关系。它主要是用来显示对象之间发送消息的顺序，它还显示了对象之间的交互，即系统执行的某一特定点所发生的事
17.通信图：用几何排列来表示交互作用的角色，它显示了所有协作关系的复合结构组成部分或角色范围内的交互。它明确地显示元素之间的协作关系，而不显示作为独立维的时间，消息的顺序和并发线程必须由顺序号确定
18.部署图：展示了运行时处理结点和在结点上生存的制品的配置。结点是运算事的计算资源，制品是物理实体，如构件、文件。部署图中显示部署在结点上的制品和它们之间的关系，以及结点之间的连接和通信方式
19.包图：是由包和它们之间的关系组成的结构图
20.类图+对象图=静态图；状态机图+活动图=行为图；顺序图+协作图=交互图；部署图+构件图=实现图
21.创建用况模型的步骤包括：1）定义系统；2）确定执行者；3）确定用况；4）描述用况；5）定义用况间的关系；6）确认模型
22.用况图之间的关系：关联、扩展、包含、用况泛化
23.类—责任—协作者（CRC）技术。实际上是一组表示类的索引卡片，每张卡片分成三部分，它们分别描述类名、类的责任和类的协作者
24.标识属性：“+”：任何能看到这个类的类都能看到该属性；“#”：这个类或者它的任何子孙类都能看到该属性 ；“-”：只有这个类自身能看到该属性 “～”：在同一个包中的任何类能看到该属性
25.类之间的关系：关联、依赖、泛化、实现
26.关联的实例是链，链由对象元组组成，二元关联的链就是由一对对象组成的表
27.聚集：聚集是表示整体与部分关系的一种关联，图电脑与鼠标，协会与个人
28.组合：组合是一种更强形式的关联，代表整体的组合对象有管理它的部分对象的特有责任，如窗口与对话框，人体与器官
29.依赖关系用一个虚线箭头表示，箭头上可附加含关键字的版型，关键字用来指明依赖的种类。
30.约束是用自然语言或特定的形式语言正文表示的语义条件或限制，它用“｛正文字符串｝”形式表示。
31.派生：是一个元素与另一个元素之间的关系，前者能通过后者计算得到，计算派生元素的公式可以由约束给出，派生元素用元素名前加斜线（/）表示
32.画状态机图的步骤：
1）列出对象具有的所有状态：状态分为起始状态、结束状态和中间状态。一张状态机图可以有一个起始状态和若干个（可以为0）结束状态。
2）标识导致状态转换的事件：当一个对象接收到某个事件时，会导致从一个状态转换到另一个状态，称为状态迁移（transition）。
3）为状态和迁移定义状态变量和动作：在状态迁移和/或处于某个状态中时都可能需要执行一些相应的动作，综合这些动作，使得对象完成相应的功能。
33.一个状态由状态名、状态变量和活动三部分组成。
34.一个简单状态没有子结构，一个组合状态被分解成区域，每个区域中包含一或多个直接子状态。
35.一个非正交的组合状态可以拥有一或多个直接子状态，当该组合状态活跃时，该组合状态在同一时刻中只有一个子状态是活跃的
36.非正交状态（非并发）：一个包含一或多个直接子状态的组合状态，当该组合状态活跃时，在同一时刻组合状态中只有一个子状态是活跃的
37.简单状态：一个没有子结构的状态
38.正交状态（并发）：一个被分成多个区域的状态，当该状态活跃时，每个区域中的一个直接子状态并发地活跃
40.活动图使用状态机图的符号表示，活动图中的状态称为动作状态，用圆角矩形表示，动作状态之间的迁移用箭头表示，迁移上可以附加警戒条件、发送子句和动作表达式。与状态机图不同的是，活动图中动作状态之间的迁移不是靠事件触发的，当动作状态中的活动完成时迁移就被触发
41.一张活动图可划分成若干个矩形区，每个矩形区为一个泳道，泳道名放在矩形区的顶端
42.顺序图有两种形式：一般形式和实例形式
43.系统的体系结构用来描述系统各部分的结构、接口以及它们用于通信的机制。
物理体系结构涉及系统的详细描述，它显示了硬件的结构，包括不同的结点和这些结点之间如何连接，它还表示了代码模块的物理结构和依赖关系，并展示了对进程、程序、构件等软件在运行时的物理分配
44.物理体系结构应回答以下问题：
（1）类和对象物理上位于哪个程序或进程？
（2）程序和进程在哪台计算机上执行？
（3）系统中有哪些计算机和其它硬件设备？它们如何相互连接？
（4）不同的代码文件之间有什么依赖关系？如果一个指定的文件被改变，那么哪些其它文件要重新编译？
45.构件图显示构件类型的定义、内部结构和依赖。构件是系统设计的模块化部分，它给出一组外部的
接口，而隐藏了它的实现。在系统中满足相同接口的构件可以自由地替换
46.构件的接口有二种：
供应接口（provided interface）:供应接口声明该构件为其它请求者提供某种服务
请求接口（required interface）:请求接口声明该构件请求其它供应者为其提供某种服务，以完成其功能需求
47.部署图的基本元素有结点、连接、构件、对象、依赖等
48.制品是一个物理实现单元，如文件。可以用版型来区分不同种类的制品
第八章 基于构件的软件开发
1.Pressman书中的定义：构件是某系统中有价值的、几乎独立的并可替换的一个部分，它在良好定义的体系结构语境内满足某种清晰的功能
Brown的定义：构件是一个独立发布的功能部分，可以通过其接口访问它的服务
“计算机科学技术百科全书”的定义：软件构件是软件系统中具有相对独立功能，可以明确标识，接口由规约指定，与语境有明显依赖关系，可独立部署，且多由第三方提供的可组装软件实体；软件构件须承载有用的功能，并遵循某种构件模型；可复用构件是指具有可复用价值的构件
2.构件的要素：规格说明、一个或多个实现、受约束的构件标准、包装方法、部署方法
3.常用的构件标准：CORBA（公共对象请求代理体系结构）、COM+、EJB（一种基于Java的构件标准）
4.领域工程步骤：
• 领域分析：首先要进
行领域分析，收集领域中有
代表性的应用样本，分析应
用中的公共部分或相似部
分，抽取该领域的应用体系
结构
• 建立领域特定的基
准体系结构模型：在领域分
析的基础上，构造该领域的
基准体系结构，这个基准体
系结构应是可以裁剪和扩
充的，并可供该领域的应用
复用
• 标识候选构件：在领
域分析和领域基准体系结
构模型的基础上标识该领域的候选构件
• 泛化(generalization)和可变性(variability)分析：提高其通用性，同时寻找候选构件在不同应
用中的变化点(variation point)，通过设置参数、继承或其它手段，使可变部分局部化
• 重建构件：在泛化和可变性分析的基础上，重建构件，使它成为可复用构件
• 构件的测试：对重建的可复用的构件要严格测试，以提高其可靠性
• 构件的包装：经测试的构件应根据构件库的要求，对它进行包装，以便构件库对它分类储
存和检索
• 构件入库：包装后的构件即可存入构件库
5.应用系统工程的步骤：
• 建立应用系统的体系结构模型：可以使用构件生产者提供的领域特定的基准体系结构经裁
剪和/或扩充而获得
•
寻找候选构件：根据应用系统的体系结构模型，从构件库或其它可利用的构件源中寻找候
选构件
• 评价和选择合适的构件：评价候选构件以判断是否适合于待开发的软件
• 构件的修改(modify)和特化(specialize)：在复用时对构件进行特化以满足特定应用的需要
• 开发未被复用的部分：对新系统中未复用的部分进行开发
• 构件的组装：将特化和修改后的可复用构件和新开发的部分组装成一个新的软件系统
• 集成测试：对组装后的软件系统进行集成测试
• 评价被复用的构件，并推荐可能的新构件
6.构件的设计应具有较高的可复用程度；构件应易于调整和定制；构件应易于组装；构件必须具有可检索性；构件必须经过充分的测试
7.典型的可变型机制有：继承、扩展、参数化
8.大多数的构件分类模式可分为3类：枚举分类、刻面分类、属性值分类
第九章 人机界面设计
1.主要的可测的人性因素：用户时间、基准时间、基准出错率、任务出错率、学习能力、记忆能力、主观看法
2.人机界面设计过程：用户、任务和环境分析及建模；界面设计；界面构造；界面确认
3.人机界面设计中涉及的模型：软件工程师创建的设计模型；人机工程师创建的用户模型；终端用户在脑海里对界面产生的映象，称为用户的模型（user´s model）或系统感觉（system perception）；系统实现者创建的系统映象
4.界面设计过程可以按照以下方式进行
1）建立任务的目标和意图。
2）将每个目标或意图映射为一系列特定的动作。
3）按在界面上执行的方式说明这些动作的顺序。
4）指明系统状态，即执行动作时的界面表现。
5）定义控制机制，即用户可用的改变系统状态的设备和动作。
6）指明控制机制如何影响系统状态。
7）指明用户如何通过界面上的信息解释系统状态
5.人机界面设计的黄金原则：让用户拥有控制权；减少用户的记忆负担；保持界面一致
第十章 程序设计语言和编码
1.程序设计语言是指用于书写计算机程序的语言，它是一种实现性的软件语言。包括：语法、语意和语用
2.语法（syntax）用来表示构成语言的各个记号之间的组合规则，它是构成语言结构正确成分所需遵循的规则集合
3.语义（semantic）用来表示按照各种表示方式所表示的各个记号的特定含义，但它不涉及到使用者
4.语用（pragmatic）用来表示构成语言的各个记号和使用者的关系
5.影响程序员心理的语言特性有：一致性、二意性、紧致性、局部性、线性和传统性
6.在源程序中的内部文档主要包括：标识符的命名；注解；程序的视觉组织
7.标识符的命名：选择含义明确的名字，使其能正确提示标识符所代表的实体；名字不要太长，太长会增加打字量，且易出错。必要时可使用缩写；不用相似的名字，相似的名字容易混淆，不易发现错误；不用关键字作标识符；同一个名字不要有多个含义；名字中避免使用易混淆的字符
8.程序的注释包括以下内容：模块的功能；模块的接口；重要的局部变量；开发历史：包括模块的设计者、评审者、评审日期、修改日期以及对修改的描述
9.书写功能性注释时应注意的问题：
注释要正确，错误的注释比没有注释更坏；
为程序段作注释，而不是为每一个语句作注释；
用缩进和空行，使程序与注释容易区分；
注释应提供一些从程序本身难以得到的信息，而不是语句的重复。
10.通过在程序中添加一些空格、空行和缩进等技巧，可以帮助人们从视觉上看清程序的结构。常用的技巧规则如下：自然的程序段之间可用空行隔开；可通过添加空格使语句成分清晰；放置大括号，一般首选的方法是K&R方法：把左括号放在行尾，右括号放在行首
11.在交互式输入时，要在屏幕上使用提示符明确提示交互输入的请求，指明可使用选择项的种类和取值范围。同时，在数据输入的过程中和输入结束时，也要在屏幕上给出状态信息
第十一章 软件测试
“程序测试是证明程序正确地执行了预期的功能”。 1.有关软件测试的错误观点：“软件测试是为了证明程序是正确的，即测试能发现程序中所有的错误”，
2.白盒测试（又称为结构测试）：这种方法把测试对象看作一个透明的盒子，测试人员根据程序内部的逻辑结构及有关信息设计测试用例，检查程序中所有逻辑路径是否都按预定的要求正确地工作。主要用于对模块的测试
3.黑盒测试（又称行为测试）把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能需求。它可用于各种测试
4.常用的白盒测试方法有：逻辑覆盖测试、基本路径覆盖测试、数据流测试、循环测试
5.主要的逻辑覆盖测试标准有：语句覆盖、判定覆盖、条件覆盖、判定－条件覆盖、条件组合覆盖、路径覆盖
6.语句覆盖：是指选择足够的测试用例，使得运行这些测试用例时，被测程序的每个可执行语句都至少执行一次
7.判定覆盖（也称分支覆盖）是指选择足够的测试用例，使得运行这些测试用例时，被测程序的每个判定的所有可能结果都至少执行一次（即判定的每个分支至少经过一次）
8.条件覆盖是指选择足够的测试用例，使得运行这些测试用例时，被测程序的每个判定中的每个条件的所有可能结果都至少出现一次
9.判定/条件覆盖是指选择足够的测试用例，使得运行这些测试用例时，被测程序的每个判定的所有可能结果都至少执行一次，并且，每个判定中的每个条件的所有可能结果都至少出现一次
10.条件组合覆盖是指选择足够的测试用例，使得运行这些测试用例时，被测程序的每个判定中条件结果的所有可能组合都至少出现一次
11.路径覆盖是指选择足够的测试用例，使得运行这些测试用例时，被测程序的每条可能执行到的路径都至少经过一次（如果程序中包含环路，则要求每条环路至少经过一次）
12.主要的黑盒测试方法有：等价类划分、边界值分析、比较测试、错误猜测、因果图
13.看因果图实例:284页
14.测试策略的V模型：
15.单元测试的内容：模块接口、局部数据结构、边
界条件、独立路径、错误处理路径
16.自顶向下集成测
试：如右图：
深度优先测试次序：M1、
M2、M5、M8、M6、M3、
M7、M4
广度优先测试次序：M1、M2、M3、M4、M5、M6、M7、M8
17.α测试：是由一个用户在开发者的场所进行的，软件在开发者对用户的“指导下”进行测试。经α测试后的软件称为β版软件
18.β测试是由软件的最终用户在一个或多个用户场所进行，与α测试不同，开发者通常不在测试现场
19.常用的系统测试包括：
恢复测试安全测试：恢复测试是通过各种手段，强制软件发生故障，然后来验证系统能否在指定的时间间隔内恢复正常，包括修正错误并重新启动系统。如果恢复是由系统自身来完成的，那么，需验证重新初始化、检查点机制、数据恢复和重启动等的正确性。如果恢复需要人工干预，那么要估算平均修复时间MTTR（mean time to repair）是否在用户可以接受的范围内
安全测试：安全测试用来验证集成在系统中的保护机制能否实际保护系统不受非法侵入。
在安全测试过程中，测试者扮演一个试图攻击系统的角色，采用各种方式攻击系统。例如，截取或破译密码；借助特殊软件攻击系统；“制服”系统，使他人无法访问；故意导致系统失效，企图在系统恢复之机侵入系统；通过浏览非保密数据，从中找出进入系统的钥匙等等。一般来说，只要有足够的时间和资源，好的完全测试一定能最终侵入系统。系统设计者的任务是把系统设计成：攻破系统所付出的代价大于攻破系统后得到信息的价值
压力测试：压力测试也称强度测试，它是在一种需要非正常数量、频率或容量的方式下执行系统，其目的是检查系统对非正常情况的承受程度。例如：（1）当系统的中断频率是每秒1或2个时，执行每秒10个中断的测试用例；（2）将输入数据的数量提高一个数量级来测试输入功能如何响应；（3）执行需要最大内存或其它资源的测试用例；（4）执行可能导致大量磁盘驻留数据的测试用例
性能测试：性能测试用来测试软件在集成的系统中的运行性能。它对实时系统和嵌入式系统尤为重要。性能测试可以发生在测试过程的所有步骤中单元测试时，主要测试一个独立模块的性能，如算法的执行速度。软件集成后，进行软件整体的性能测试。计算机系统集成后，进行整个计算机系统的性能测试。性能测试常常需要与压力测试结合起来进行，而且常常需要一些硬件和软件测试设备，以监测系统的运行情况
20.由于面向对象软件把类作为面向对象软件的单元，传统的单元测试等价于面向对象中的类测试，也称类内测试。它包括类内的方法测试和类的行为测试
21.面向对象中的类间测试（interclass testing）相当于面向对象的集成测试。它有两种集成策略：基于线程的测试和基于使用的测试
22.执行测试用例错误时要进行调试，主要的调试方法有：蛮力法、回溯发、原因排除法
第十二章 Web工程
1.基于Web系统和应用（称为WebApp）的属性：网络集约 、并发、不可预测的登陆、性能、可用性、数据驱动、内容敏感、持续演化、数据库访问、数据仓库型
2.WebApp的开发具有如下特点：WebApp常常以增量的方式去开发；变化经常发生；期限较短
3.整个Web工程过程框架包括：客户交流、计划、建模、构建、部署。其中，计划，由一个任务定义和一个时间表组成
4.Web工程方法一般包括如下几种：沟通方法、需求分析方法、设计方法、测试方法
5.Web设计主要可分为：体系结构设计、导航设计、界面设计3个部分
6.一个良好的Web设计需要满足以下要求：设计要尽可能简单；布局要尽可能没换；整体的一致性
7.体系结构主要分为：线性结构、网格结构、层次结构3种
8.WEB工程自己的设计原则：页面速度；页面正确；所有的才打和界面的风格应该统一；链接指示应明显；界面功能明显清晰；通常都需要使用表格等工具
第十三章 软件维护与再工程
1.软件演化是指软件在交付以后，对软件进行的一系列活动的总称
2.软件演化包括：软件维护和软件再工程。其中软件维护阶段覆盖了从软件交付使用到软件被淘汰为止的整个时期。再工程的主要目的是为了遗留系统转化为可演化系统提供一条显示可行的途径
3.软件维护：是指软件系统交付使用以后，为了改正错误或满足新的需要而修改软件的过程
4.软件维护可以分为纠错性维护、适应性维护、改善性维护和预防性维护四类
• 纠错性维护：为了改正软件系统中的错误，使软件能够满足预期的正常运行状态的要求而
进行的维护
• 适应性维护：为了使软件适应内部或外部环境变化，而去修改软件的过程
• 改善性维护：满足使用过程中用户提出增加新功能或修改已有功能的建议维护
• 预防性维护：为了提高软件的可维护性、可靠性等，为以后进一步改进软件打下良好基础
而修改软件的活动
在几种维护活动中，改善性维护占的比重最大，来自用户要求扩充、加强软件功能、性能的维护活动中占整个维护工作的50%
5.和软件维护有关的部分问题：
（1）理解别人的代码通常是非常困难的，而且难度随着软件配置成分的缺失而迅速增加（2）需要维护的软件往往没有文档、或文档资料严重不足、或软件的变化未在相应的文档中反映出来（3）当软件要求维护时，不能指望由原来的开发人员来完成或提供软件的解释。由于维护持续时间很长，因此当需要解释软件时候，往往开发人员已经不在附近了（4）绝大多数软件在设计时没有考虑到将来的修改问题（5）软件维护这项工作毫无吸引力。一方面是因为软件维护，看不到什么“成果”，但工作量很大，更重要的是维护工作难度大，软件维护人员经常遭受挫折
6.软件维护活动包括：建立维护组织；确定维护过程；保管维护记录；进行维护评价
7.对软件可维护性影响的主要因素有：可理解性；可测试性；可修改性和可一致性
8.提高软件可维护性的方法：确定质量管理目标和优先级；规范化程序设计风格；选择可维护性高的程序设计语言；改进程序文档；保证软件质量审查方法
9.逆向工程（reverse engineering）：指在软件生存周期中，将软件的某种形式描述转换成更抽象形式的活动
重构（restructuring）：指在同一抽象级别上转换系统的描述形式。如把C++ 程序转换成Java程序 设计恢复（design recovery）：指借助工具从已有程序中抽象出有关数据结构设计、总体结构设计和过程设计的信息
再工程（reengineering）：指在逆向工程所获信息的基础上修改或重构已有的系统，产生系统的一个新版本
10.再工程的主要目的：为遗留系统转化为可演化系统提供一条现实可行的途径
11.通常再工程包含：业务过程再工程、软件再工程
12.业务过程再工程（BPR）：应该自顶向下进行，是迭代的，没有开始和结束，只有不断的演化，整个业务再工程模型如图P328
13.指导BRP活动的原则：围绕结果而不是任务进行组织；让那些使用过程结果的人来执行；将信息处理工作合并到生产原始信息的现实工作中；将地理分散的资源视为好像它们是集中的；连接并行的活动以代替集成它们的结果；在工作完成的地方设置决策点，并将控制加入过程中；在其源头一次性获取数据
14.软件再工程包含库存目录分析、文档重构、逆向工程、代码重构和数据重构以及正向工程。这一部分通常由软件工程师完成
15.逆向工程导出的信息可分为四个抽象层次：实现级、结构级、功能级、领域级
16.根据源程序的类别不同，逆向工程还可以分为：对用户界面的逆向工程、对数据的逆向工程和对理解的逆向工程
17.逆向工程中用于恢复信息的方法主要有四类：用户指导下的搜索与变换；变换方法；基于领域知识的方法；铅板恢复
第十四章 软件项目管理
1.项目管理是通过项目经理和项目组织的努力，运用系统理论的方法对项目及其资源进行计划、组织、协调、控制，旨在实现项目的特定目标的管理方法体系
2.(软件)项目管理的基本内容：项目定义、项目计划、项目执行、项目控制、项目结束
3.软件项目管理的关注点：
人员(People)：人员是软件工程项目的基本要素和关键因素在对人员进行组织时，有必要考虑参与软件过程(及每一个软件项目)的人员类型
产品(Product)：定义项目范围，其中包括建立产品的目的和范围、可选的解决方案、技术或管理的约束等
过程(Process)：通常将项目分解为任务—子任务等，其分解准则是基于软件工程的过程
项目(Project)：采用科学的方法及工具对项目基本内容进行管理
4.软件度量是指计算机软件范围内的测量，主要是为产品开发的软件过程和产品本身定义相关的测量方法和标度
5.需要考虑：合适的度量是什么；所收集的数据如何使用；用于比较个人、过程或产品的度量是否合理
6.度量对象：软件产品、软件过程、资源
7.软件度量有两种分类方法：第一种是将软件度量分为面向规模的度量、面向功能的度量和面向人的度量；第二种分类方法是软件度量分为生产率的度量、质量度量和技术度量。
8.功能点（FP）度量的5个信息域特征及其含义：
用户输入数：对每个用户输入进行计数，它们向软件提供不同的面向应用的数据
用户输出数：对每个用户输出进行计数，它们向用户提供不同的面型应用的信息
用户查询书：一个查询被定义为一个联机输入，它导致软件以联机输出的方式产生适时的响应。每个不同的查询都要计算
文件数：对每个逻辑上的主文件进行计算
外部接口数：对说有机器可读的接口进行计数，利用这些接口可以将信息从一个系统传到另一个系统
9.软件质量定义：
– ISO/IEC 9126《信息技术 软件产品质量评价 质量特性及其使用指南》中定义为：
与软件产品满足明确或隐含需求的能力有关的特征和特性的总和
– GB/T 13423《工业控制用软件评定准则》：软件产品中能满足给定需求的性质和
特性的总和，例如符合规格说明的程度；软件具有所期望的各种属性的组合程度；客户
或用户觉得软件满足其综合期望的程度；软件的综合特性，它确定软件在使用中将满足
客户预期要求的程度
10.McCall等人1987年提出一个包括软件质量要素、评价准则和度量3个层次的软件质量度量模型框架
11.软件质量的11个要素：正确性、可靠性、效率、完整性、可用性、可维护性、灵活性、可测试性、可移植性、可复用性、可互操作性
12.软件质量要素评价的21个准则：可审计性、准确性、通信机制通用性、完备性、简洁性、一致性、数据通用性、容错性、执行效率、可扩展性、通用性、硬件独立性、自检测性、模块性、可操作性、安全性、自文档性、简单性、软件系统独立性、可追踪性、易培训
13.ISO/IEC 9126质量模型：由质量特性、子特性和度量三个层次组成；第一层有6个质量特性；第二层有21个质量子特性；第三层是由度量者定义的可定量化度量指标
14.典型的程序复杂性度量：McCabe环形复杂性度量、Halstead的复杂性度量
15.Halstead认为程序是由操作符和操作数组成的符号序列。设n1为程序中不同操作符的个数，n2为程序中不同操作数的个数、N1为程序中操作符的总数、N2为程序中操作数的总数，则Halstead度量公式如下：
程序的符号长度：N = N1 + N2
程序的词汇量：n=n1+n2
程序量(指存储容量)：V=N log2 (n1 +n2)=(N1+ N2 ) log2 (n1 +n2)，习惯上，称该公式为长度方程 最小程序量：可以认为，最小的程序只有两个操作符：函数调用和赋值，即n1＝N1=2，而操作数n2*
就是赋于函数值的变量和函数调用时的参数，即n2*= n2= N2代入长度方程，可得最小程序量为：V*＝(2+n2*)log2(2+n2*)
预测程序长度：V*＝n1 log2 n1 +n2 log2 n2
预测程序潜在的错误数：B’=V/3000
16.软件可靠性通常用下列公式进行计算：
MTBF＝MTTF＋MTTR。其中：MTBF(mean time between failer)是平均故障间隔时间，MTTF(mean time to failer)是平均故障时间，MTTR(mean time to repair)是平均修复时间
17.软件可靠性估算：与软件可靠性密切相关的程序中残留错误数的估算和平均故障间隔时间的估算方法：错误植入法；分别测试法；软件平均故障间隔时间估算
18.指导软件项目进度安排的基本原则：划分、相互依赖性、时间分配、工作量确认、定义责任、定义结果、定义里程碑
19.根据软件工程过程的不同，可确定其相应的任务的工程量分配。常用的有40-20-40规则：在整个软件开发过程中，编码工作量仅占20%，编码前工作量占40%，编码后工作量占40%
20.甘特图：也称时间表(Timeline chart)，用来建立项目进度表，在甘特图中，每项任务的完成以必须交付的文档和通过评审为标准
21.用于软件开发的项目进度安排方法：计划评审技术和关键路径方法，它们是安排开发进度、制定软件开发计划的最常用的方法
22.风险：在给定情况下和特定时间内，那些可能发生的结果与预期结果之间的差异，差异越大，风险越大。
风险应该具备以下因素：事件、事件发生的概率、事件的影响、风险的原因
风险可表示成不确定和后果的函数：风险＝f(事件，不确定性，后果)
23.风险管理就是识别评估风险，建立、选择、管理和解决风险的可选方案和组织方法。包括了风险标识、风险预测、风险评估和风险管理与监控四个活动
24.风险可以分为：项目风险；技术风险和商业风险3类
25风险预测也称风险估算，风险预测.评价每种风险发生的可能性或概率以及当该风险发生时所导致的后果。以中间大的风险预测技术是建立风险表，风险表的第1列列出所有的风险，第2至4列列出每个风险的种类(项目风险、技术风险、商业风险等)、发生的概率以及所产生的影响
26.软件项目组织的组织原则有以下3条：尽早落实责任、减少交流接口、责权均衡
27.程序设计小组的组织形式有：主程序员制小组、民主制小组、层次式小组
28.人员配备的原则：重质量、重培训、双阶梯提升
29.技术评审的指导原则：
• 评审产品，而不是评审生产者
• 制定议事日程且遵守日程
• 限制争论和辨驳
• 对各个问题都发表见解，但不要试图解决所有记录的问题
• 做书面笔记
• 限制参与者人数并坚持事先做准备
• 为每个可能要评审的工作制品建立一个检查表
• 为正式技术评审分配资源和时间
• 对所有评审者进行有意义的培训
• 评审以前所做的评审
30.配置状态报告，也称为状态记录，它回答下列问题：发生了什么事；谁做的此事；此事是什么时候发生的；将影响别的什么