【软件测评师】08软件工程基础知识

#用于个人笔记整理

一、软件工程概述

1、软件危机

定义：软件危机是指落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题的现象。这一现象在20世纪60年代中期随着大容量、高速度计算机的出现而逐渐显现，主要表现为软件开发费用和进度失控、软件可靠性差、生产出来的软件难以维护等问题。

1）产生原因

用户需求不明确：在软件开发过程中，用户需求不明确或描述不精确，导致开发出来的软件不符合用户的实际需要。

缺乏有力的方法学和工具支持：软件开发过程复杂，依赖于开发人员的高度智力投入，缺乏系统化的开发方法和工具支持，使得软件开发产品的个性化问题加剧。

软件规模和复杂性增加：随着计算机应用范围的扩大，软件规模和复杂性急剧增加，大型软件开发项目需要组织大量人力共同完成，但管理人员和开发人员往往缺乏相应的经验，导致信息交流不畅，容易产生误解和错误。

2）解决途径

推广使用开发软件的成功技术和方法：通过总结和实践中的经验，推广使用更好的软件开发技术和方法。

开发和使用更好的软件工具：为软件开发提供自动的或半自动的软件支撑环境，提高开发效率和质量。

加强软件工程教育：提高软件开发人员的教育和训练水平，积累更多的经验。

强化项目管理：通过有效的项目管理手段，确保软件开发过程的顺利进行。

2、软件工程

定义：软件工程是一门研究用工程化方法构建和维护有效的、实用的和高质量的软件的学科。它涉及程序设计语言、数据库、软件开发工具、系统平台、标准、设计模式等方面。

3、三个要素

1）方法

软件工程方法为软件开发提供了“如何做”的技术。它包括了项目计划与估算、软件系统需求分析、数据结构、系统总体结构的设计、算法过程的设计、编码、测试以及维护等多个方面的任务。

2）工具

软件工具为软件工程方法提供了自动的或半自动的软件支撑环境。这些工具可以帮助开发人员更高效地进行软件开发、测试和维护工作。

3）过程

软件工程的过程则是将软件工程的方法和工具综合起来以达到合理、及时地进行计算机软件开发的目的。它包括了需求分析、设计、编码、测试、维护等多个阶段，每个阶段都有其特定的任务和输出。

二、软件生命周期

软件生命周期（Software Development Life Cycle, SDLC）是指从软件项目的启动到软件退役的整个过程。它涵盖了软件从概念、规划、需求分析、设计、编码、测试、部署、运行、维护直到最终被淘汰的所有阶段。每个阶段都有其特定的目标、活动、输出和可交付成果。

1、软件生命周期的主要阶段

1）可行性分析与项目开发计划

可行性分析：通过市场、技术、经济等多方面的分析，评估项目是否值得投资和开发。可行性分析报告是这一阶段的产物，它详细记录了分析过程、结果和结论。

项目开发计划：基于可行性分析的结果，制定详细的项目开发计划。项目计划书明确了项目的目标、范围、时间表、预算、资源需求、风险管理策略等关键要素。

2）需求分析

需求分析：与利益相关者（如用户、客户、业务分析师等）合作，收集、分析和定义软件系统的需求。需求包括功能性需求（系统应做什么）和非功能性需求（如性能、安全、易用性等）。

软件需求说明书：是需求分析的产物，它详细描述了软件系统的需求，为后续的设计和开发工作提供了基础。

系统分析-逻辑模型：在需求分析的基础上，构建系统的逻辑模型，包括业务流程、数据流、功能分解等，以便更好地理解系统的结构和行为。

3）概要设计

概要设计：在逻辑模型的基础上，进行系统的总体设计，包括划分系统模块、定义模块间的接口和交互方式、确定系统的总体架构等。

概要设计书：是概要设计的产物，它描述了系统的总体设计思路和方案，为后续的详细设计工作提供了指导。

4）详细设计

详细设计：在概要设计的基础上，对每个模块进行细化设计，包括数据结构、算法、接口实现等。详细设计确保了系统的可实施性和可维护性。

详细设计说明书：是详细设计的产物，它详细描述了每个模块的设计细节，为编码工作提供了详细的指导。

系统设计-物理模型：在某些情况下，详细设计阶段也会涉及物理模型的设计，如数据库的物理设计、网络布局等。但通常，物理模型的设计更多地与系统设计阶段（特别是与详细设计紧密相关的部分）相关联。

5）编码

编码：根据详细设计说明书，编写程序代码，实现系统的各个功能模块。编码过程中需要遵循编码规范，确保代码的可读性、可维护性和可扩展性。

物理模型-今实际运行的系统：编码完成后，通过集成测试、系统测试等阶段，形成可实际运行的系统。此时，系统的物理实现（如软件、硬件、网络等）已经就绪，可以部署到生产环境中进行运行。

6）测试

测试：对系统进行全面的测试，以验证其是否满足需求规格说明书中的要求。测试包括单元测试、集成测试、系统测试和验收测试等阶段。测试过程中需要发现并修复软件中的缺陷，确保系统的质量和稳定性。

7）维护

维护：系统上线后，需要进行长期的运行和维护工作。维护包括更正性维护（修复错误）、适应性维护（适应环境或业务需求变化）、完善性维护（增加新功能）和预防性维护（预防未来可能出现的问题）。维护是信息系统生命周期中花钱最多、延续时间最长的活动，因为它涉及到系统的长期稳定运行和持续改进。

2、软件瀑布模型将软件生命周期分为三个阶段

1）软件定义阶段

这一阶段的主要任务是进行问题的定义和可行性研究。通过详细调查现实世界要处理的对象（问题域），充分了解用户要求，确定软件开发的总体目标，给出软件的功能、性能、可靠性以及接口等方面的要求，完成需求规格说明书，制定完成开发任务的实施计划。

计划阶段还包括对软件开发的可行性进行分析，包括经济可行性、技术可行性和操作可行性。

2）开发阶段

在开发阶段，首先要进行需求分析，把软件功能和性能的总要求进一步具体化，得到系统的需求规格说明。

接着进行软件设计，包括总体设计和详细设计两个部分。总体设计解决的是软件系统的总体结构、划分功能模块、确定每个模块的功能以及模块间的调用关系等问题；详细设计则是对每个模块进行具体的设计，确定实现模块功能所需要的算法和数据结构。

然后是编码和单元测试阶段，即将设计结果转换成用某种程序设计语言书写的程序代码（即源程序），并进行单元测试，以检验模块是否按预定的要求正确地工作。

最后进行综合测试，通过各种类型的测试（如集成测试、系统测试等）使软件达到预定的要求。

3）运行阶段（即维护阶段）

软件在投入运行后，需要进行长期的运行和维护工作。这一阶段的主要任务是使软件持久地满足用户的需求，包括更正性维护（修复错误）、适应性维护（适应环境或业务需求变化）、完善性维护（增加新功能）和预防性维护（预防未来可能出现的问题）。

3、需求

1）需求的层次

1.业务需求

业务需求（Business Requirements）是从组织的角度出发，描述组织为什么需要这个系统，以及系统如何帮助组织实现其业务目标。这些需求通常与商业目标、策略、法规遵从性或行业规范等相关。例如，一个电商平台可能有一个业务需求，即“提高用户购物体验，以增加用户粘性和销售额”。

2.用户需求

用户需求（User Requirements）关注于最终用户如何使用系统以及他们对系统的期望。这些需求描述了用户想要系统做什么，以及他们如何与系统交互。例如，对于上述电商平台，用户需求可能包括“用户能够轻松搜索商品”、“用户能够查看商品详情和评论”以及“用户能够安全地完成支付流程”。

3.系统需求

系统需求（System Requirements）是将业务需求和用户需求转化为对软件系统的具体需求。这些需求涵盖了系统必须实现的功能、性能标准、可靠性要求等。

功能需求（Functional Requirements）：描述了系统必须执行的具体任务或操作。这些需求通常与系统的输入输出、处理逻辑和数据流相关。例如，“系统应支持用户通过关键词搜索商品”。

非功能需求（Non-Functional Requirements）：也称为质量属性需求，描述了系统除了功能需求之外的其他特性，如性能、可用性、安全性、可维护性等。例如，“系统响应时间不得超过2秒”，“系统应支持至少1000个并发用户”等。

设计约束（Design Constraints）：是指在设计系统时必须遵守的限制条件。这些约束可能来自于技术、环境、法规或其他外部因素。例如，“系统必须兼容IE11浏览器”，“系统必须遵循GDPR数据保护法规”等。

2）需求的特征

1. 完整性

完整性是指每一项需求都必须将所要实现的功能描述清楚，不能丢失一些信息。这意味着需求说明应该包含所有必要的细节，以便开发人员能够充分理解和实现这些功能。如果需求不完整，可能会导致设计缺陷、遗漏功能或系统性能问题。

2. 正确性

正确性是指每一项需求都必须准确地陈述其要开发的功能。正确性要求需求描述清晰、无歧义，并且与用户的期望和系统目标相一致。如果需求不正确，可能会导致开发出的系统无法满足用户需求，甚至引发错误或故障。

3. 可行性

可行性是指需求是否能被正常地实现，即每一项需求都必须是可以在已知系统和环境的权能和限制范围内实施的。这包括技术可行性、经济可行性和操作可行性等方面。如果需求在现有条件下无法实现，那么它就是不可行的，需要重新评估或调整。

4. 可验证性

可验证性是指每项需求都可以通过具体的用例或测试步骤来验证其是否正确。这要求需求描述具有可测试性，即能够制定出相应的测试用例来验证需求的实现情况。如果需求无法验证，那么就无法确保系统的正确性和可靠性。

5. 必要性

必要性是指每一项需求都应把客户真正所需要的和最终所需遵从的标准记录下来。这要求需求必须是基于用户或业务需求的真实反映，而不是基于开发人员的个人想法或假设。

6. 划分优先级

划分优先级是对所有的需求进行分类，分成不同等级的需求。这有助于在有限的资源条件下，优先实现最重要的功能，确保系统的核心价值和竞争力。

7. 无二义性

无二义性是指需求描述应该清晰明确，避免产生歧义或误解。这要求使用简洁明了的语言和术语，避免使用模糊或含糊的表述方式。

8. 简要性

简要性要求需求说明只包括一个需求，即简单和清晰地说明必须做的事情，应易于阅读和理解。为简要起见，需求的表述不应包含任何解释、原理、定义或系统描述。

9. 唯一性

唯一性是指同一个需求在需求文档中只应出现一次，以避免重复和混淆。这有助于保持需求文档的一致性和清晰度。

4、概要设计（总体设计）

1）设计软件系统总体结构

设计软件系统总体结构是概要设计的首要任务。它旨在将复杂的系统按照功能、业务逻辑或技术架构等因素进行分解，形成清晰、可管理的模块结构。这一过程通常采用层次结构的方式，将系统划分为高层模块、中层模块和底层模块，每个模块都负责不同的功能和任务。通过定义系统的总体结构，可以确保系统的可扩展性、可维护性和可重用性。

2）划分功能模块

功能模块是系统总体结构中的基本组成单元。在划分功能模块时，需要根据系统的业务需求、用户需求和系统目标，将系统划分为多个具有相对独立功能的模块。这些模块可以是按照业务流程划分的（如采购申请、供应商选择、订单处理等），也可以是按照功能特性划分的（如用户管理、商品管理、订单管理等）。每个模块都应该具有明确的职责和边界，以便于开发、测试和维护。

3）模块功能和职责

在划分功能模块后，需要为每个模块定义具体的功能和职责。这包括明确模块需要完成哪些任务、处理哪些数据、以及与其他模块之间的交互方式等。通过为模块定义明确的功能和职责，可以确保系统的整体功能和业务需求得到满足，并且每个模块都能够独立地完成其任务。

4）模块间的调用关系

模块间的调用关系是指模块之间相互调用和协作的方式。在系统设计时，需要明确每个模块之间的调用关系，以确保系统能够按照预定的业务流程和逻辑顺序正确地执行。这包括定义模块之间的接口、参数传递方式、调用时机等。通过合理的模块间调用关系设计，可以提高系统的可维护性和可扩展性。

5）模块间的信息传递

模块间的信息传递是指模块之间交换数据和信息的过程。在系统设计时，需要明确模块之间需要传递哪些数据和信息，以及传递的方式和时机。这包括定义数据格式、通信协议、消息传递机制等。通过合理的模块间信息传递设计，可以确保系统能够高效地处理和传输数据和信息，提高系统的性能和可靠性。

6）评价模块结构的质量

评价模块结构的质量是概要设计的重要任务之一。它旨在评估模块结构的合理性、有效性和可维护性等方面。在评价时，需要关注模块的大小适中、系统深度和宽度比例合理、模块的扇入扇出控制得当、模块独立性高（即高内聚低耦合）等方面。通过评价模块结构的质量，可以及时发现和纠正设计中的问题，提高系统的整体质量和可维护性。

7）数据结构及数据库设计

数据结构及数据库设计是概要设计中的另一个重要方面。它涉及对系统中数据的组织、存储和管理等方面的设计。在数据结构设计时，需要明确数据的组成、操作约束和数据之间的关系等方面；在数据库设计时，需要进行概念设计、逻辑设计和物理设计等方面的工作。通过合理的数据结构及数据库设计，可以确保系统能够高效地处理和存储数据，提高系统的性能和可靠性。

5、详细设计

1）代码设计

目标：确定软件系统的代码结构、模块划分、接口定义、数据结构和算法选择等。

模块划分：根据功能需求将系统划分为多个独立的模块，每个模块负责完成特定的任务。

接口定义：明确模块间如何交互，包括输入参数、输出参数、异常处理等。

数据结构：设计适合的数据结构来存储和处理数据，以提高程序的效率和可维护性。

算法选择：针对特定问题选择合适的算法，确保程序能高效运行。

2）输入/输出设计

目标：定义用户与系统之间的交互方式，包括输入数据的格式、验证规则以及输出结果的格式和展示方式。

输入设计：明确用户输入的数据类型、格式要求、错误处理机制等。

输出设计：设计输出结果的格式、布局、排序方式等，确保信息清晰易懂。

日志与报告：规划系统日志的生成与存储方式，以及生成定期报告或按需报告的格式和内容。

3）用户界面设计

目标：设计直观、易用、符合用户习惯的用户界面。

布局设计：确定界面元素的布局，包括菜单、按钮、文本框、列表等。

交互设计：设计用户与界面元素的交互方式，如点击、拖拽、滑动等。

视觉设计：选择合适的颜色、字体、图标等，提升界面的美观性和可读性。

响应式设计：确保界面在不同设备（如手机、平板、电脑）上都能良好显示和交互。

4）处理过程设计

目标：详细描述系统如何处理输入数据并产生输出结果的过程。

流程图：使用流程图或伪代码描述处理过程的逻辑流程。

状态转换图：对于需要处理状态变化的系统，设计状态转换图以描述系统在不同状态下的行为。

异常处理：设计异常处理机制，确保系统在遇到错误或异常情况时能够稳定运行并给出适当的反馈。

5）其他设计任务

1.标准化设计

编码规范：制定统一的编码规范，包括命名规则、注释规范、代码风格等。

数据标准：定义数据格式、编码标准等，确保数据的一致性和可交换性。

2.描述设计结果

设计文档：编写详细的设计文档，包括上述所有设计内容的描述和说明。

评审与反馈：组织设计评审会议，邀请相关人员对设计结果进行评审并提供反馈。

3.拟定实施方案

开发计划：根据设计结果制定详细的开发计划，包括任务分配、时间安排、资源需求等。

测试计划：制定测试计划，包括单元测试、集成测试、系统测试等阶段的测试内容、方法和预期结果。

部署与上线：规划系统的部署和上线流程，包括环境准备、数据迁移、用户培训等。

6、系统结构设计原则

1）分解-协调原则

定义：将整个系统视为一个整体，通过将其分解成多个相互关联的小模块或子系统来实现系统的整体目的和功能。这些模块或子系统在处理过程中需要相互协调，以确保系统整体功能的顺利实现。

目的：降低系统的复杂性，提高系统的可管理性和可维护性。

2）自顶向下的原则

定义：从系统的整体功能目标出发，逐层向下分解，先确定上层模块的功能，再逐步细化到下层模块。

目的：确保系统设计的逻辑性和层次性，使每个模块的功能明确且易于实现。

3）信息隐蔽、抽象的原则

定义：上层模块只规定下层模块需要完成的任务和模块间的协调关系，而不涉及下层模块的具体实现细节。通过抽象，将具体对象、行为和特征概括成更高级别的类或对象。

目的：提高模块的独立性和内部结构的合理性，降低模块间的耦合度，使系统更易于理解和维护。

4）一致性原则

定义：在系统设计的全过程中保持统一的规范、标准和文件模式。

目的：确保系统的各个部分在设计和实现上保持一致，降低因不一致性带来的错误和复杂性。

5）明确性原则

定义：每个模块的功能和接口必须明确，避免多重功能和无用接口的存在。

目的：提高系统的清晰度和可维护性，降低因接口不明确导致的错误和调试难度。

6）模块的扇入系数和扇出系数要合理

定义：

扇入系数：指直接调用该模块的上级模块的个数。扇入大表示模块的通用性强，复用机会高。

扇出系数：指该模块直接调用的下级模块的个数。扇出大表示模块复杂度高，需要控制和协调的模块多。

目的：保持扇入和扇出系数的合理性，以平衡模块的通用性和复杂度。一般来说，扇入和扇出系数都不宜过大或过小。

7）模块的规模适当

定义：模块的规模应根据实际需求来确定，既不过大也不过小。

目的：确保模块的功能单一且易于管理，同时避免因模块过小导致的接口复杂性和因模块过大导致的难以理解和维护的问题。

7、聚合

偶然聚合：模块完成的动作之间没有任何关系，或者仅仅是一种非常松散的关系。这种聚合方式下，模块内的各个组成部分几乎没有相互的联系或依赖。

逻辑聚合：模块内的各个组成部分的处理动作在逻辑上相似，但功能彼此不同或无关。

时间聚合：模块内各个组成部分的处理动作必须在同一时间内进行

过程聚合：模块内部的各个组成部分的处理动作各不相同，也没有很强的联系，但都受同一个控制流支配，决定它们的执行次序，有先后顺序。

通信聚合：模块内部各组成部分的处理动作因具有相同的输入数据或输出数据而聚合在一起。

顺序聚合：模块内各组成部分的执行顺序以确定顺序进行，不能随意改变。顺序聚合时往往模块内前一处理动作所产生的输出数据是后一个处理动作的输入数据，并且这些处理动作是与同一处理功能密切相关的。顺序聚合的凝聚度较高，仅次于功能聚合。

功能聚合：一个模块内各组成部分全都为执行同一个功能而存在，且只执行同一个功能。由于这种模块只完成一个单独的、能够确切定义的功能，它对确定的输入进行处理后，必然得到确定的输出结果，这是一种“黑箱”模块。功能聚合的聚合度最高。

8、耦合

非直接耦合：模块之间没有任何联系，这是耦合度最低的一种情况，但在实际软件设计中很少出现。

数据耦合：模块之间通过数据参数进行交换和传递。如果传递的是基本类型的数据，那么这种耦合的紧密程度较低；如果传递的是复杂类型的数据（如对象或结构体），那么耦合度会相应提高。

标记耦合：模块之间通过传递数据结构（如数组、结构体等）的指针或引用进行耦合。由于数据结构的内部细节对外部模块是可见的，因此这种耦合方式比数据耦合更紧密。

控制耦合：模块之间通过传递控制参数（如开关、标志位等）进行耦合。这种耦合方式允许一个模块控制另一个模块的行为，但通常不建议使用，因为它增加了模块间的依赖性和复杂性。

外部耦合：模块之间通过全局变量、共享的数据区或外部设备进行耦合。这种耦合方式通常会导致模块间的紧密依赖和难以维护的问题。

公共耦合：多个模块通过访问同一个全局数据结构（如数据库、共享文件等）进行耦合。这种耦合方式会导致模块间的相互依赖和难以预测的行为。

内容耦合：模块之间直接引用对方的数据结构或内部实现细节进行耦合。这种耦合方式是最紧密的，也是最难以维护和修改的。它通常会导致软件系统的可维护性和可扩展性大大降低。

9、高聚低耦

“高聚低耦”是软件设计中的一个重要原则，其中“高聚”指的是高内聚，即模块内部各组成部分之间的高凝聚程度，表示模块功能的专一化程度；“低耦”指的是低耦合，即模块之间或模块内的组成部分之间的低依赖程度。高内聚有助于减少模块间的交互，提高系统的可维护性和可重用性；低耦合则有助于减少模块间的相互影响，提高系统的稳定性和可扩展性。

考点一：确定聚合类型/聚合程度高低

题目：模块A的功能为: 从数据库中读出产品信息，修改后存回数据库，然后将修改记录写到维护文件中。该模块内聚类型为 (C)内聚。以下关于该类内聚的叙述中，正确的是 (C)

(1)A逻辑 B时间C过程D功能

(2)A是最低的内聚类型B是最高的内聚类型C不易于重用D模块独立性好

考法二：确定耦合类型/耦合程度高低

题目：以下关于模块耦合关系的叙述中，耦合程度最低的是 (A)其合类型为 (C) 耦合。

(1)

A模块M2根据模块M1传递如标记量的控制信息来确定M2执行哪部分语名

B模块M2直接访问块M1内部

C模块M1和模块M2用公共的数据结构

D模块M1和模块M2有部分代码是重叠的

(2)A数据B标记C 控制D内容

考点三：模块设计的原则

题目：以下关于模块化的叙述中，正确的是 (C)

(1)

A每个模块的规模越小越好，这样开发每个模块的成本就可以降低了

B每个模块的规模越大越好，这样模块之间的通信开销就会降低了

C应具有高内聚和低耦合的性质

D仅适用于结构化开发方法

10、软件运维

1）系统可维护性的评价指标

1.可理解性（Comprehensibility）

定义：可理解性是指软件系统的结构、代码和文档对于开发人员和维护人员的清晰度和易懂程度。高可理解性的软件更容易被理解，从而减少因理解错误导致的维护成本。

影响因素：包括代码的可读性（如变量命名、注释质量）、架构的清晰度（如模块划分、接口定义）以及文档的完整性和准确性。

2.可测试性（Testability）

定义：可测试性是指软件系统能够方便地通过测试来验证其正确性、完整性和可靠性的程度。高可测试性的软件能够降低测试成本，提高软件质量。

影响因素：包括测试用例的可设计性（如是否容易覆盖所有代码路径）、测试环境的搭建难度、以及测试结果的可追溯性和可重复性。

3.可修改性（Modifiability）

定义：可修改性是指在不引入错误或降低软件质量的前提下，对软件系统进行修改（如增加新功能、修复缺陷）的难易程度。高可修改性的软件能够更灵活地适应需求变化。

影响因素：包括代码的模块化程度、接口的设计质量、依赖关系的复杂度以及重构的难易程度。

2）按照软件维护的性质

1.纠错性维护（Corrective Maintenance）

定义：纠错性维护是指对软件系统中已发现的错误进行定位和修复的过程。这类维护通常是在软件发布后，根据用户反馈或测试发现的错误进行的。纠错性维护大约占总维护工作的20%，范围在17%到21%之间。这表明在软件维护周期中，修复错误是一个持续且重要的任务。

2.适应性维护（Adaptive Maintenance）

定义（按常规理解）：适应性维护（25%，范围18%到25%）是指对软件系统进行修改以适应新的或变化了的环境条件。

3.完善性维护（Perfective Maintenance）

定义：完善性维护是指对软件系统进行修改以改进其性能、增加新功能或提升用户满意度。这类维护通常基于用户的新需求或市场反馈进行。完善性维护是软件维护中最常见的类型，占总维护工作的比例最高，大约在50%到60%之间。

4.预防性维护（Preventive Maintenance）

定义：预防性维护是指为了预防未来可能出现的错误或问题而进行的软件修改。这包括重构代码、优化性能、更新依赖库等。预防性维护虽然占总维护工作的比例较小（约5%，范围4%），但它在提高软件长期稳定性和降低维护成本方面起着重要作用。

11、分析工具

1）数据流图（Data Flow Diagram, DFD）

数据流图是一种图形化工具，用于表示系统中数据的流动、存储、处理和外部实体之间的交互。它主要包括四种基本元素：

1. 数据流

定义：数据流是数据在系统内传播的路径，由一组成分固定的数据组成。如订票单可能包含旅客姓名、年龄、单位、身份证号、日期、目的地等数据项。

表示：在数据流图中，数据流用带箭头的线表示，箭头指向数据流动的方向。在其线旁标注数据流名。

2. 加工（处理）

定义：加工表示对数据进行的处理或变换，如计算、比较、存储等。

表示：在数据流图中，加工用圆圈表示，在圆圈内写上加工名。

3. 数据存储

定义：数据存储是数据在系统中存储的地方，可以是数据库、文件或其他存储介质。

表示：在数据流图中，数据存储用带有双线的矩形表示，通常标注存储的名称和类型。

4. 外部实体

定义：外部实体是指存在于系统之外，但与系统有数据交换的实体，如用户、其他系统或设备等。

表示：在数据流图中，外部实体用正方形表示，通常标注实体的名称和类型。

5.数据流图的基本原则

自外向内，自顶向下，逐层细化，完善求精：

这个原则强调从系统的整体视角开始，先绘制高层（或顶层）数据流图，然后逐层细化，深入到每个子系统的内部细节。通过逐层细化，可以逐步揭示系统的复杂性和内部逻辑。

保持父图与子图的平衡：

在细化过程中，必须确保父图（高层图）中的每个加工在子图中都有对应的展开，且子图中的数据流和加工应与父图保持一致，以维护整个数据流图的完整性和一致性。

保持数据守恒：

数据守恒原则要求数据流图中输入到加工的数据量必须等于从该加工输出的数据量（除了可能的存储外）。这确保了数据的完整性和正确性，避免了数据的丢失或增加。

加工细节隐藏：

在绘制数据流图时，应关注于数据的流动和加工的主要功能，而不是加工内部的详细实现。这样可以保持数据流图的简洁性，并便于不同层次的参与者理解和交流。

简化加工间的关系：

为了使数据流图更加清晰易懂，应尽量减少加工之间的复杂关系。如果两个加工之间的数据流过多或关系复杂，可能需要考虑进一步细化或重新组织这些加工。

均匀分解：

在细化数据流图时，应确保各个子图（或加工）的复杂度和信息量相对均衡。这有助于保持整个数据流图的平衡和一致性。

适当取名，避免空洞的名字：

数据流图中的每个元素（包括数据流、加工、数据存储和外部实体）都应具有清晰、准确的名称。这些名称应能够准确反映元素的功能和作用，避免使用空洞或模糊的名称。

表现的是数据流而不是控制流：

数据流图主要关注数据的流动和变换，而不是系统的控制逻辑。因此，在绘制数据流图时，应避免引入控制流的概念和元素。

每个加工必须既有输入数据流，又有输出数据流：

这个原则确保了加工的完整性和功能性。一个没有输入或输出的加工在逻辑上是不完整的，因为它不能实现任何数据变换或处理。因此，在绘制数据流图时，应确保每个加工都至少有一个输入数据流和一个输出数据流。

2）数据字典（Data Dictionary）

数据字典是对数据流图中所有元素（如数据流、数据存储、处理过程以及外部实体）的详细描述的集合。它提供了关于数据元素的名称、类型、长度、取值范围、来源和用途等信息的全面定义。

1. 数据流（Data Flow）

定义：数据流是数据结构在系统内传输的路径，表示了数据结构沿着系统的事务和处理过程中的传输流向。它描述了数据的动态特性，即数据在系统内部如何流动和变化。

特点：

方向性：数据流具有明确的方向，表示数据从何处流向何处。

传输量：除了传输的方向性，数据流还描述了数据传输量的信息，如单位时间内的传输次数或数据量。

作用：数据流图是描述数据流的主要工具，而数据字典则对数据流图中的每个数据流进行详细定义和说明，包括其来源、去向、传输的数据项及其含义等。

2. 数据项（Data Item）

定义：数据项是数据的最小组成单位，是不可再分的基本数据单位。它描述了数据的静态特性，即数据的具体内容和属性。

特点：

原子性：数据项是不可再分的，是数据的最基本单位。

详细性：数据项的定义通常包括数据项的名称、数据类型、长度、取值范围、默认值、是否允许为空等详细信息。

作用：数据项是构成数据结构的基础，通过定义数据项，可以明确系统中每个数据元素的具体内容和属性，为后续的数据库设计和系统开发提供基础。

3. 数据存储（Data Storage）

定义：数据存储是在事务和处理过程中，对数据所停留和保存的地方进行定义。它描述了数据在系统中的持久化存储方式，包括数据的存储位置、存储方式、存取频度等。

特点：

持久性：数据存储中的数据是持久化的，即使系统关闭或重启，数据也不会丢失。

存取方式：数据存储还包括对数据存取的频度信息和存取方式等相关内容的描述，如批处理、联机处理、检索、更新等。

作用：数据存储是数据流图中的一个重要元素，它定义了数据在系统中的存储方式和位置。通过定义数据存储，可以明确数据的存储需求和存储策略，为后续的数据库设计和数据管理提供依据。

4. 基本加工（Basic Processing）

定义：基本加工（或称处理过程）是对数据流图中每个处理过程的详细定义和说明。它描述了处理过程的功能、输入、输出以及处理逻辑等。

特点：

功能性：基本加工描述了处理过程的具体功能，即处理过程对数据执行的操作或转换。

输入输出：基本加工还包括其输入和输出数据流，以及处理过程中可能使用的数据存储。

处理逻辑：处理逻辑是基本加工的核心部分，它描述了处理过程如何对输入数据进行处理并产生输出数据。

作用：基本加工是数据流图中的重要组成部分，它定义了系统中每个处理过程的具体内容和行为。通过定义基本加工，可以明确系统的处理流程和数据处理逻辑，为后续的系统开发和维护提供指导。

3）结构化语言（Structured Language）

结构化语言是一种用于描述处理逻辑的半形式化语言，它结合了自然语言的易读性和编程语言的精确性。结构化语言使用明确的语句结构（如顺序、选择、循环）来表达处理逻辑，使得逻辑描述更加清晰和易于理解。

4）判定表（Decision Table）

判定表是一种用于描述复杂逻辑条件的表格，特别是当多个输入条件决定一个或多个输出时。它清晰地列出了所有可能的输入条件组合以及每种组合对应的输出动作。判定表有助于确保逻辑的全面性和准确性。

5）判定树（Decision Tree）

判定树是一种图形化工具，用于表示基于一系列条件判断做出决策的过程。它从一个根节点开始，每个节点代表一个条件判断，根据条件的真假分支到不同的子节点，直到达到叶子节点（代表最终的决策或输出）。判定树提供了一种直观的方式来展示复杂的决策逻辑。

12、设计工具

1）概要设计

1. 结构图（Structure Chart）

结构图主要用于表示软件系统的模块结构，包括模块之间的层次关系、调用关系和数据流向。它帮助开发者理解系统的整体架构和模块间的依赖关系。

2. 层次图（Hierarchy Diagram）

层次图也是展示系统结构的一种方式，但它更侧重于展示系统的层次性。它通过将系统划分为不同的层次，每个层次包含一组相关的模块或组件，来展示系统的组织方式。

3. HIPO图（Hierarchy Plus Input/Process/Output）

HIPO图结合了层次图和IPO图（输入/处理/输出图）的概念。它首先通过层次图展示系统的模块层次结构，然后对每个模块使用IPO图来详细描述其输入、处理和输出。

2）详细设计

详细设计关注于如何将概要设计阶段的模块或子系统进一步细化为具体的程序实现。

1. 程序流程图（Flowchart）

程序流程图是最早用于表示程序逻辑的图示方法，通过图形符号（如矩形表示处理、菱形表示决策、椭圆表示开始和结束等）来展示程序的执行流程。

2. 程序框图（Program Block Diagram）

程序框图与程序流程图类似，但更侧重于展示程序的结构化特点，如顺序、选择和循环结构。它有助于减少流程图的复杂性，提高程序的可读性。

3. 盒图 (N-S图，Nassi-Shneiderman Diagram)

盒图是一种严格的结构化程序设计工具，它使用矩形（或称为盒子）来表示处理步骤，并通过箭头连接这些盒子来展示程序的逻辑顺序。盒图不允许使用流程线直接从一个步骤跳到另一个步骤，从而强制程序员遵循结构化编程的原则。

4. PAD图（Problem Analysis Diagram）

PAD图是一种二维树状结构的图表，用于表示程序的逻辑结构。它从左到右展开，每个节点代表一个处理步骤，节点之间的连线表示控制流。PAD图易于阅读和转换为程序代码，特别是在处理嵌套和重复结构时。

5. PDL（Pseudo-code Description Language）

PDL，即伪码描述语言，不是一种图形表示方法，而是一种介于自然语言和编程语言之间的表示方法。它使用类似于编程语言的语法和符号，但更接近于自然语言，以便更清晰地描述算法或程序逻辑。PDL有助于开发者在详细设计阶段将设计思想转化为可执行的代码。

三、软件开发模型

1、瀑布模型

软件开发模型中的瀑布模型是一种传统的软件开发方法，也被称为经典的生命周期模型。该模型将软件开发过程分为一系列线性和有序的阶段，每个阶段的输出是下一个阶段的输入，开发过程呈现为一种顺序流程。

1）定义与核心思想

定义：瀑布模型是一种软件开发过程模型，它将软件开发过程划分为需求分析、设计、实现、测试和维护等有序阶段。

核心思想：按工序将问题化简，将功能的实现与设计分开，便于分工协作。即采用结构化的分析与设计方法将逻辑实现与物理实现分开。

2）阶段划分

瀑布模型将软件生命周期划分为以下六个基本活动：

制定计划：明确项目的目标、范围、时间、资源等。

需求分析：进行需求调研和分析，明确项目的需求和目标，收集和整理用户需求和功能要求，编写需求文档。

软件设计：包括系统设计和详细设计，制定系统架构和模块设计，编写详细设计文档。

程序编写（实现）：根据设计文档进行编码和测试，包括编写源代码、进行单元测试和集成测试，编写测试文档。

软件测试：进行系统测试和验收测试，包括对系统功能、性能、安全性等方面进行测试，编写测试报告。

运行维护：对系统进行维护和优化，包括进行故障排查和修复、进行性能优化和升级、更新文档等。

3）特点与优势

明确的阶段划分：每个阶段都有明确的输入和输出，以及质量保证的标准。

顺序性：开发过程呈现为一种顺序流程，一旦进入下一个阶段就难以回到前一个阶段。

文档化：开发过程需要详细记录和管理，确保开发过程可重复和可维护。

质量控制：注重每个阶段的质量控制和测试，确保产品的质量和稳定性。

适用于需求稳定的项目：能够为项目管理提供有力支持，特别适用于大型项目。

4）局限性

不适应需求变化：对于需求变更的响应能力较弱，难以应对需求变化和创新性项目。

线性流程缺乏灵活性：开发过程是一种线性流程，不允许阶段之间的交叉或重叠。

风险较高：测试和调试放在最后阶段，导致问题在后期才能发现和解决，成本和风险较高。

文档工作量大：阶段之间产生大量的文档，极大地增加了工作量。

5）应用与选择

瀑布模型适用于需求明确、稳定、低风险的项目。然而，在现代软件开发中，由于需求变化频繁和不确定性增加，瀑布模型已逐渐被其他更灵活的模型所取代，如敏捷开发模型。但是，在某些特定情况下，如大型复杂系统或需要严格质量控制的项目中，瀑布模型仍然具有一定的应用价值。

2、V模型

V模型，也被称为快速应用开发模型，是软件开发过程中的一个重要模型。它因其模型构图形似字母V而得名，特别是在软件测试领域具有显著意义。

1）定义与核心思想

V模型是一种将软件开发过程与测试过程紧密结合的模型。它强调在整个软件项目生命周期中，每个开发阶段都对应一个测试阶段，以确保软件的质量和可靠性。V模型的核心思想是尽早地和不断地进行软件测试，测试对象不仅包括程序，还包括需求、设计等。

2）阶段划分

V模型将软件开发过程分为以下主要阶段，每个阶段都对应一个测试阶段：

需求分析：

开发活动：收集、分析、记录和确认客户的需求。

测试活动：需求评审，确保需求的准确性和完整性。

概要设计：

开发活动：设计软件系统的总体结构、主要模块和模块之间的关系。

测试活动：设计评审，确保设计符合需求并具备可行性。

详细设计：

开发活动：进行每个模块的详细设计，包括接口、算法、数据结构等。

测试活动：设计测试用例，为后续的单元测试做准备。

软件编码：

开发活动：根据设计文档编写代码。

测试活动：单元测试，对每个模块进行独立测试。

集成测试：

开发活动：将各个模块集成在一起，形成完整的系统。

测试活动：集成测试，检查模块之间的接口和交互是否正确。

系统测试：

开发活动：完成系统的集成和调试。

测试活动：系统测试，对整个系统进行全面测试，验证系统是否满足需求。

验收测试：

开发活动：准备系统交付给客户。

测试活动：验收测试，由客户或第三方进行，确保系统满足合同要求。

3）特点与优势

强调测试和验证：V模型将测试活动贯穿于整个开发过程，确保软件质量和可靠性。

明确的开发和测试对应关系：每个开发阶段都对应一个测试阶段，有助于团队理解和控制开发过程。

提高效率和生产力：通过早期发现和解决问题，减少重新开发和修复的成本。

增强风险管理：通过测试和验证，团队可以更早地发现和应对潜在风险。

可追溯性：每个开发阶段都能追溯到相应的测试阶段和文档，有助于管理和控制开发过程。

4）局限性

刚性开发过程：V模型的开发过程比较刚性，不够灵活。对于需求变化较快的项目，可能需要回到前期规划阶段，增加开发时间和成本。

文档工作量大：V模型需要大量的文档支持，包括需求文档、设计文档、测试计划和测试报告等，增加了工作量。

对测试人员要求高：测试阶段的重要性使得测试人员需要具备较高的技能和经验。

5）适用场景

V模型适用于需求明确、开发周期较长、对软件质量和可靠性要求较高的项目。在这些项目中，V模型能够提供清晰的开发过程框架和严格的测试机制，确保软件的质量和可靠性。

3、原型模型

原型模型是指在设计或开发过程中，通过搭建一个部分或完整的模型来展示最终产品的外观、功能和特性。它是一个用于验证设计方案或解决方案的重要工具，旨在帮助设计师、开发人员和客户更好地理解和沟通需求和解决方案。

1）定义与核心思想

原型模型的核心思想在于通过构建一个可操作的模型，让相关人员（包括设计师、开发人员、客户等）能够直观地看到产品的实际效果，从而在早期阶段就发现并解决问题，减少后期的风险和成本。

2）类型

原型模型可以是物理模型，如3D打印或手工制作的物品，也可以是虚拟模型，如软件中的交互式原型或网站的原型。这些不同类型的原型模型各有优势，可以根据具体需求和场景进行选择。

3）优点

提高沟通效率：通过原型模型，设计师、开发人员和客户可以更直观地理解产品的外观、功能和特性，从而加快沟通速度，减少误解。

减少错误：在设计和开发的早期阶段就通过原型模型进行测试和验证，可以及时发现并纠正错误，避免在后期才发现并修复成本更高的问题。

节省时间和成本：通过原型模型，可以更早地确定产品的需求和设计方案，从而避免不必要的返工和修改，节省时间和成本。

增加用户满意度：原型模型允许用户在实际操作前就对产品有一个初步的了解和体验，从而增加用户的满意度和接受度。

4）应用场景

原型模型在各种行业和应用场景中都有广泛的应用，包括但不限于：

产品设计：在产品设计阶段，通过制作原型可以更直观地展示产品的外观、功能和操作流程，帮助设计团队验证设计方案的可行性和实用性。

软件开发：在软件开发过程中，原型模型可以用于展示软件的界面、功能和交互方式，帮助开发人员和客户更好地理解软件的需求和设计。

游戏开发：在游戏开发领域，原型模型可以用于快速制作游戏原型，以验证游戏的概念、玩法和用户体验。

教育培训：原型模型也常用于教育培训领域，用于展示概念、演示操作流程，帮助学生更好地理解和掌握知识。

5）局限性

尽管原型模型具有诸多优点，但也存在一些局限性：

制作成本：制作高质量的原型模型可能需要较高的成本和时间投入。

技术限制：在某些领域或场景中，由于技术限制可能无法制作出完全符合预期的原型模型。

用户反馈的局限性：用户可能对原型模型的理解存在偏差或局限，导致反馈不够准确或全面。

4、增量模型

增量模型是一种逐步增加功能和特性的软件开发过程模型，它将待开发的软件系统模块化，将每个模块作为一个增量组件，从而分批次地分析、设计、编码和测试这些增量组件。以下是增量模型的详细介绍：

1）定义与特点

定义：增量模型（Incremental Model），又称为渐增模型或有计划的产品改进模型，是一种逐步构建和交付软件产品的方法。它从一组给定的需求开始，通过构造一系列可执行中间版本来实施开发活动。

特点：

模块化：将软件系统划分为多个增量模块，每个模块独立开发并测试。

逐步交付：每完成一个增量模块，就将其集成到系统中并交付给用户，用户可以逐步使用新功能。

灵活调整：根据用户反馈和需求变化，可以灵活调整后续增量模块的开发计划。

2）开发过程

增量模型的开发过程通常包括以下几个阶段：

需求分析：明确软件系统的整体需求和各个增量模块的具体需求。

划分增量：将软件系统划分为多个增量模块，每个模块包含一组相关的功能和特性。

设计与开发：对每个增量模块进行详细设计、编码和测试。

集成与测试：将完成的增量模块集成到系统中，并进行系统测试以确保各模块之间的兼容性和整体功能的正确性。

用户反馈：收集用户对已交付增量模块的反馈意见，并根据反馈进行必要的调整和优化。

重复开发：继续下一个增量模块的开发、集成、测试和用户反馈过程，直到所有增量模块都完成并集成到系统中。

3）优缺点

优点：

降低风险：通过分批次交付软件产品，可以降低整体项目的开发风险。一旦某个增量模块出现问题，可以及时调整和修复，而不会影响到整个软件系统的交付。

快速响应：能够快速响应用户需求的变化。当用户需求发生变化时，可以及时调整后续增量模块的开发计划以满足新的需求。

提高用户满意度：用户可以逐步使用新功能并提供反馈意见，这有助于开发者及时了解用户需求并调整开发方向从而提高用户满意度。

缺点：

需求管理复杂：如果需求频繁变化或增量模块之间的依赖关系复杂可能会导致项目范围不断扩大增加管理复杂性。

软件结构复杂：由于增量模型是逐步构建软件系统的因此需要确保各个增量模块之间的兼容性和整体结构的合理性这可能会增加软件结构的复杂性。

技术难度较高：要求软件具备开放式的体系结构以便能够灵活地加入新的增量模块同时还需要确保加入新模块时不会破坏已构造好的系统部分这对技术要求较高。

4）适用场景

增量模型适用于以下场景：

需求不稳定或频繁变化的项目。

需要逐步交付软件产品并收集用户反馈的项目。

项目规模较大且难以一次性完成开发的项目。

5、螺旋模型

螺旋模型（Spiral Model）是一种演化软件开发过程模型，它兼顾了快速原型的迭代特征以及瀑布模型的系统化与严格监控。以下是对螺旋模型的详细解析：

1）定义与特点

定义：螺旋模型是一种将软件开发过程分为多个迭代周期，每个周期都包括计划、风险分析、实现和评审四个阶段的软件开发模型。

特点：

迭代周期：螺旋模型将软件开发过程划分为多个迭代周期，每个周期都产生一个可执行的软件版本。

风险分析：在每个迭代周期的开始，都进行风险识别、风险分析和风险控制，这是螺旋模型最显著的特点之一。

原型构建：在每个迭代阶段构建原型，用以减小风险并验证设计思路。

灵活性：螺旋模型允许在项目的各个阶段进行变更，具有较高的灵活性。

2）开发过程

螺旋模型的每个迭代周期都包括以下四个阶段：

计划：确定该阶段的目标，完成这些目标的选择方案及其约束条件。

风险分析：从风险角度分析方案的开发策略，努力排除各种潜在的风险。有时需要通过建造原型来完成风险分析。

工程实现：根据计划进行实际的编码和测试工作，实现该阶段的目标。

评审：评估该阶段的结果，包括产品的性能、风险的处理情况等，并设计下一个阶段的计划。

3）适用范围

螺旋模型特别适用于以下类型的软件开发项目：

大型、复杂、高风险的软件开发项目：螺旋模型的风险分析机制使得这类项目能够及时发现和解决问题，降低项目失败的风险。

需求不明确或经常变更的项目：螺旋模型的灵活性使得它能够在需求变化时快速调整开发计划。

内部的大规模软件开发：由于螺旋模型要求客户接受和相信风险分析并做出反应，因此它更适合于内部项目，客户更容易理解和接受风险分析的结果。

4）优缺点

优点：

设计上的灵活性：可以在项目的各个阶段进行变更。

以小的分段来构建大型系统：使成本计算变得简单容易。

客户始终参与：保证了项目不偏离正确方向以及项目的可控性。

强调风险分析：有助于及时识别和解决潜在问题。

缺点：

风险分析要求高：需要开发人员具有丰富的风险评估经验和专门知识。

客户接受度问题：要求客户接受和相信风险分析并做出反应可能存在一定的困难。

模型复杂性：螺旋模型包含多个阶段和迭代周期，可能增加项目的复杂性。

6、喷泉模型

喷泉模型（Fountain Model）是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程。该模型的特点和主要方面可以归纳如下：

1）模型概述

动力与驱动：喷泉模型以用户需求为动力，以对象为驱动，强调软件开发的整个过程围绕用户需求进行，并通过对象技术来推动开发进程。

开发过程：喷泉模型认为软件开发过程自下而上周期的各阶段是相互重叠和多次反复的，就像水喷上去又可以落下来，类似一个喷泉。各个开发阶段没有特定的次序要求，并且可以交互进行，可以在某个开发阶段中随时补充其他任何开发阶段中的遗漏。

无间隙性：喷泉模型强调各活动之间无明显边界，如设计和实现之间没有明显的界限，这也称为“喷泉模型的无间隙性”。由于对象概念的引入，表达分析、设计及实现等活动只用对象类和关系，从而可以较容易地实现活动的迭代和无间隙。

2）特点

迭代性：喷泉模型的各个阶段没有明显的界限，开发人员可以同步进行开发。软件的某个部分通常被重复多次，相关对象在每次迭代中随之加入渐进的软件成分。

高效性：该模型可以提高软件项目开发效率，节省开发时间，特别适应于面向对象的软件开发过程。

需求驱动：喷泉模型以用户需求为动力，强调在开发过程中不断根据用户需求进行迭代和调整。

3）优缺点

优点

提高开发效率：由于各阶段可以并行和迭代进行，减少了等待时间，提高了开发效率。

适应需求变化：能够灵活地应对需求的变化，及时在开发过程中进行调整。

面向对象：特别适用于面向对象的软件开发过程，能够充分发挥对象技术的优势。

缺点

管理复杂：由于各阶段重叠进行，需要大量的开发人员同时参与，增加了项目管理的复杂性。

文档管理困难：要求严格管理文档，以记录每次迭代和变更的内容，使得审核的难度加大。

成本较高：由于需要更多的开发人员和更复杂的项目管理，可能会增加项目的开发成本。

4）应用场景

喷泉模型特别适用于那些需求不明确或经常变更的软件开发项目。通过迭代和灵活的开发过程，可以逐步明确需求并调整开发计划，从而降低项目风险并提高开发成功率。

四、软件开发方法

1、统一过程

统一过程（Unified Process，简称UP）是一种迭代增量式的软件开发方法论，它强调将系统开发过程分为一系列的迭代周期，每个周期都包括了需求分析、设计、编码、测试和部署等活动。该方法论由Rational公司（现为IBM的一部分）在20世纪90年代初开发，并和UML（统一建模语言）一起发布，旨在提供一种以最佳实践为基础的、易于自定义的软件开发过程。

1）统一过程的核心特点

1.迭代增量开发

将软件开发过程划分为多个迭代周期，每个周期都会产生一个可执行的软件部分。

每个迭代周期都会增加新的功能或改进现有的功能，使得开发团队能够快速响应需求变化，并逐步构建完整的系统。

2.用例驱动

用例作为系统功能需求的基础，描述了系统的功能需求。

每个迭代周期都可以从用例中选取一些来实现，有助于明确需求，并帮助开发团队集中精力在最重要的功能上。

3.架构中心

强调对系统的架构进行设计和规划，确保系统具有合适的可扩展性、可维护性和性能等特性。

4.风险驱动

关注项目风险，并在开发过程中采取相应的措施来降低风险。

通过早期的风险分析和迭代的方式，可以更好地应对不确定性。

5.高度可配置

UP是一个框架，而不是一个具体的过程。它可以根据项目的特性和团队的需求进行定制和配置。

6.提高质量和降低风险

通过迭代和增量的开发方法，可以更早地发现问题，减少缺陷，从而提高产品质量。

同时，通过以风险为驱动的过程，可以更早地识别和解决风险，降低项目失败的风险。

2）统一过程的阶段

1.初始阶段（Inception）

确定项目的范围和边界，识别系统的关键用例，展示系统的候选架构，估计项目费用和时间，评估项目风险。

2.细化阶段（Elaboration）

分析系统问题领域，建立软件架构基础，完成架构设计，淘汰最高风险元素。

3.构建阶段（Construction）

开发剩余的构建，进行构建组装与测试。

4.交付阶段（Transition）

进行β测试，制作发布版本，用户文档定稿，确认新系统，培训、调整产品。

3）模型元素

1.角色（Role）

定义：角色描述了在软件开发过程中，某个人或小组的行为与职责。

实例：如体系结构师、设计人员、实现人员、测试员、配置管理人员等，每个角色都有其特定的职责和工作内容。

2.活动（Activity）

定义：活动是一个有明确目的的独立工作单元，是软件开发过程中的具体任务。

示例：需求分析、设计、编码、测试、部署等活动。

3.制品（Artifact）

定义：制品是活动生成、创建或修改的一段信息，是软件开发过程中的产出物。

示例：需求文档、设计模型、源代码、测试报告等。

4.工作流（Workflow）

定义：工作流描述了一个有意义的连续的活动序列，它显示了角色之间的关系，并产生了有价值的制品。

特点：每个工作流都围绕特定的软件开发阶段或任务展开，确保开发过程的连贯性和有序性。

2、敏捷方法

敏捷方法是一种轻型软件开发方法，自20世纪90年代开始逐渐引起关注。它强调快速开发和有效适应需求变化，不要求严格遵循传统的软件开发流程。

1）特点

快速开发：强调通过短周期的迭代开发，快速将产品或功能推向市场。

需求适应性：支持在项目开发过程中随时调整需求，以更好地满足市场变化。

紧密协作：要求程序开发人员、业务人员、客户方之间紧密协作、面对面沟通。

持续交付：频繁交付新的软件版本，确保客户能够尽早获得价值。

2）价值观与原则

个体和交互重于过程和工具：强调团队成员之间的密切合作和交流，而非过分依赖工具或流程。

工作的软件重于详尽的文档：注重实际可运行的软件，而非详尽的文档。

客户合作重于合同谈判：鼓励客户参与到开发过程中，通过持续反馈和合作来确保产品的质量和满意度。

响应变化重于遵循计划：敏捷方法能够灵活应对需求变化，即使在开发后期也能进行调整。

此外，敏捷方法还遵循一系列原则，如尽早并持续交付有价值的软件、欣然面对需求变化、频繁地交付可工作的软件、业务人员与开发人员紧密合作等。

3）典型代表

敏捷方法的典型代表包括极限编程（XP）、测试驱动开发（TDD）等。这些方法在实践中得到了广泛应用，并形成了各自独特的开发流程和最佳实践。

4）适用范围

敏捷项目管理方法适用于快速变化和不确定性高的项目环境，如软件开发、信息技术、互联网、市场营销、教育培训等领域。在这些领域中，需求往往不是静态的，而是随着时间、市场、用户的变化而不断发生变化。采用敏捷方法可以更好地应对这些变化，提高项目成功率。

5）优缺点

优点：

快速交付价值：敏捷开发方法强调快速迭代和持续交付，可以更快地将产品或功能推向市场。

灵活性和适应性：允许团队根据需求变化和反馈进行调整，更好地应对不确定性和变化的环境。

强调用户参与：鼓励用户参与到开发过程中，通过持续反馈和合作来确保产品的质量和用户满意度。

高效的沟通和协作：倡导团队成员之间的密切合作和交流，加强团队的沟通效率和协作能力。

更好的风险管理：通过迭代和持续集成的方式，能够及早发现和解决问题，减少项目失败的风险。

缺点：

对团队成员的要求较高：需要团队成员具备良好的自组织能力、快速学习和适应新技术的能力。

可能导致过度迭代：快速迭代可能导致团队过度关注细节和持续变动，影响项目的进展和稳定性。

需要高效的沟通和协调：如果团队成员分布在不同地理位置或时区，会增加沟通和协调的难度。

需要明确的产品愿景和需求：虽然强调灵活性和变化，但也需要有清晰的产品愿景和需求来确保方向正确。

对管理层的支持和理解要求高：需要管理层对敏捷开发原则的理解和支持，以及提供必要的资源和环境来支持团队的工作。

3、结构化方法

结构化方法是一种在软件开发中广泛使用的传统方法，它强调开发方法的结构合理性以及所开发软件的结构合理性。

1）定义与特点

定义：

结构化方法，也称为结构化分析与设计方法（Structured Analysis and Design Method，简称SAD），是针对数据流建立数据模型、功能模型和行为模型，是一种基于数据流的设计方法。

特点：

面向数据流：结构化方法主要围绕数据流进行分析和设计，通过数据流图（DFD）等工具表示系统的逻辑模型。

模块化：将复杂的系统划分为若干个简单的模块，每个模块可以独立地开发、测试和维护，这有助于降低系统的复杂性和提高开发效率。

自顶向下，逐步求精：从整体到局部，逐步细化设计过程，确保每一步都符合系统需求。

文档化：开发过程中强调文档的编写和规范化，以便于系统的维护和管理。

2）主要阶段

结构化方法通常包括以下几个主要阶段：

需求分析：通过与客户沟通，收集并理解客户的需求，形成需求规格说明书（SRS）。

系统分析：基于需求分析的结果，进行系统的逻辑设计，包括数据流图、数据字典等文档的编写。

系统设计：将系统逻辑设计转化为物理设计，包括体系结构设计、接口设计、数据设计和过程设计等任务。

系统实现：根据系统设计的结果，进行编程和测试工作，完成系统的开发工作。

系统维护：在系统运行期间，对系统进行必要的维护和更新工作。

3）优点与缺点

优点：

整体性：从系统整体全局出发，强调在整体优化的前提下进行分析和设计，保证了系统的整体性和目标一致性。

适用性：用户至上，根据用户需求开发，系统具有较强的适用性。

规范性：严格区分工作阶段，每个阶段都有其明确的任务，便于系统开发的管理和控制。

文档化：文档规范化，有利于系统的维护。

缺点：

需求把握难度：由于用户的素质或系统分析员和管理者之间的沟通问题，在系统分析阶段很难把握用户的真正需求，易导致开发出不是用户需要的系统。

开发周期长：开发周期较长，一方面使得用户在较长时间内不能得到一个实际可运行的系统，另一方面，难于适应环境变化。

功能锁定难度：结构化程度较低的系统，在开发初期难于锁定功能要求。

4）结构化设计原则

1. 模块独立性原则

内部凝聚性强：所划分的模块其内部的各个部分之间应该紧密相连，共同实现一个明确的功能。这种高内聚性有助于减少模块内部的复杂性和错误传播的可能性。

模块间联系少：模块之间应该尽量减少直接的依赖和联系，即模块间的耦合度要低。这样可以使得模块更加独立，便于单独测试和维护。

2. 层次化调用原则

上下级调用关系：模块之间的连接只能存在上下级之间的调用关系，即一个模块可以调用其下级模块，但不能直接调用同级或上级模块。这种层次化的调用关系有助于形成清晰的系统结构。

禁止横向联系：同级模块之间不应该存在直接的调用关系，这有助于减少模块间的相互依赖和耦合度。

3. 树状结构原则

整体呈树状结构：整个系统应该呈现出一种树状结构，即有一个明确的根模块，然后逐层向下划分出子模块。这种结构有助于清晰地表达系统的层次关系和模块间的调用关系。

禁止网状和交叉调用：系统中不允许出现网状结构或交叉调用关系，这有助于避免模块间的复杂依赖和潜在的冲突。

4. 模块编码与归档原则

严格分类编码：所有模块（包括后继IPO图等）都必须进行严格的分类编码，以便于管理和维护。编码应该能够清晰地反映模块的层次关系、功能特点等信息。

建立归档文件：对于每个模块，都应该建立相应的归档文件，包括模块的源代码、设计文档、测试报告等。这些归档文件是系统维护、升级和重用的重要基础。

五、MVC

MVC（Model-View-Controller）是一种软件设计模式，用于将应用程序分割成三个主要逻辑组件：模型（Model）、视图（View）和控制器（Controller），以提高应用程序的可维护性、可扩展性和可重用性。这种模式最初是在1970年代由Trygve Reenskaug在施乐帕克研究中心（Xerox PARC）开发的，但直到Web开发兴起后才变得广为人知。

1、MVC 组件

模型（Model）

代表应用程序的数据结构，是业务逻辑和数据的核心。

负责处理数据逻辑和业务规则。

可以是数据访问层（如数据库）的抽象，也可以是内存中的数据结构。

通常与数据库交互，执行数据的增删改查（CRUD）操作。

视图（View）

呈现给用户的界面，负责显示应用程序的输出。

可以是HTML页面、XML文档或任何类型的用户接口。

通常从模型中获取数据，但不应包含业务逻辑。

当模型数据变化时，视图会更新以反映这些变化。

控制器（Controller）

接受用户的输入并调用模型和视图去完成用户的需求。

控制器本身不输出任何内容，也不进行任何数据的处理，它只是接收请求并决定调用哪个模型组件去处理请求，然后再确定用哪个视图来显示模型处理返回的数据。

是模型和视图之间的桥梁，控制程序的流程。

2、MVC 的工作原理

用户通过视图层与应用程序进行交互，发起请求（如点击按钮、提交表单等）。

控制器接收用户的输入，并决定调用哪个模型组件去处理请求。

模型根据业务逻辑处理数据，并与数据库进行交互。

控制器将模型处理后的数据传递给视图。

视图展示数据给用户。

3、MVC 的优点

低耦合：模型、视图和控制器之间的耦合度低，便于修改和扩展。

高内聚：每个组件都负责单一的任务，提高了代码的可读性和可维护性。

可重用性：视图和控制器可以独立于模型进行重用。

易于测试和维护：由于组件之间的低耦合性，使得测试和维护变得更加容易。

六、能力成熟度模型

在软件工程和测试领域，CMMI（能力成熟度模型集成）和TMM（测试成熟度模型）都是用于评估和改进组织在软件开发和测试过程中的成熟度的模型。

1、CMMI级别

CMMI共有五个级别，从低到高依次为：

初始级（Initial）

特点：软件开发和维护过程处于最低的成熟度水平，管理过程通常未被定义，项目的成功主要依赖于个别人员的能力和经验。软件开发过程不稳定，缺乏一致性和可重复性。

可重复级（Repeatable）

特点：软件开发过程已经形成了标准化的基本流程，并且已经在组织中得到了广泛的应用。这使得软件过程具有一定的可重复性和稳定性。

已定义级（Defined）

特点：软件开发过程已经被完全定义和规范化，并且与其他组织的流程进行了比较和改进。组织已经建立了一套完整的项目管理流程和标准，并且这些流程和标准已经形成了文档，可以被组织内的其他项目所参考和借鉴。

已管理级（Managed）

特点：在已管理级，组织已经建立了一套基本的项目管理流程和标准，但这些流程和标准可能还未得到充分的量化。组织开始注重对项目过程的管理和控制，以提高项目的稳定性和可预测性。

注意：在部分资料中，已管理级与可重复级有所混淆，但根据CMMI的官方定义，已管理级是高于可重复级的一个级别。

优化级（Optimizing）

特点：组织持续地追求卓越，并通过创新和优化来改进过程。在优化级，组织能够定量地评估过程的效果，并采取措施来持续改进过程的稳定性和预测性。

2、TMM级别

TMM也由五个级别组成，从低到高依次为：

初始级（Initial）

特点：测试活动是混乱无序的，通常测试被认为是调试的一部分，在编码结束后自发进行。缺少资源、工具和受过良好培训的测试员工。产品往往不能按时发布，预算超支并无法达到预期的交付质量。

阶段定义级（Phase Definition）

特点：测试过程被明确定义，并且明确将测试与调试区分开。测试成为了一个已管理的过程，有全公司或全项目的测试策略和测试计划。测试的设计和执行是根据规格设计和选择的，具有独立的测试环境。

集成级（Integration）

特点：测试被完全集成到软件开发生命周期中，而不仅仅是其中的一个阶段。测试活动与软件开发的其他阶段紧密协作，共同确保软件的质量。

管理和度量级（Management and Measurement）

特点：测试被定义为全面的可测度的过程。组织能够定量地评估测试过程的效果，并根据数据和指标进行过程改进。

优化缺陷预防和质量控制级（Optimization for Defect Prevention and Quality Control）

特点：组织通过创新和优化来持续改进测试过程，以提高缺陷预防和质量控制的能力。此级别是TMM中的最高级别，代表了测试过程的卓越水平。

七、分层体系结构

1、分层体系结构

在软件工程中，分层体系结构是一种常见且重要的设计方式，它将软件系统划分为多个层次，每个层次都承担特定的角色和功能，并通过接口与其他层次进行交互。这种结构有助于降低系统的复杂性，提高开发效率，增强系统的可维护性和可扩展性。

1）分层体系结构的定义

分层体系结构（Layered Architecture）是一种将软件系统划分为多个水平层的设计方法，每一层都有清晰的角色和分工，且层与层之间通过接口进行通信。这种结构使得系统的不同部分可以独立地开发、测试和维护，从而提高了软件开发的效率和质量。

2）分层体系结构的优点

降低复杂性：通过将系统划分为多个层次，每个层次都关注于特定的任务和功能，从而降低了系统的整体复杂性。

提高开发效率：开发人员可以专注于某一层次的实现，而不必关心其他层次的具体细节，从而提高了开发效率。

增强可维护性：由于层与层之间通过接口进行通信，因此当某一层次发生变化时，通常只需要修改该层次及其相邻层次的接口，而不会影响到其他层次，从而增强了系统的可维护性。

提高可扩展性：当需要扩展系统功能时，可以在现有层次的基础上添加新的层次或修改现有层次的接口，而不需要对整个系统进行大规模的修改。

3）分层体系结构的实现

明确层次划分：根据系统的需求和功能特点，合理划分层次结构，确保每个层次都承担特定的角色和功能。

定义清晰的接口：层与层之间通过接口进行通信，因此需要定义清晰的接口规范和协议，以确保层与层之间的正确交互。

保持层间独立：尽量减少层与层之间的依赖关系，使每个层次都能独立地开发、测试和维护。

合理设计层内组件：在每个层次内部，合理设计组件和模块，确保它们之间的耦合度低、内聚度高。

2、三层分层体系结构

三层分层体系结构是软件开发中常用的一种架构模式，旨在通过将系统划分为不同的逻辑层来实现“高内聚、低耦合”的设计目标。这种体系结构通常包括三个主要层次：表示层（UI）、业务逻辑层（BLL）和数据访问层（DAL）。

1. 表示层（UI）

定义：表示层是呈现给用户的界面，是用户与系统交互的窗口。

功能：

接收用户的输入和指令。

显示数据和业务处理的结果。

提供用户友好的交互界面。

特点：

通常采用图形用户界面（GUI）或网页界面（Web UI）。

可能包含表单、按钮、文本框等控件。

依赖于业务逻辑层进行数据交换和处理。

典型技术或应用：

JDBC（Java Database Connectivity）：虽然JDBC本身是一种用于Java应用程序与数据库连接的API，但在客户层中，它可能不是直接用于构建用户界面的技术，而是作为后端数据库连接的一部分。然而，在Java应用程序中，JDBC可以用于从数据库检索数据并在表示层中显示这些数据。

DHTML（Dynamic HyperText Markup Language）：DHTML是HTML、CSS和JavaScript的集合，用于创建动态和交互式的网页。在Web应用程序中，DHTML是构建用户界面的关键技术之一。

Applet：Applet是Java编写的小程序，可以嵌入到HTML页面中，在支持Java的浏览器中运行。Applet曾经广泛用于在Web页面上提供动态内容和交互性，但随着Web技术的发展，其使用已逐渐减少。

2. 业务逻辑层（BLL）

定义：业务逻辑层是系统的核心部分，负责处理具体的业务逻辑和数据操作。

功能：

从数据访问层获取数据并进行处理。

根据业务需求进行数据转换和计算。

调用数据访问层进行数据持久化操作。

提供给表示层所需的数据和业务处理结果。

特点：

不直接与数据库交互，而是通过数据访问层进行。

封装了业务规则和数据操作逻辑，提高了系统的可维护性和可扩展性。

可能包含多个业务组件或服务，每个组件负责特定的业务功能。

典型技术或应用：

CGI（Common Gateway Interface）：CGI是一种标准协议，用于Web服务器与外部应用程序（如C/C++、Perl、Python等编写的程序）之间的通信。CGI程序可以处理来自Web表单的数据，执行特定的任务，并将结果返回给Web服务器。

SAPI（Server Application Programming Interface）：SAPI是一个比较通用的术语，可能指的是特定服务器平台上的应用程序编程接口。

ASP（Active Server Pages）、PHP、JSP（JavaServer Pages）：这些技术都是用于构建动态Web内容的服务器端脚本语言。它们允许开发者将HTML、CSS、JavaScript与服务器端代码混合在一起，以生成动态的Web页面。

EJB（Enterprise JavaBeans）、Servlet：EJB和Servlet是Java EE平台上的两种重要技术，用于构建企业级应用程序。EJB提供了分布式计算的支持，而Servlet则用于处理HTTP请求并生成响应。

3. 数据访问层（DAL）

定义：数据访问层负责与数据库进行交互，执行数据的增删改查（CRUD）操作。

功能：

封装数据库访问细节，如连接数据库、执行SQL语句等。

提供数据持久化服务，确保数据的完整性和一致性。

响应业务逻辑层的数据请求，并返回处理结果。

特点：

直接操作数据库，是系统与数据库之间的桥梁。

实现了数据访问的抽象和封装，降低了业务逻辑层对数据库操作的依赖。

可能包含多个数据访问对象（DAO），每个对象对应数据库中的一个表或视图。

典型技术或应用：

Oracle和SQL Server都是关系型数据库管理系统的例子，它们属于数据层的范畴。这些数据库系统提供了数据存储、查询、更新和删除等功能，是系统数据持久化的关键部分。

4. 三层分层体系结构的优点

高内聚、低耦合：各层之间职责明确，降低了层与层之间的依赖关系，提高了系统的可维护性和可扩展性。

易于开发和维护：开发人员可以专注于某一层的开发，降低了开发难度和复杂度。同时，由于各层之间相对独立，因此维护和升级也更加方便。

提高系统性能：通过将数据处理逻辑集中在业务逻辑层和数据访问层，可以减少表示层的数据处理负担，提高系统的响应速度和性能。

增强系统安全性：通过封装数据访问细节和业务逻辑处理，可以更好地控制对数据的访问权限和操作权限，提高系统的安全性。

3、体系风格

1. 数据流风格

数据流风格主要关注数据在系统中的流动和处理方式。

批处理序列：在这种风格中，数据被组织成一系列的批处理任务，每个任务按顺序执行，处理完一批数据后再进行下一批。这种风格适用于需要大量数据处理且可以容忍一定延迟的场景。

管道/过滤器：数据通过一系列的过滤器（处理单元）进行传输和处理，每个过滤器接收输入数据流，进行处理后输出新的数据流。这种风格适用于数据流处理系统，如数据流分析、图像处理等。

2. 调用/返回风格

调用/返回风格主要关注系统中构件之间的调用关系。

主程序/子程序：在这种风格中，系统被划分为一个主程序和多个子程序，主程序负责控制流程，调用子程序执行特定任务。子程序完成任务后返回结果给主程序。这种风格简单直观，易于理解和实现。

面向对象风格：面向对象风格将数据和操作封装在对象中，通过对象之间的交互来实现系统功能。这种风格提高了代码的重用性和可维护性。

层次结构：在层次结构中，系统被划分为多个层次，每个层次为上一层提供服务，并使用下一层的服务。这种风格有助于将复杂问题分解为更小的子问题，降低系统的复杂度。

3. 独立构件风格

独立构件风格强调构件之间的独立性和松耦合。

进程通讯：在这种风格中，构件是独立运行的进程，它们之间通过消息传递进行通信。这种风格提高了系统的可扩展性和容错性。

事件系统：事件系统风格中，构件不直接调用其他构件，而是通过触发或监听事件来进行交互。这种风格适用于需要高度解耦和灵活性的系统。

4. 虚拟机风格

虚拟机风格通过模拟一个完整的计算机环境来执行程序。

解释器：解释器逐条执行程序代码，将其翻译成机器语言并执行。这种风格适用于需要动态执行代码或跨平台运行的场景。

基于规则的系统：基于规则的系统通过一组规则来控制系统的行为。当满足特定条件时，相应的规则会被触发并执行相应的操作。这种风格适用于需要处理复杂逻辑和决策的场景。

5. 仓库风格

仓库风格以数据为中心，通过共享的数据仓库来组织系统。

数据库系统：数据库系统通过数据库管理系统来管理数据，提供数据的存储、查询、更新和删除等功能。这种风格适用于需要处理大量数据和复杂查询的场景。

超文本系统：超文本系统通过超链接将信息组织成网状结构，用户可以通过点击链接来浏览相关信息。这种风格适用于需要呈现非线性信息和支持用户自由导航的场景。

黑板系统：黑板系统是一种用于解决复杂问题的框架，它通过黑板来共享问题和解决方案的状态信息。不同的知识源（构件）通过读取和修改黑板上的信息来协作解决问题。这种风格适用于需要解决复杂、非结构化问题的场景。

八、面向对象

面向对象编程（OOP）是一种编程范式，它使用“对象”来设计软件。这些对象具有状态（数据）和行为（代码）。以下是您提到的面向对象基础概念的简要解释：

1、对象

对象是类的实例，它包含了数据和可以操作这些数据的函数（方法）。在面向对象编程中，对象是程序的基本单元，代表可以操作的数据和数据的操作。

2、类

类是对一组具有相同属性和方法的对象的抽象。它定义了对象的蓝图，包括对象的属性（数据成员）和可以执行的操作（成员函数或方法）。通过类，可以创建多个具有相同属性和方法的对象。

3、抽象

抽象是隐藏内部实现细节，只显示对外接口的过程。在面向对象编程中，抽象允许我们定义接口，而不需要关心具体的实现细节。例如，通过抽象类，我们可以定义一组方法但不实现它们，让子类去实现这些方法。

4、封装

封装是将数据（属性）和操作数据的方法（行为）捆绑在一起，形成一个独立的单元（即对象）。封装可以隐藏对象的属性和实现细节，仅对外公开接口。这样，外部代码只能通过预定的接口来访问对象，而不能直接访问其内部数据。

5、继承

继承是一种允许我们根据一个或多个已存在的类来定义新类的方式。继承可以复用现有的代码，并在新类中添加或修改功能。在面向对象编程中，继承允许我们定义一个类（子类）来继承另一个类（父类）的属性和方法，并且可以添加新的属性或重写现有方法。

6、多态

多态意味着“多种形态”。在面向对象编程中，多态允许我们以统一的方式处理不同类型的对象。这通常通过接口或抽象类实现，允许子类提供特定于它们自己的实现。多态性提高了代码的灵活性和可重用性。

7、接口

接口是一种引用类型，它是一种抽象的类型，用于指定一组方法，但不提供这些方法的实现。接口是一种形式的契约，任何实现了接口的类都必须遵守这个契约，即必须实现接口中定义的所有方法。接口是实现多态性的重要手段之一。

8、消息

在面向对象编程中，对象之间通过发送和接收消息来通信。当一个对象调用另一个对象的方法时，实际上是在向该对象发送一条消息，请求其执行某个操作。消息传递是面向对象编程中对象间通信的基本机制。

9、组件

组件是面向对象编程和软件架构中的一个概念，它代表了一个独立的、可替换的、与系统中其他部分交互的软件模块。组件可以是对象、类、库或更大的软件单元，它们共同协作以实现系统的整体功能。

10、复用

复用是指在软件开发中重复使用已有的代码、设计或文档等资源的过程。面向对象编程中的封装、继承和多态等特性为代码复用提供了强有力的支持。通过复用，可以提高开发效率，减少重复劳动，提高软件质量。

九、UML

UML（统一建模语言）是一种用于对软件密集系统进行可视化建模的标准语言。它帮助开发者理解、设计、构建和文档化软件系统。UML由三个主要要素组成：事物（Things）、关系（Relationships）和图（Diagrams）。

1、事物（Things）

事物是UML模型中的基本构造块，它们代表了模型中的抽象概念。UML中的事物分为四种类型：

结构事物（Structural Things）

类（Class）：描述具有相同属性、方法和关系的对象集合。

接口（Interface）：定义了一组操作的规范，但不实现它们。

协作（Collaboration）：描述一组对象间的交互以及它们共同完成任务的方式（UML 2.x中已移除）。

用例（Use Case）：描述系统的一个功能单元，即系统外部的一个用户与系统之间的一次交互。

组件（Component）：描述物理的或逻辑的软件部件。

节点（Node）：描述在运行时存在的物理设备或软件在其中的执行环境。

行为事物（Behavioral Things）

交互（Interaction）：描述对象间为实现特定目的而进行的交互序列，如顺序图、协作图。

状态机（State Machine）：描述对象在其生命周期中的行为序列。

分组事物（Grouping Things）

包（Package）：将元素组织成组的机制，便于组织和封装。

注释事物（Annotational Things）

注释（Note）：为模型中的元素提供附加信息的机制。

2、关系（Relationships）

关系是UML中用来描述事物之间如何相互关联的。UML定义了四种主要的关系类型：

依赖（Dependency）：表示两个事物之间的一种使用关系，其中一个事物（依赖者）发生变化会影响到另一个事物（被依赖者）。

关联（Association）：表示两个或多个类之间的一种结构关系，用于描述对象之间的连接。

泛化（Generalization）：表示一种继承关系，即特殊化与一般化的关系。一个类是另一个类的一般化，而另一个类是前者的一个特殊种类。

实现（Realization）：表示类与接口之间的实现关系，即一个类实现了某个接口。

3、图（Diagrams）

UML图是用来表示UML模型的可视化工具。它们使用UML的元素（事物和关系）来展示系统的不同方面。静态建模机制：类图、对象图、构件图、配置图 (部署图)。动态建模机制：用例图、状态图、活动图、顺序图(序列图)、协作图(通信图)。UML定义了九种不同类型的图：

用例图（Use Case Diagram）：展示系统的功能需求，主要描述参与者（用户）与系统用例之间的关系。两种使用用例图的方式：对系统的语境建模、对系统的需求建模。用例之间的三种关系：包含关系、扩展关系、泛化关系。

类图（Class Diagram）：展示系统中的类、接口以及它们之间的关系，如关联、依赖、泛化等。使用类图的三种方式：对系统的词汇建模、对简单的协作建模、对逻辑数据库模式建模。

对象图（Object Diagram）：展示类图中类或接口的特定实例及其关系。

状态图（State Diagram）：描述一个对象的所有可能状态以及事件发生时状态的转移。

活动图（Activity Diagram）：描述满足用例要求所要进行的活动以及活动间的约束关系。

序列图（Sequence Diagram）：展示对象之间的交互顺序，强调对象间消息的时间顺序。

协作图（Collaboration Diagram）：与序列图相似，但更侧重于展示对象间的组织结构和交互关系。

组件图（Component Diagram）：展示系统组件的物理结构、组件间的依赖关系以及组件的接口。

部署图（Deployment Diagram）：展示软件在物理硬件上的部署情况，即系统的物理结构。