软件工程大纲总结
一、软件工程概述
包括但不限于软件、软件工程等基本概念，主要内容有
软件的概念：是一系列按照特定顺序组织的计算机数据和指令的集合（软件主要包括程序、文档、数据等成分）
软件的特征：
1、无形的，没有物理形态，只能通过运行状况来了解功能、特性和质量
2、软件渗透了大量的脑力劳动，人的逻辑思维、智能活动和技术水平是软件产品的关键
3、软件不会像硬件一样老化磨损，但存在缺陷维护和技术更新
4、软件的开发和运行必须依赖于特定的计算机系统环境，对于硬件有依赖性，为了减少依赖，开发中提出了软件的可移植性
5、软件具有可复用性，软件开发出来很容易被复制，从而形成多个副本
软件的分类：软件被划分为系统软件、应用软件和介于这两者之间的中间件
软件危机产生的原因：
1、一方面与软件本身的特点有关；管理和控制软件开发过程相当困难；软件较难维护；2、另一方面也和软件开发与维护的方法不正确有关：忽视软件需求分析的重要性，轻视软件维护，对用户要求没有完整准确的认识就匆忙着手编写程序；软件配置主要包括程序、文档、数据等成分，只重视程序而忽视软件配置其余成分。
软件危机的表现：
1、对软件开发成本和进度的估计常常很不准确；2、用户对“已完成的”软件系统不满意的现象经常发生；3、软件产品的质量往往靠不住；4、软件常常是不可维护的；5、软件通常没有适当的文档资料；6、软件成本在计算机系统总成本中所占的比例逐年上升；7、软件开发生产率提高的速度，既跟不上硬件的发展速度，也远远跟不上计算机应用迅速普及深入的趋势；
软件工程的概念原则：
软件工程是指导计算机软件开发和维护的工程学科。采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来，经济地开发出高质量的软件并有效地维护它
软件工程的原则：
软件工程的7条基本原理：1、用分阶段的生命周期计划严格管理；2、坚持进行阶段评审；3、实行严格的产品控制（意思所有变更都要评审）；4、采用现代程序设计技术（比如面向对象）；5、结果应能清楚地审查（意思要划责任、设标准）；6、开发小组的人员应该少而精；7、承认不断改进软件工程实践的必要性（意思要谦虚学习）
软件工程知识体以及相关标准：
软件工程知识体系划分为以下10个知识领域：1、软件需求；2、软件设计（就是架构和详设）；3、软件构建（就是开发编码和自测）；4、软件测试；5、软件维护；6、软件配置管理（这活也是运维干的）；7、软件工程管理（就是项目经理的活，计划协调把握进度）；8、软件工程过程；（意思应该是项目总负责人，把项目跟到下线，过程中不断提新需求改进系统）；9、软件工程工具和方法；（比如自动化测试运维CICD持续集成啥的工具）；10、软件质量；（就是客户满不满意）
二、软件工程过程
包括但不限于软件生命周期和基本过程模型等基本概念，主要内容有：软件生命周期概念 和各个阶段，典型软件过程模型：瀑布模型、快速原型模型、螺旋模型、统一过程模型、敏捷 模型等。
软件生命周期概念 和各个阶段：软件生命周期由软件定义、软件开发和运行维护3个时期组成
1、软件定义：分为3个阶段，即问题定义、可行性研究、需求分析。
问题定义：要解决的问题是什么（出问题性质工程目标的书面报告）
可行性研究：上一个阶段所确定的问题是否有行得通的解决办法（概括需求提方案，看方案是否可行）
需求分析：目标系统必须做什么（与客户敲定需求细节，出需求规格说明书）
2、软件开发：概要设计、详细设计、编码和单元测试、综合测试。
概要设计：设计程序的体系结构，确定有哪些模块，模块间的关系
详细设计：详细地设计每个模块，确定实现模块功能所需要的算法和数据结构。
编码和单元测试
综合测试：集成测试（就是各个模块联调了），验收测试（照着需求说明书去验功能）。出 测试计划、详细测试方案以及实际测试结果
3、软件维护：改正性维护（比如错误数据手动改改）、适应性维护（比如改个环境配置）、完善性维护（比如加机器）、预防性维护（比如经常备份预防宕机）
瀑布模型：
收集需求——分析——设计——编码——测试——维护
特点：阶段间具有顺序性和依赖性（前面完成了才能干后面）；推迟实现的观点（清楚地区分逻辑设计与物理设计，尽可能推迟程序的物理实现。就是别急，想好了再写代码）；质量保证的观点（每个阶段都出文档，并评审）；每个阶段发现错误都得反馈给上一阶段修改
优点：可强迫开发人员采用规范的方法（如结构化技术）；严格地规定了每个阶段必须提交的文档；要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证。
缺点：由于瀑布模型几乎完全依赖于书面的规格说明，很可能导致最终开发出的软件产品不能真正满足用户的需要
快速原型模型：
就是根据需求用可视化编程工具先做个demo，然后根据需求不断地改。改到满意再写需求规格说明书，再详细开发
优点：用户不会再改需求了；开发明确知道用户想要啥了；就是快
螺旋模型：
在每个阶段之前都增加了风险分析过程的快速原型模型。 然后风险分析没问题了，就按瀑布开发，完成了阶段工作，就再按这个步骤转一圈，螺旋上升式推进项目
优点：质量高风险低，维护和开发一直干
适合内部大型项目，因为项目越大风险越大，内部的所以说停就能停
缺点是就怕开发经验不够，评估不出风险
统一过程模型 rational unified process，RUP：
是个软件开发过程框架。
核心：用于成功开发软件的一组基本观念和原则（6条“最佳实践”和10个“流程要素”）；一套关于可重用方法内容和过程构建的框架。可以在这个框架之下定义自己的开发方法和过程；基础的方法和过程定义语言。这就是统一方法架构元模型（unified method architecture，UMA）。该模型提供了用于描述方法内容及过程的语言。这种新语言统一了不同方法和过程工程语言。
最佳实践：最佳实践”描述了一个指导开发团队达成目标的迭代和递增式的软件开发过程。1、迭代式开发；（就是每个版本，用户可以提意见，下个版本改）；2、管理需求；（用用例分析来捕获需求）；3、使用基于组件的架构；（就是多用组件，相当于模块，微服务那感觉）；4、可视化建模；（就类似流程图，可视化的统一建模语言（Unified Modeling Language，UML））；5、验证软件质量；（自始至终全员参与）；6、控制软件变更（我估计类似svn）
十大要素：1、前景：制定前景（分析问题，理解项目干系人的需求，定义系统以及管理需求变化）；2、计划：按计划管理；3、风险：降低风险并跟踪相关问题（就是做个风险表）；4、业务案例：检验业务案例（就是项目预算钱）；5、架构：设计组件架构（就是定项目架构出个文档）；6、原型：增量地构建和测试产品（还是迭代，版本）；7、评估：定期评估结果（还是在迭代时评审）；8、变更请求：管理并控制变更（就是评估一下变更的代价）；9、用户支持：部署可用的产品（给用户个说明书）；10、过程：采用适合项目的过程（不要盲从流程）
RUP生命周期：1、核心工作流：业务建模-需求-分析与设计-实现-测试-部署-配置与变更管理-项目管理-环境；2、工作阶段：先启阶段（确定项目范围）、精化阶段（设计架构项目计划）、构建阶段（开发测试）、移交阶段（交给用户）；3、RUP迭代式开发：每次迭代中只考虑系统的一部分需求，针对这部分需求进行分析、设计、实现、测试、部署等，每次迭代都是在系统已完成部分的基础上进行的，每次给系统增加一些新的功能，如此循环往复地进行下去，直至完成最终项目 （这不就按版本开发么）
敏捷 模型：
1、“个体和交互”胜过“过程和工具”（就是大家面对面直接交流）2、“可以使用的软件”胜过“面面俱到的文档”（就是写完代码再补文档）3、“客户合作”胜过“合同谈判”（开发团队与客户密切协作）4、“响应变化”胜过“遵循计划”（计划要够灵活）
原则：1、尽早和持续交付；2、后期也能改需求；3、交付周期越短越好；4、业务和开发每天在一起；5、开发人员要积极；6、团队里大家面对面交流；7、就看软件做好没有，说别的没用；8、持续周期长，人员要稳定；9、要追求好技术；10、简单；11、自己团队决定架构；12、多总结如何提高效率
三、软件需求分析
包括但不限于需求和需求分析相关的概念和应用，主要内容包括：软件需求的基本概念、 功能需求、非功能需求和需求的评价准则；常见的需求调方法：竞品分析、观察、访谈、开会、 原型和问卷调查等；结构化需求分析基本概念，数据流图、状态转换图和ER图的基本用法；基 于用例的需求建模方法和过程，参与者、用例、用例图、用例文档的基本概念，基于用例方法 开展需求建模实践；面向对象技术的基本概念，对象和类，面向对象的基本原则：抽象、封装、 分解、泛化、多态、分层和复用等；可视化建模语言UML的基本概念、UML特点，UML基本 构造块和通用机制，常见的UML图：用例图、活动图、类图、对象图、包图、顺序图、通信图、 状态机图、构件图和部署图等；利用UML开展面向对象的分析基本过程，抽取分析类：边界类、 控制类和实体类，基于顺序图、通信图等开展交互分析，定义分析类的职责和属性，分析类的 关系：泛化关系、关联关系、聚合关系和组合关系。
四、软件设计
包括但不限于软件设计的概念和应用，主要内容有：软件设计的基本原则，概要设计（架 构设计）和详细设计（构件设计）的基本过程；软件体系结构（架构）的基本概念和过程、典 型架构模式（风格）、关键质量属性设计；面向数据流设计的基本概念，流程图、判定表、判定 树和过程设计语言等基本设计方法；数据库设计的基本概念，界面设计的基本概念；面向对象 设计基本概念，设计类的操作、方法和状态设计，关联关系设计，依赖关系、泛化关系等设计， 面向对象设计模式的基本概念。
五、软件构造与测试
包括但不限于软件构造和测试的概念和应用，主要内容有：软件构造的基本概念、一般原 则和要点，设计模型与实现模型的映射；软件测试的基本概念、原则和模型；测试用例的基本 概念和设计方法，黑盒测试概念和方法：等价类、边界值等，白盒测试概念和方法：程序流图、 逻辑覆盖等；单元测试、集成测试、系统测试、验收测试、回归测试等基本概念。
六、软件项目管理基础
包括但不限于软件项目管理的基本概念，主要内容有：软件项目管理基础及项目规划；软 件成本管理、风险管理、质量管理、配置管理等各类管理概念。
其余部分知识点思维导图
链接: https://pan.baidu.com/s/1ZiftDXCEmZngmgM8mjkV1Q 提取码: 477n 复制这段内容后打开百度网盘手机App，操作更方便哦
OOA(面向对象分析)
OOD（面向对象设计）
OOP（面向对象实现）
OOT（面向对象测试）
动作抽象：一个对象，提供了一组通用的操作，所有这些操作都执行同类的功能。
界定是否用动作抽象的标准：方法是否产生数据，是否有内部状态，有就用。
虚拟机抽象：一个对象，集中了某种高层控制要用到的所有操作。
概念类，比如党派，培育计划。
偶然抽象：一个对象，封装了一组相互间没有关系的操作。
如tools工具包
封装的意义：和抽象互补，抽象关注对象可以观察到的行为，封装关注这种行为的实现。
封装在不同抽象之间提供了明确的边界。
抽象、封装、模块化是相辅相成的，一个对象围绕单一的抽象提供了一个明确的边界，封装和模块化都围绕这种抽象提供了屏障。
关于并发：
在高层次的抽象中，通过将并发隐藏在可复用的抽象中，OOP可以减轻大多数程序员在并发问题上的负担。
虽然面向对象编程关注数据抽象，但是封装、继承、并发关注了过程抽象和同步。对象是统一这两种不同观点的概念：
每个对象（来自于真实世界的一个抽象）都可以代表一个独立的控制线程（一种过程抽象）。这样的对象被称为主动的。
在基于面向对象设计的系统中，我们可以将世界概念化为一组协作的对象，其中某些是主动的，因此作为独立活动的中心。
在面向对象的设计中有3中并发方式：
1、语言提供了并发和同步的机制，可以创建一个主动对象，他与其他主动对象一起并发执行某些处理过程。
2、可以使用类库来实现轻量级进程。
3、利用中断实现并发的假象。
最好用1，让一个对象管理多个线程，而不是每个线程创建一个对象。
软件过程是为了获得高质量软件产品所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。软件过程必须科学、合理，才能开发出高质量的软件产品。按照在软件生命周期全过程中应完成的任务的性质，在概念上可以把软件生命周期划分成问题定义、可行性研究、需求分析、概要设计、详细设计、编码和单元测试、综合测试以及维护8个阶段。实际从事软件开发工作时，软件规模、种类、开发环境、使用的技术方法等因素，都影响阶段的划分，因此，一个科学、有效的软件过程应该定义一组适合于所承担的项目特点的任务集合。生命周期模型（即软件过程模型）规定了把生命周期划分成的阶段及各个阶段的执行顺序。本章介绍了5类典型的软件生命周期模型。瀑布模型历史悠久、广为人知，它的优势在于它是规范的、文档驱动的方法。这种模型的问题是，最终交付的产品可能不是用户真正需要的。快速原型模型正是为了克服瀑布模型的缺点而提出来的。它通过快速构建起一个可运行的原型系统，让用户试用原型并收集用户反馈意见的办法，获取用户的真实需求。增量模型具有能在软件开发的早期阶段使投资获得明显回报和易于维护的优点。但是，要求软件具有开放结构是使用这种模型时固有的困难。风险驱动的螺旋模型适用于大规模的内部开发项目，但是，只有在开发人员具有风险分析和排除风险的经验及专门知识时，使用这种模型才会获得成功。当使用面向对象范型开发软件时，软件生命周期必须是循环的。也就是说，软件过程必须支持反馈和迭代。喷泉模型是一种典型的适合于面向对象范型的过程模型。能力成熟度模型（CMM），是改进软件过程的一种策略。它的基本思想是，因为问题是管理软件过程的方法不恰当引起的，所以运用新软件技术并不会自动提高软件生产率和软件质量，应当下大力气改进对软件过程的管理。对软件过程的改进不可能一蹴而就，因此，CMM 以增量方式逐步引入变化，它明确地定义了5个不同的成熟度等级，一个软件开发组织可用一系列小的改良性步骤迈入更高的成熟度等级。每个软件开发组织都应该选择适合于本组织及所要开发的软件特点的软件生命周期模型。这样的模型应该把各种生命周期模型的合适特性有机地结合起来，以便尽量减少它们的缺点，充分利用它们的优点。
传统的软件工程方法学使用结构化分析技术，完成分析用户需求的工作。需求分析是发现、求精、建模、规格说明和复审的过程。需求分析的第一步是了解用户当前所处的情况，发现用户所面临的问题。接下来应该通过与用户交流，对用户的基本需求反复细化，以得出对目标系统的完整、准确和具体的需求。为了详尽地了解并正确地理解用户的需求，必须使用适当的方法与用户沟通和交流。访谈是历史悠久的与用户沟通方法，至今仍被系统分析员广泛采用。为了促使用户与分析员密切合作共同分析需求，人们研究出一种面向团队的需求收集法，称为“简易的应用规格说明技术”。现在，这种技术已经成为信息系统界使用的主流技术。实践表明，快速建立软件原型是最准确、最有效和最强大的需求分析技术。快速原型应该具备的基本特性是“快速”和“容易修改”，因此，必须有适当的软件工具支持快速原型技术。通常使用第四代技术、可重用的软件构件及形式化规格说明与原型环境等工具，快速地构建和修改原型。为了更好地理解问题，人们常常采用建立模型的方法，结构化分析实质上就是一种建模活动，通常建立数据模型、功能模型和行为模型。在需求分析阶段建立起来的模型，在软件开发过程中有许多重要作用。◇ 模型能帮助分析员更好地理解软件系统的信息、功能和行为，从而使得需求分析工作更容易完成，使需求分析的结果更系统化。◇ 模型是复审需求分析成果时的焦点，因此，也成为验证规格说明的完整性、一致性和准确性的重要依据。◇ 模型是设计的基础，为设计者提供了软件的实质性表示，通过设计工作将把这些表示转化成软件实现。除了创建分析模型之外，在需求分析阶段还应该写出软件需求规格说明，经过认真评审并得到用户确认之后，作为这个阶段的最终成果。通常，使用实体——关系图来建立数据模型，读者应该掌握这种图形的基本符号，能够正确地使用这些符号建立软件系统的数据模型。数据流图是描绘信息流和数据从输入移动到输出的过程中所经受的变换的图形化技术。可以在任何抽象层次上使用数据流图来表示信息处理系统或软件。它是分析员与用户之间沟通、交流的有效工具，也是进行软件设计的极好出发点。由于结构化分析通常主要关注目标系统应该完成的逻辑功能，而数据流图提供了功能建模的基本机制，因此，数据流图是结构化分析过程中使用的最主要的建模工具。读者应该熟练掌握数据流图的基本符号，并能正确地使用这些符号建立目标系统的功能模型。状态转换图通过描绘系统的状态及引起系统状态转换的事件，表示系统的行为，从而提供了行为建模的机制。数据字典描述在数据模型、功能模型和行为模型中出现的数据对象和控制信息的特性，给出这些对象的精确定义。因此，数据字典成为把3种分析模型黏合在一起的“黏合剂”，是分析模型的“核心”。在开发大型软件系统的过程中，数据字典的规模和复杂程度都迅速增加，通常需要使用CASE工具来创建和维护数据字典。本章最后讲述了一个结构化分析的实际例子。认真阅读并仔细思考这个例子，有助于读者更深入具体地理解用结构化技术完成系统分析工作的过程和方法，并逐步学会用结构化分析技术解决实际问题。
软件设计的目标是设计出所要开发的软件的模型，传统的软件工程方法学采用结构化设计技术完成软件设计工作。软件设计在软件工程过程中处于技术核心地位，是软件开发过程中决定软件产品质量的关键阶段。软件设计必须依据对软件产品的需求来进行，因此，结构化设计把结构化分析的结果作为基本输入信息。由数据模型、功能模型和行为模型描述的软件需求被传送给软件设计者，以便他们采用适当的设计方法完成数据设计、体系结构设计、接口设计和过程设计。为了获得高质量的软件设计结果，应该遵循模块化、抽象、逐步求精、信息隐藏、模块独立等基本设计原理，特别是其中的模块独立原理，对软件体系结构设计和接口设计具有非常重要、十分具体的指导作用。总结众多软件工程师在开发软件的长期实践中所积累的丰富经验，形成了一些启发规则，这些启发规则虽然不像上述基本原理那样普遍适用，但在许多场合仍然能给软件设计者以有益的启示，有助于设计出有效模块化的软件。通常，使用层次图或结构图表示软件结构，这些图形工具具有形象直观、容易理解的优点，读者应该学会用这类图形描绘软件结构。面向数据流的设计方法是设计软件体系结构的一种系统化的方法，它定义了一些映射规则，可以把数据流图变换成软件的初步结构。得出软件的初步结构之后，还必须根据好设计的标准，用基本设计原理和启发规则为指南，对所得到的软件结构进行仔细优化，才能设计出令人满意的软件体系结构。人—机界面设计是接口设计的一个组成部分。对于交互式系统来说，人—机界面设计和数据设计、体系结构设计、过程设计一样重要。人—机界面的质量直接影响用户对软件产品的接受程度，因此，必须对人—机界面设计给予足够重视。在设计人—机界面的过程中，必须充分重视并认真处理好系统响应时间、用户帮助设施、出错信息处理和命令交互4个设计问题。用户界面设计是一个迭代过程。通常，先创建设计模型，接下来用原型实现这个设计模型并由用户试用和评估原型，然后根据用户意见修改原型，直到用户满意为止。总结人们在设计人—机界面过程中积累的经验，得出了一些关于用户界面设计的指南，认真对待这些设计指南有助于设计出友好、高效的人—机界面。过程设计应该在数据设计、体系结构设计和接口设计完成之后进行，它是详细设计阶段的主要任务。过程设计的目标不仅是保证算法正确，更重要的是设计出的处理过程应该尽可能简明易懂。结构程序设计技术是实现上述目标的关键技术，因此是过程设计的逻辑基础。描述程序处理过程的工具，可分为图形、表格和语言3类，这3类工具各有所长，读者应该能够根据需要选用适当的工具。在许多应用领域中信息都有清楚的层次结构，在开发这类应用系统时可以采用面向数据结构的设计方法完成过程设计。
实现包括编码和测试两个阶段。按照传统的软件工程方法学，编码是在对软件进行了概要设计和详细设计之后进行的，编码不过是把软件设计的结果翻译成用某种程序设计语言书写的程序，因此，程序的质量基本上由设计的质量决定。但是，编码使用的语言，特别是写程序的风格，也对程序质量有相当大的影响。大量实践结果表明，高级程序设计语言较汇编语言有很多优点。因此，除非在非常必要的场合，一般不要使用汇编语言写程序。至于具体选用哪种高级程序设计语言，则不仅要考虑语言本身的特点，还应该考虑使用环境等一系列实际因素。程序内部的良好文档资料，有规律的数据说明格式，简单清晰的语句构造，输入/输出格式等，都对提高程序的可读性有很大作用，也在相当大的程度上改进了程序的可维护性。目前，软件测试仍然是保证软件可靠性的主要手段。测试阶段的根本任务是发现并改正软件中的错误。设计测试方案是测试阶段的关键技术问题，其基本目标是选用尽可能少的高效测试数据，做到尽可能完善的测试，从而尽可能多地发现软件中的错误。白盒测试和黑盒测试是软件测试的两类不同方法，这两类方法各有所长，相互补充，在测试过程中应该联合使用这两类方法。通常，在测试过程的早期阶段主要使用白盒测试技术，而在测试的后期主要使用黑盒测试技术。为了设计出有效的测试方案，软件工程师必须深入理解并应用指导软件测试的基本准则。设计白盒测试方案的技术主要有逻辑覆盖和控制结构测试；设计黑盒测试方案的技术主要有等价划分、边界值分析和错误推测。大型软件的测试应该分阶段进行，通常分为单元测试、集成测试、确认测试和系统测试（如果软件是新开发的计算机系统的一部分）4个阶段。在测试过程中发现的软件错误必须及时改正，这就是调试的任务。为了改正错误，首先必须确定错误的准确位置，这是调试过程中最困难的任务，需要审慎周密的思考和推理。改正错误往往需要修正原来的设计，必须通盘考虑而不能“头疼医头脚疼医脚”，应该尽量避免在调试过程中引进新的错误。测试和调试是软件测试阶段中的两个关系极其密切的过程，它们常常交替进行。程序中潜藏的错误的数目，直接决定了软件的可靠性。通过测试可以估计出程序中剩余的错误数。根据测试和调试过程中已经发现和改正的错误数，可以估计软件的平均无故障时间；反之，根据要求达到的软件平均无故障时间，可以估计应该发现和改正的错误数，从而能够判断测试阶段何时可以结束。
近年来，面向对象方法学日益受到人们的重视，特别是在用这种方法开发大型软件产品时，可以把该产品看做是由一系列本质上相互独立的小产品组成，不仅降低了开发工作的技术难度，而且也使得对开发工作的管理变得比较容易了，因此，对于大型软件产品来说，面向对象范型明显优于结构化范型。此外，使用面向对象范型能够开发出稳定性好、可重用性好和可维护性好的软件。这些都是面向对象方法学的突出优点。面向对象方法学比较自然地模拟了人类认识客观世界的思维方式，它所追求的目标和遵循的基本原则，就是使描述问题的问题空间和在计算机中解决问题的解空间，在结构上尽可能一致。面向对象方法学认为，客观世界由对象组成。任何事物都是对象，每个对象都有自己的内部状态和运动规律，不同对象彼此间通过消息相互作用、相互联系，从而构成了我们所要分析和构造的系统。系统中每个对象都属于一个特定的对象类。类是对具有相同属性和行为的一组相似对象的定义。应该按照子类、父类的关系，把众多的类进一步组织成一个层次系统，这样做了之后，如果不加特殊描述，则处于下一层次上的类可以自动继承位于上一层次的类的属性和行为。用面向对象观点建立系统的模型，能够促进和加深对系统的理解，有助于开发出更容易理解、更容易维护的软件。通常，人们从3个互不相同然而又密切相关的角度建立起3种不同的模型，它们分别是描述系统静态结构的对象模型、描述系统控制结构的动态模型，以及描述系统计算结构的功能模型。其中，对象模型是最基本、最核心、最重要的。统一建模语言（UML）已成为国际对象管理组织（OMG）最频繁使用的、基于面向对象技术的标准建模语言。通常，使用UML的类图来建立对象模型，使用UML的状态图来建立动态模型，使用数据流图或UML的用例图来建立功能模型。在UML中把用用例图建立起来的系统模型称为用例模型。本章所讲述的面向对象方法及定义的概念和表示符号，可以适用于整个软件开发过程。软件开发人员无须像用结构分析、设计技术那样，在开发过程的不同阶段转换概念和表示符号。实际上，用面向对象方法开发软件时，阶段的划分是十分模糊的，通常在分析、设计和实现等阶段间多次选代。喷泉模型是典型的面向对象软件过程模型。
分析就是提取系统需求并建立问题域精确模型的过程，它包括理解、表达和验证3项主要工作内容。面向对象分析的关键工作，是分析、确定问题域中的对象及对象间的关系，并建立起问题域的对象模型。大型、复杂系统的对象模型通常由下述5个层次组成：主题层、类与对象层、结构层、属性层和服务层。它们对应着在建立对象模型的过程中所应完成的5项工作。大多数分析模型都不是一次完成的，为了理解问题域的全部含义，必须反复多次地进行分析，因此，分析工作不可能严格地按照预定顺序进行；分析工作也不是机械地把需求陈述转变为分析模型的过程。分析员必须与用户及领域专家反复交流、多次磋商，及时纠正错误认识并补充缺少的信息。分析模型是同用户及领域专家交流时有效的通信手段，最终的模型必须得到用户和领域专家的确认。在交流和确认的过程中，原型往往能起很大的促进作用。一个好的分析模型应该正确完整地反映问题的本质属性，且不包含与问题无关的内容。分析的目标是全面深入地理解问题域，其中不应该涉及具体实现的考虑。但是，在实际的分析过程中完全不受与实现有关的影响也是不现实的。虽然分析的目的是用分析模型取代需求陈述，并把分析模型作为设计的基础，但是事实上，在分析与设计之间并不存在绝对的界线。认真阅读并仔细思考本章讲述的自动取款机系统和电梯系统这两个实例，有助于读者更深入、具体地理解面向对象分析的方法与过程。
面向对象设计，就是用面向对象观点建立求解空间模型的过程。通过面向对象分析得出的问题域模型，为建立求解空间模型奠定了坚实基础。分析与设计本质上是一个多次反复迭代的过程，而面向对象分析与面向对象设计的界限尤其模糊。优秀设计是使得目标系统在其整个生命周期中总开销最小的设计，为获得优秀的设计结果，应该遵循一些基本准则。本章结合面向对象方法学固有的特点讲述了面向对象设计准则，并介绍了一些有助于提高设计质量的启发式规则。用面向对象方法设计软件，原则上也是先进行总体设计（即系统设计），然后再进行详细设计（即对象设计）。当然，它们之间的界限非常模糊，事实上是一个多次反复迭代的过程。大多数求解空间模型，在逻辑上由4大部分组成。本章分别讲述了问题域子系统、人—机交互子系统、任务管理子系统和数据管理子系统的设计方法。此外还讲述了设计类中服务的方法及实现关联的策略。通常应该在设计工作开始之前，对系统的各项质量指标的相对重要性做认真分析和仔细权衡，制定出恰当的系统目标。在设计过程中根据既定的系统目标，做必要的优化工作。
面向对象方法学把分析、设计和实现很自然地联系在一起了。虽然面向对象设计原则上不依赖于特定的实现环境，但是实现结果和实现成本却在很大程度上取决于实现环境。因此，直接支持面向对象设计范型的面向对象程序语言、开发环境及类库，对于面向对象实现来说是非常重要的。为了把面向对象设计结果顺利地转变成面向对象程序，首先应该选择一种适当的程序设计语言。面向对象的程序设计语言非常适合用来实现面向对象设计结果。事实上，具有方便的开发环境和丰富的类库的面向对象程序设计语言，是实现面向对象设计的最佳选择。良好的程序设计风格对于面向对象实现来说格外重要。它既包括传统的程序设计风格准则，也包括与面向对象方法的特点相适应的一些新准则。面向对象方法学使用独特的概念和技术完成软件开发工作，因此，在测试面向对象程序的时候，除了继承传统的测试技术之外，还必须研究与面向对象程序特点相适应的新的测试技术。面向对象测试的总目标与传统软件测试的目标相同，也是用最小的工作量发现最多的错误。但是，面向对象测试的策略和技术与传统测试有所不同，测试的焦点从过程构件（模块）移向了对象类。一旦完成了面向对象程序设计，就开始对每个类进行单元测试。测试类时使用的方法主要有随机测试、划分测试和基于故障的测试。每种方法都测试类中封装的操作。应该设计测试序列以保证相关的操作受到充分测试。检查对象的状态（由对象的属性值表示），以确定是否存在错误。可以采用基于线程或基于使用的策略完成集成测试。基于线程的测试，集成一组相互协作以对某个输入或某个事件做出响应的类。基于使用的测试，从那些不使用服务器类的类开始，按层次构造系统。设计集成测试用例，也可以采用随机测试和划分测试方法。此外，从动态模型导出的测试用例，可以测试指定的类及其协作者。面向对象系统的确认测试也是面向黑盒的，并且可以应用传统的黑盒方法完成测试工作。但是，基于情景的测试是面向对象系统确认测试的主要方法。
统一建模语言（UML）的提出，标志着面向对象建模方法已经进入了第三代。1997年11月，OMG组织采纳UML作为面向对象建模的标准语言。多年以来，UML已经迅速成长为一个事实上的工业标准，并即将被国际标准化组织采纳作为信息技术的正式国际标准。UML是一种标准的图形化建模语言，它用若干个视图构造系统的模型，每个视图描述系统的一个方面。视图用图描述，图用模型元素的图示符号表示。图中包含的模型元素可以有类、对象、节点、包、构件、关系、消息等。UML的图包括：用例图、类图、对象图、状态图、活动图、顺序图、协作图、构件图和部署图。用例模型是描述系统基本功能的工具，它由一个或多个用例图描述。用例图主要由用例和执行者组成。一个用例代表系统的一个完整功能，执行中的用例是一个动作序列。执行者是与系统交互的人或物，它代表外部实体。类图描述系统的静态结构，由类及它们之间的关系构成。类图是构建其他 UML 图的基础。类与类之间可以有关联、泛化（继承）、依赖和细化4种关系。所有系统都既有静态结构又有动态行为，动态行为描述静态结构内包含的元素是如何交互的。UML 提供了下述 4 种图以支持动态建模：状态图描述对象的所有可能状态及引起状态转换的事件；顺序图描述对象之间的动态交互关系，着重表现对象间传递消息的时间顺序；协作图描述相互协作的对象间的交互关系和链接关系，着重表现交互对象的静态链接关系；活动图是状态图的变种，主要描述动作及动作的结果——对象状态的改变。系统架构是对构成系统的各个部分的框架性描述，可分为逻辑架构和物理架构。逻辑架构完整地描述系统的功能；物理架构描述代码构件的结构和组成系统的硬件结构，它详细地描述逻辑架构中定义的概念的实现方案。软件构件和构件间的相关性在 UML 的构件图中显示。部署图描述硬件节点和节点间的连接，可以把可执行的构件分配给执行它们的节点，而且可以把对象分配给构件。本章给出了使用UML的几条准则，可供实际工作者参考。为使UML能适应某些方法、机构或用户的特殊需要，UML提供了扩展机制。
软件工程包括技术和管理两方面的内容，是管理与技术紧密结合的产物。只有在科学而严格的管理之下，先进的技术方法和优秀的软件工具才能真正发挥出它们的威力。因此，软件项目管理是大型软件工程项目成功的关键。软件项目管理从项目计划开始，而第1项计划活动就是估算。为了估算项目工作量和完成期限，首先需要预测软件规模。度量软件规模的常用技术主要有代码行技术和功能点技术。这两种技术各有优缺点，应该根据软件项目的特点及项目计划者对这两种技术的熟悉程度，选择适用的技术。根据项目的规模可以估算出完成项目所需的工作量，常用的估算模型有静态单变量模型、动态多变量模型和COCOMO2模型。为了做到较准确的项目估算，通常至少同时使用上述3种模型中的两种。通过比较和协调使用不同模型得出的估算值，有可能得到比较准确的估算结果。虽然软件项目估算并不是一门精确的科学，但是，把可靠的历史数据和系统化的技术结合起来，仍然能够提高估算的准确度。多数估算开发工作量的模型也同时提供了估算软件开发时间的方程，这样估算出的开发时间称为正常开发时间。增加从事开发工作的人员，可在一定程度上缩短开发时间。但是，不可能用增加人力的方法无限制地缩短开发时间。如果要求一个软件的开发时间远远少于它的正常开发时间，则开发成功的可能性几乎为零。项目管理者的目标是定义所有项目任务，识别出关键任务，跟踪关键任务的进展状况，以保证能够及时发现拖延进度的情况。为此，管理者必须制订一个足够详细的进度表，以便监督项目进度并控制整个项目。常用的制定进度计划的工具主要有Gantt图和工程网络两种。Gantt图具有历史悠久、直观简明、容易学习、容易绘制等优点。但是，它不能显式地表示各项任务彼此间的依赖关系，也不能显式地表示关键路径和关键任务，进度计划中的关键部分不明确。因此，在管理大型软件项目时，仅用 Gantt 图是不够的，不仅难以做出既节省资源又保证进度的计划，而且还容易发生差错。工程网络不仅能描绘任务的分解情况及每项作业的开始时间和结束时间，而且还能显式地表示各个作业彼此间的依赖关系。从工程网络图中容易识别出关键路径和关键任务，因此，工程网络是制订进度计划强有力的工具。通常，联合使用 Gantt 图和工程网络这两种工具来制订和管理进度计划，使它们互相补充、取长补短。
对任何软件项目而言，最关键的因素都是承担项目的人员。必须合理地组织项目组，使项目组有较高生产率。“最佳的”小组结构取决于管理风格、组里的人员数目和他们的技术水平，以及所承担的项目的难易程度。本章具体介绍了国外比较流行的民主制程序员组、主程序员组和现代程序员组的组织方式，讨论了不同组织方式的优缺点和适用范围。然后又从更广阔的角度进一步讨论了通用的软件项目组的组织结构问题。
对于软件开发项目来说，控制是十分重要的管理活动。本章主要讲述了风险管理、质量保证和配置管理3类软件工程控制活动。当对软件项目寄予较高期望时，通常都会进行风险分析。识别、预测、评估、监控和管理风险等方面花费的时间和人力，可以从许多方面得到回报：项目进展过程更平稳；跟踪和控制项目的能力更强；由于在问题发生之前已经做了周密计划而产生的信心。软件质量保证是在软件过程中的每一步都进行的“保护性活动”。软件质量保证措施主要有基于非执行的测试（也称为复审）、基于执行的测试（即通常所说的测试）和程序正确性证明。软件复审是最重要的软件质量保证活动之一，它的作用是在改正错误的成本相对比较低时就及时发现并排除错误。走查和审查是进行正式技术复审的两类具体方法。审查过程不仅步数比走查多，而且每个步骤都是正规的。由于在开发大型软件过程中所犯的错误绝大多数是规格说明错误或设计错误，而正式的技术复审发现这两类错误的有效性高达75%，因此是非常有效的软件质量保证方法。软件配置管理是应用于整个软件过程中的保护性活动，它是在软件整个生命期内管理变化的一组活动。软件配置由一组相互关联的对象组成，这些对象也称为软件配置项，它们是作为某些软件工程活动的结果而产生的。除了文档、程序和数据这些软件配置项之外，用于开发软件的开发环境也可置于配置控制之下。一旦一个配置对象已被开发出来并且通过了复审，它就变成了基线。对基线对象的修改导致建立该对象的新版本。版本控制是用于管理这些对象而使用的一组规程和工具。变化控制是一种规程活动，它能够在对配置对象进行修改时保证质量和一致性。配置审计是一项软件质量保证活动，它有助于确保在进行修改时仍然保持质量。状态报告向需要知道关于变化的信息的人，提供有关每项变化的信息。
软件维护是指在软件产品交付用户之后，为了改正软件测试阶段未发现的缺陷、改进软件产品的性能、补充软件产品的新功能等所进行的修改软件的过程。根据维护工作的特征以及维护目的的不同，软件维护可以分为四种类型：改正性维护、适应性维护、完善性维护和预防性维护。软件的可维护性是用来衡量对软件产品进行维护的难易程度的标准，它与软件的可理解性、可测试性、可修改性和可移植性密切相关。软件维护具有副作用，所以在进行软件维护时要慎之又慎。不能忽视软件文档在软件工程中的重要地位。合格的软件工程的文档应该具备针对性、精确性、清晰性、完整性、灵活性、可追溯性等特点。还应该清楚软件文档的分类，即用户文档、开发文档和管理文档三类。
基于数学的形式化规格说明技术，目前还没有在软件产业界广泛应用。但是，与欠形式化的方法比较起来，它确实有实质性的优点：形式化的规格说明可以用数学方法研究、验证（例如，一个正确的程序可以被证明满足其规格说明，两个规格说明可以被证明是等价的，规格说明中存在的某些形式的不完整性和不一致性可以被自动地检测出来）。此外，形式化的规格说明消除了二义性，而且它鼓励软件开发者在软件工程过程的早期阶段使用更严格的方法，从而可以减少差错。当然，形式化方法也有缺点：大多数形式化的规格说明主要关注于系统的功能和数据，而问题的时序、控制、行为等方面的需求却更难于表示。此外，形式化方法比欠形式化方法更难学习，不仅在培训阶段要花大量的投资，而且对某些软件工程师来说，它代表了一种“文化冲击”。把形式化方法和欠形式化方法有机地结合起来，使它们取长补短，应该能获得更理想的效果。本章讲述的应用形式化方法的准则，对于读者今后在实际工作中更好地利用形式化方法，可能是有帮助的。本章简要地介绍了有穷状态机、Petri网和Z语言3种典型的形式化方法，使读者对它们有初步的、概括的了解。当然，要想在实际工作中使用这些方法，还需要进一步研读有关的专著。
软件重用是降低软件整体成本、提高软件质量和开发生产率的合理而且有效的途径。可重用的软件成分包括软件的技术表示（如规格说明、体系结构模型、设计和代码）、文档、测试数据，甚至还包括与过程相关的任务（如审查技术）。重用过程包括两个并发的子过程：领域工程和软件工程。领域工程的目的是在特定的应用领域中标识、构造、分类和传播一组软件成分。然后，软件工程在开发新系统的过程中选取适当的软件成分供重用。分析和设计可重用构件的技术，使用与良好的软件工程实践中使用的相同的概念和原理。可重用构件应该在这样一个环境中设计：该环境为每个应用领域建立标准的数据结构、接口协议和程序体系结构。基于构件的开发使用数据交换模型、自动化工具、结构化存储以及底层对象模型，以利用已有的构件来构造应用系统。对象模型通常遵守一个或多个构件标准（如OMG/CORBA），构件标准定义了应用系统访问可重用对象的方式。软件构件的分类模式使得开发者能够发现和检索可重用的构件，这些分类模式遵照明确标识概念、内容和语境的 3C 模型。枚举分类、刻面分类和属性—值分类是众多构件分类模式中的典型代表。
