软件工程复习,广泛的解析落实
软件工程层次图
支持软件工程的根基在于质量关注点。
软件工程的基础是过程层。
软件工程方法为构建软件提供技术上的解决方法。
软件工程工具为过程和方法提供自动化或半自动化的支持
软件过程定义
软件过程是工作产品构建时所执行的一系列活动、动作和任务的集合。活动主要实现宽泛的目标。动作包含了主要工作产品生产过程中的一系列任务。任务关注小而明确的目标，能够产生实际产品。
2.2.1 过程框架
一个通用的软件工程过程框架通常包括以下5个活动：沟通、策划、建模、构建、部署。
沟通。在技术工作开始之前，和客户（及其他利益相关者）的沟通与协作是极其重要的；其目的是理解利益相关者的项目目标，并收集需求以定义软件特性和功能。策划。也可以称为软件项目计划，它定义和描述了软件工程工作，包括需要执行的技术任务、可能的风险、资源需求、工作产品和工作进度计划。建模。利用模型来更好地理解软件需求，并完成符合这些需求的软件设计。构建。它包括编码（手写的或者自动生成的）和测试以发现编码中的错误。部署。软件（全部或者部分增量）交付到用户，用户对其进行评测并给出反馈意见。
软件工程的基本要素包括方法、工具和（ A ）。
A、过程
B、软件系统
C、硬件环境
D、人员
软件工程的基本要素包括方法、工具和过程，并且人员也是一个重要的要素。
软件过程包括五个框架活动——沟通、策划、建模、构建和部署。其中，哪个活动主要涉及确定软件系统的需求、功能和性能等方面的规范和描述？（ C ）
A、沟通
B、策划
C、建模
D、构建
E、部署
建模活动主要涉及确定软件系统的需求、功能和性能等方面的规范和描述。在软件过程中，建模活动通过使用不同的建模技术和工具，如需求建模、系统建模、数据建模等，来对软件系统进行抽象和描述，以便于后续的开发、测试和部署工作。
软件工程是一门迅速发展的新兴学科，现已经成为计算机科学的一个重要分支。软件工程是一种层次化的技术，软件工程包括（ C ）三个要素。
A、技术、方法和工具
B、封装、继承、多态
C、方法、工具和过程
D、过程、模型、方法
软件需求确定以后，进入由软件设计、编码(Coding)和（ B ）三个关联阶段构成的软件开发(develupmeni)阶段。
A、需求分析
B、软件测试
C、系统定义
D、软件维护
可行性研究又称为可行性分析，目的是避免盲目投资，减少不必要的损失。下列（ C ）不是可行性分析阶段的任务。
A、确定项目规模和目标
B、确定资源(人力、硬件、软件等)需求
C、建立新系统的高层逻辑模型
D、提出实现高层逻辑模型的各种方案，并推荐可行的方案
可行性研究是在项目初期进行的一项工作，旨在评估项目的可行性和可行性方案的可行性。在可行性分析阶段，主要任务包括确定项目规模和目标、确定资源需求（人力、硬件、软件等）、提出实现方案并推荐可行的方案。
"建立新系统的高层逻辑模型"不是可行性分析阶段的任务，而是在系统设计阶段进行的工作，用于描述系统的逻辑结构和组成部分。
可行性研究主要从以下几个方面进行研究：（ A ）
A、技术可行性，经济可行性，操作可行性
B、技术可行性，经济可行性，系统可行性
C、经济可行性，系统可行性，操作可行性
D、经济可行性，系统可行性，时间可行性
关键：需求准确定义且稳定
前提：需求必须是准确定义和相对稳定的
各项活动规定为固定顺序链接的工作，即从用户需求规格说明开始，
顺序地通过沟通、策划、建模、构建和部署过程，最终提供完整软件和持续技术支持。
特点：
阶段间具有顺序性和依赖性；推迟实现的观点：前面步骤完成后才考虑实现；质量保证的观点：每一阶段都需要有文档以及经过评审；
优点：适用于小型项目，强调文档化和可追溯性，提供了明确的开发流程
问题：
瀑布模型需要客户明确需求，但客户难以准确表达所有需求。得到可执行程序的时间太迟(项目接近尾声)，对于系统中存在的重大缺陷，如果在可执行程序评审之前没有被发现，将可能造成惨重损失。可能导致一些阻塞(开发团队的一些成员要等待另一些成员工作完成，尤其在开始和结束阶段，花在等待的时间可能超过生产性工作时间)过于理想化，难以应对开发过程中的各种不确定因素。
缺点：难以适应需求变化、开发周期较长、不适用于大型项目
V模型
关键：瀑布模型pro（将验证确认动作应用于软件早期）
瀑布模型与V模型没有本质区别，V模型提供了一种将验证确认动作应用于早期软件工程工作中的方法
关键：需求不明确；迫切需要；后续细化改进，每个增量都是可运行程序；
前提：需求不明确或迫切需要为用户迅速提供一套功能有限的软件产品，然后再后续版本中再进行细化和扩展功能。
关键：业务和需求经常变化；是迭代的过程模型
前提：开发过程中，业务和产品需求经常变化；严格的交付时间；核心产品需求确定，但是系统扩展的细节问题却没有定义
演化模型是迭代的过程模型，每次迭代产生软件的一个更完整的版本
缺点
大多数的项目管理和估算技术是基于活动的线性布局，所以并不完全适用于演化软件过程。没有确定演化的最快速度，不定带来的不确定演化模型侧重灵活性和可延展性，而不是高质量。这种说法听起来很惊人。演化模型优先追求开发速度，而不是零缺陷。
原型开发
前提：
客户提出基本功能，但是未详细定义详细需求（输入输出）
开发人员对于开发的运行环境、算法效率、兼容性、人机交互不确定
流程：
在原型系统不断调整以满足各种利益相关者需求的过程中，采用迭代技术，同时也使开发者逐步清楚用户的需求。
问题：
因为是原型，所以需要重新搭建，但是利益相关者不愿意并要求对软件稍加修改变成一个可运行的产品，最终软件开发管理往往陷入失效。
由于一开始的快速搭建，对于效力会有一个向下的适应，最终造成并不完美的选择变成了系统的组成部分
螺旋模型
关键：循环方式；结合瀑布模型与原型模型，但独有风险分析；与增量模型不同，不需要每个增量都是可运行程序；开发大型系统和软件的理想方法
风险驱动的软件开发模型：
采用循环的方式，逐步加深系统定义和实现的深度（原型开发的迭代性质）；确定一系列里程碑，确保利益相关者都支持系统解决方案（瀑布模型的系统性和可控性）；
将瀑布模型与原型的迭代特征结合,并加入两种模型均忽略了的风险分析,和增量模型不同，它并不要求每一个增量都是可运行的程序
开发大型系统和软件的理想方法，更好地应对风险
以下情况应该选用什么过程模型？
（1）客户不太清楚待开发的系统需要提供什么服务。
需求不明确原型模型
（2）开发团队了解待开发软件的相关领域知识，尽管此系统庞大，但其较已经开发的系统差异并不大。
需求明确瀑布模型
（3）软件的功能是把读入的浮点数开平方，所得到的结果应该精确到小数点后4位。
需求很明确瀑布模型
（4）开发一个已发布软件的新版本，公司规定了严格的完成期限，并对外公布。
新版本 + 严格期限增量模型
（5）汽车防锁死刹车控制系统
考虑技术风险 + 循环的方式逐步加深系统定义和实现深度螺旋模型
（6）大学记账系统，准备替换一个已存在的系统
需求很明确瀑布模型
（7）一个位于火车站的交互式火车车次查询系统
“交互式”体现的是沟通上的迭代，需求不明确原型模型
在一个为机器视觉领域服务的公司中，你被指派为项目管理者。你的工作是管理一个软件产品的开发，该产品能够加速图像识别的速度。这项工作是面向研究及开发（R&D）的，但其目标是在下一年内生成产品。你会选择那种软件过程模型？BD
A、XP
B、增量模型
C、Scrum
D、原型模型
你被指派为一个小型软件产品公司的项目管理者。你的工作是建造一个结合了虚拟现实的硬件和高超的体验的游戏软件。因为家庭娱乐市场的竞争非常激烈，且团队人员有限，完成这项工作的压力很大。你不会选择那种软件过程模型？BC
A、增量模型
B、螺旋模型
C、瀑布模型
D、原型模型
（21）如果客户要求交付产品的时间非常迫切、团队中有几个项目同时在开发，我们最好采用（ A ）来开发这个项目。
A、增量模型
B、螺旋模型
C、瀑布模型
D、原型模型
增量模型是一种软件开发方法，它将项目划分为多个小的增量部分，每个增量都是一个可交付的、完整的功能子集。在每个增量中，团队可以按照优先级完成必要的功能和特性。这种方法可以让团队快速交付部分功能，并在后续增量中逐步完善和改进。对于紧迫的项目交付需求和并行开发的情况，增量模型可以帮助团队以迅速且可控的方式进行开发，并及时满足客户的要求。
具有风险分析的软件生命周期模型是（ C ）。
A、瀑布模型
B、喷泉模型
C、螺旋模型
D、增量模型
螺旋模型是一种迭代的软件开发模型，结合瀑布模型与原型模型，但独有风险分析，强调风险管理和迭代开发。在螺旋模型中，项目经理和开发团队通过多个迭代周期来逐步开发和完善软件系统。每个迭代周期包括四个主要阶段：计划、风险分析、工程开发和评审。
以下哪个不属于瀑布模型的优点？（ D ）
A、适用于小型项目
B、强调文档化和可追溯性
C、提供了明确的开发流程
D、强调迭代和快速原型开发
瀑布模型是一种线性的开发模型，按照固定的阶段顺序进行开发，不支持迭代和快速原型开发。瀑布模型的优点包括适用于小型项目、强调文档化和可追溯性、提供了明确的开发流程。
以下哪个不瀑布模型的缺点？（ D ）
A、难以适应需求变化
B、开发周期较长
C、不适用于大型项目
D、不适用于团队协作
瀑布模型的缺点包括难以适应需求变化、开发周期较长、不适用于大型项目。然而，瀑布模型并没有明确指出不适用于团队协作。在实际项目中，瀑布模型可以适用于团队协作，但要求各个团队成员在各个阶段按顺序进行工作，以确保项目的顺利进行。
瀑布模型本质上是一种（ A ）。
A、线性顺序模型
B、顺序迭代模型
C、线性迭代模型
D、增量开发模型
瀑布模型是软件开发过程中最早被提出的一种经典模型，它采用线性顺序的方式进行软件开发。在瀑布模型中，各个阶段按照顺序依次进行，每个阶段的输出作为下一个阶段的输入，形成了一个明确的开发流程。
在软件开发过程中，原型模型和瀑布模型是两种常见的开发方法。以下哪个描述是正确的？（ A ）
A、原型模型采用迭代和增量的方式进行开发，允许快速原型验证和反馈，适用于需求不明确或经常变化的项目。瀑布模型是一种线性顺序的开发方法，按照预先定义的阶段顺序进行开发。
B、原型模型和瀑布模型都是一种迭代的开发方法，根据项目需求的复杂性和规模选择使用。原型模型更适合小型项目，而瀑布模型适用于大型项目。
C、原型模型和瀑布模型是完全相同的开发方法，只是名称不同而已。
D、原型模型和瀑布模型都是一种敏捷开发方法，强调团队合作和持续交付。它们在开发过程中没有本质上的区别。
B错误，原型模型和瀑布模型适用的项目规模和复杂性没有直接关联。
C错误，原型模型和瀑布模型是两种不同的开发方法，不仅仅是名称的差异。
D错误，原型模型和瀑布模型虽然都有敏捷的特点，但它们在开发过程和方法上有本质的区别。
如果需求不明确，我们最好采用（ A ）来明确需求。
A、原型模型
B、瀑布模型
C、增量模型
D、螺旋模型
原型模型是一种迭代开发方法，它通过构建初步的原型来帮助用户和开发团队更好地理解需求，并在需求澄清的过程中进行迭代和改进。通过原型模型，用户可以提供反馈和建议，开发团队可以根据反馈进行调整和完善，从而逐渐明确和理解需求。
软件开发的结构化生命周期方法将软件生命周期划分成（ A ）。
A、计划阶段、开发阶段、运行阶段
B、计划阶段、编程阶段、测试阶段
C、总体设计、详细设计、编程调试
D、需求分析、功能定义、系统设计
软件开发的结构化生命周期方法将软件生命周期划分成计划阶段、开发阶段、运行阶段。
计划阶段包括问题定义、可行性研究和需求分析；
开发阶段包括概要设计、详细设计、编码和测试；
运行阶段包括部署和维护。
在一个为遗传工程领域服务的公司中，你被指派为项目管理者。你的工作是管理一个软件产品的开发，该产品能够加速基因分类的速度。这项工作是面向研究及开发（R&D）的，但其目标是在下一年内生成产品。你会选择那种软件过程模型？
你会选择那种团队结构？
你被指派为一个小型软件产品公司的项目管理者。你的工作是建造一个具有突破性的产品，该产品结合了虚拟现实的硬件和高超的软件。因为家庭娱乐市场的竞争非常激烈，完成这项工作的压力很大。你会选择那种软件过程模型？
你会选择那种团队结构？
请简要描述三个适于采用瀑布模型的软件项目。
传统的桌面应用程序：对于传统的桌面应用程序，通常具有明确的功能需求和固定的技术环境。这种项目通常遵循传统的软件开发生命周期，并且在项目开始之前能够明确定义所有的功能和规范。瀑布模型可以帮助团队在每个阶段有序地进行设计、开发和测试。嵌入式系统开发：嵌入式系统往往需要与硬件进行密切集成，其开发过程需要严格的计划和预测。在这种情况下，瀑布模型可以帮助团队在每个阶段有序地完成需求分析、设计、编码和测试，并最终交付一个完整且稳定的嵌入式系统。传统的企业级软件开发：某些企业级软件项目对于稳定性和可靠性的要求较高，而且对于变更的容忍度相对较低。这些项目通常有明确的业务需求和规范，并需要按计划进行开发和交付。在这种情况下，瀑布模型可以帮助团队按照预定的计划进行逐个阶段的开发和测试，确保项目按时交付。
5.1 什么是敏捷
敏捷的变更：
敏捷的拥护者认为，一个设计良好的敏捷过程“拉平”了变更成本曲线，使软件开发团队在没有超常规的时间和费用影响的情况下，在软件项目后期能够适应各种变化。敏捷过程包括增量交付。当增量交付与其他敏捷实践耦合时，例如连续单元测试及结对编程，引起变更的费用会衰减。虽然关于拉平曲线的程度的讨论仍然在进行，但是证据表明，敏捷变更费用显著降低。
敏捷过程的定义：
基于敏捷原则进行的软件开发过程，视为敏捷过程。所谓“基于”，是指充分考虑，而不是全部包含。
敏捷过程的三大假设
提前预测需求或变化很难，预测优先级也存在困难；理论上讲，是先有设计，后有构建。但实际上这两步是交替反复的，因为设计者是人，不是神；从客观角度和软件开发的经验来讲，软件开发的几大要素（分析、设计、构建和测试）都要不断的调整、变化，而这正是敏捷的内涵。
敏捷原则
我们最优先要做的是通过尽早、持续地交付有价值的软件来使客户满意。即使在开发的后期，也欢迎需求变更。敏捷过程利用变更为客户创造竞争优势。经常交付可运行软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。围绕有积极性的个人构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。在团队内部，最富有效果和效率的信息传递方法是面对面交谈。可运行软件是进度的首要度量标准。敏捷过程提倡可持续的开发速度。责任人（sponsor）、开发者和用户应该能够保持一个长期的、恒定的开发速度 。不断地关注优秀的技能和好的设计会增强敏捷能力。简单是必要的。最好的架构、需求和设计出自于自组织团队。每隔一定时间，团队会反省如何才能更有效地工作，并相应调整自己的行为。
★并不是每一个敏捷模型都同等使用这12项原则，一些模型可以选择忽略（或至少淡化）一个或多个原则的重要性。
使用得最为广泛的敏捷过程。三个特点：
是一些相互关联的准则和惯例的集合；追求变更曲线平坦化；适合于小团队、高风险的项目。
极限编程过程
XP使用面向对象方法作为推荐的开发范型，
它包含了策划、设计、编码和测试4个框架活动的规则和实践。
(区别于：软件工程过程框架通常包括以下5个活动：沟通、策划、建模、构建、部署)
策划：
建立一系列描述待开发软件必要特征与功能的“故事” (故事：由客户谈论系统应该完成什么功能，然后用通俗的自然语言，使用自己的语汇，将其写在卡片上)；
评估每一个故事，并给出以开发周数为度量单位的成本；
客户和XP团队共同决定如何对故事分组，并置于将要开发的下一个发行版本中（下一个软件增量）；
形成关于一个发布版本的基本承诺；
对有待开发的故事进行排序：（1）所有选定故事 (下一个增量)将在几周之内尽快实现；（2）具有最高权值的故事将移到进度表的前面并首先实现；（3）高风险故事将首先实现。
在第一个版本发布之后，XP团队计算项目的速度。项目速度由第一个发行版本中实现的客户故事个数来决定。
项目速度将用于： (1) 帮助估计后续发行版本的发布日期和进度安排；(2) 确定是否对整个开发项目中的所有故事有过分承诺。一旦发生过分承诺，则调整软件发行版本的内容或者改变最终交付日期。
在开发过程中，客户可以增加故事，改变故事的权值，分解或者去掉故事。然后由XP团队重新考虑并修改计划。
设计：
严格遵循KIS (Keep It Simple)原则，即使用简单而不是复杂的表述。不鼓励额外功能性（因开发者假定以后会用到）设计。
鼓励使用CRC卡（类-责任-协作者）确定与当前软件增量相关的面向对象的类。
在某个故事设计中遇到困难时，立即建立这部分设计的可执行原型，实现并评估设计原型 (Spike解决方案：让不明确的评估成为明确的评估)，其目的是在真正的实现开始时降低风险，对可能存在设计问题的故事确认其最初的估计。
鼓励“重构”。【重构：是以不改变代码外部行为而改进其内部结构的方式来修改软件系统的过程。实质上，重构就是在编码完成之后改进代码设计 (设计优化，代码优化)。重构所需工作量随着应用软件规模的增长而急剧增长。】
编码：
XP推荐在故事开发和初步设计完成之后，团队不是直接开始编码，而是开发一系列用于检测本次（软件增量）发布的包括所有故事的单元测试。一旦编码完成，就可以立即完成单元测试，从而向开发者提供即时的反馈。(先开发测试用例，然后再编码)
结对编程。XP建议两个人面对同一台计算机共同为一个故事开发代码。这一方案提供了实时解决问题 (两个人总比一个人强)和实时质量保证的机制 (在代码写出后及时得到复审)，同时也使得开发者能集中精力于手头的问题。
实施中不同成员担任的角色略有不同，例如，一名成员考虑设计特定部分的编码细节；而另一名成员确保编码遵循的标准。
当结对的两人完成其工作，他们所开发的代码将与其他人的工作集成起来。有些情况下，团队(专人)进行集成。还有一些情况下，结对者自己负责集成，这种“连续集成”策略有助于避免兼容性和接口问题。
测试：
建立的单元测试应当使用一个可以自动实施的框架（因此易于执行并可重复），这种方式支持代码修改之后即时的回归测试策略。
将个人单元测试组织到一个“通用测试集”，与传统方式不同，每天都可以进行系统的集成和确认测试，可以为XP团队提供连续的进展指示，也可在一旦发生问题的时候及早提出预警。 “每几个小时修改一些小问题，比仅在最后截止期之前修正大问题要节省时间。”
XP验收测试，也称为客户测试 (由客户主导)，由客户规定技术条件，并且着眼于客户可见的、可评审的系统级的特征和功能。验收测试根据本次软件发布中所实现的用户故事而确定。
5.5 其他敏捷过程模型
5.6 敏捷过程工具集
关于极限编程（XP）的优点，以下哪个说法是正确的？（ A ）
A. 提供高度灵活性和响应变化能力
B. 强调个人技能而忽视团队合作
C. 仅适用于小型项目
D. 降低软件质量和可维护性
极限编程（XP）注重高度灵活性和快速响应变化的能力。它通过迭代开发、持续交付和频繁反馈的方式，使团队能够适应需求变化，并在项目进展中及时调整。
软件工程的敏捷理念强调以下哪个重要方面？（ C ）
A. 高度规范化的流程和文档
B. 个人技能的发展和提升
C. 自组织团队的控制力
D. 长期的计划和预测
软件工程的敏捷理念强调4个关键问题：
自组织团队对所开展工作具有控制力的重要性；
团队成员之间以及开发参与者和客户之间的交流与合作；
对“变更代表机遇”的认识；
强调快速交付让客户满意的软件。
Scrum是一种敏捷软件开发框架，强调（自组织、迭代开发和持续反馈）。它通过迭代开发周期，称为（sprint），来持续交付可工作的软件增量。每个（sprint）的工作内容由（团队）自行决定，并通过（产品Backlog）来确定和调整优先级。团队在每天的（每日站会）会议中分享工作进展、遇到的问题和计划。Sprint结束后，进行（回顾会议）会议以评审已完成的工作并进行反馈，以及回顾会议以识别改进机会。
敏捷过程模型声称能够有效控制成本，即便是经常发生需求变更也支持。请结合Scrum、XP、看板法，谈谈其内在机制是哪些？
敏捷过程模型是一种以人为核心、迭代、增量的软件开发方法论，它强调适应性、灵活性和快速响应变化。Scrum、XP（极限编程）、看板法（Kanban）是敏捷开发中的几种常见方法。这些方法通过以下内在机制来有效控制成本，即使在需求频繁变更的情况下：
迭代开发（Iterative Development）：
Scrum和XP都采用短周期的迭代开发模式，通常称为Sprint或迭代。每个迭代周期内，团队会完成一部分需求的开发和测试，这样有助于快速获得反馈并进行调整。
持续集成（Continuous Integration）：
在XP中，团队成员频繁地集成代码，确保代码的集成质量。这有助于及早发现集成问题，减少后期集成的成本。
最小可行产品（Minimum Viable Product, MVP）：
敏捷方法鼓励开发最小可行产品，即只包含核心功能的版本，以验证产品概念。这有助于减少不必要的开发工作和成本。
需求优先级（Requirement Prioritization）：
Scrum和看板法都强调根据业务价值对需求进行优先级排序，优先开发最重要的功能。这有助于确保资源被集中用于最有价值的部分。
透明性（Transparency）：
敏捷方法要求项目的进展和状态对所有团队成员和利益相关者透明。这有助于及时发现问题和偏差，减少误解和返工。
自我组织团队（Self-Organizing Teams）：
在Scrum和XP中，团队成员自行组织工作，选择最适合完成工作的方式。这种自主性有助于提高团队的效率和适应性。
持续改进（Continuous Improvement）：
敏捷方法鼓励团队定期回顾和改进工作流程。例如，Scrum中的Sprint回顾会议，看板法中的持续流程改进。
适应性规划（Adaptive Planning）：
敏捷方法允许在项目过程中根据反馈和变化调整计划。这种灵活性有助于应对需求变更，而不是坚持一个固定的计划。
限制在制品（Limit Work In Progress, WIP）：
看板法特别强调限制在制品数量，以减少多任务处理和提高流程效率。这有助于更快地响应需求变更。
测试驱动开发（Test-Driven Development, TDD）：
在XP中，测试驱动开发是一种核心实践，它要求先编写测试用例，再编写功能代码。这有助于确保代码质量，减少后期的修复成本。
客户协作（Customer Collaboration）：
敏捷方法强调与客户紧密合作，以便更好地理解需求并及时调整。Scrum中的Product Owner角色就是客户代表。
快速反馈循环（Fast Feedback Loops）：
敏捷方法通过快速的反馈循环，使得团队能够迅速响应需求变更和市场变化。
通过这些内在机制，敏捷过程模型能够有效地控制成本，提高开发效率，同时保持对需求变更的适应性。这些方法论的共同目标是交付高质量的软件，同时最大化客户满意度。
七种特质
责任感。这会让软件工程师去努力实现对同伴、其他利益相关者和管理者的承诺。为获得成功的结果，他会在需要的时候不遗余力地做他需要做的事情。对一些人的需求有敏锐的意识，这些人包括同团队的成员、利益相关者、掌控整个项目并能找到解决方法的管理者。他会观察人们工作的环境，并根据环境和人本身来调整自己的行为。坦诚。如果发现了有缺陷的设计，他会用诚实且有建设性的方式指出错误。展现抗压能力。前面我们提到，软件工程工作经常处在混乱的边缘。压力（以及由此产生的混乱）来自很多方面——需求和优先级的变更、要求苛刻的利益相关者或同伴、不切实际或者令人难以忍受的管理者。但一个卓有成效的软件工程师可以在不影响业绩的情况下很好地处理这些压力。有高度的公平感。他会乐于与同事分享荣誉，努力避免利益冲突并且绝不破坏他人劳动成果。注重细节。这并不意味着追求完美，而是说他会利用产品和项目已有的概括性标准（如性能、成本、质量），在日常工作基础上仔细思考，进而做出技术性决策。务实。他知道软件工程不是要恪守教条的宗教信仰，而是可根据当下情景需要进行调整的科学规则。
6.2 软件工程心理学
6.3 软件团队
软件工程团队的四种组织模式：
封闭式模式。按照传统的权利层次来组织团队。当开发与过去已经做过的产品相似的软件时，这种团队十分有效。但在这种封闭式范型下难以进行创新性的工作。随机式模式。松散地组织团队，团队工作依赖于团队成员个人的主动性。当需要创新或技术上的突破时，按照这种随机式范型组织的团队很有优势。但当需要“有次序地执行”才能完成工作时，这种团队就会陷入困境。开放式模式。试图以一种既具有封闭式范型的控制性，又包含随机式范型的创新性的方式来组织团队。良好的沟通和根据团队整体意见做出决策是开放式范型的特征。开放式范型的团队结构特别适合于解决复杂的问题，但可能不像其他类型团队那么有效率。同步式模式。 依赖于问题的自然划分，组织团队成员各自解决问题的一部分，他们之间没有什么主动的交流。
组织结构
主程序员式组织结构
随机式组织结构
民主式组织结构
6.5 敏捷团队
6.6 社交媒体的影响
6.7 软件工程中云的应用
6.8 协作工具
6.9 全球化团队
在一个信息系统组织中，你被指派为项目管理者。你的工作是建造一个应用，类似于你的小组以前已经做过的项目，虽然这一个规模更大且更复杂一些。需求已经由用户写成文裆。你会选择那种团队结构？
1.出卷系统案例
问题描述
系统支持人工辅助出卷和自动出卷：
自动出卷：根据教师出卷要求，抽取题目，自动得到一份试卷；人工辅助出卷：根据教师出卷要求，抽取符合要求的题目，供教师选择。出卷要求包括总分，总难度及其比例，总题型及其比例，总知识点及其比例。 系统能进行题库管理：
包括试题录入、修改、删除等；至少有1000道不同类型的试题；能容纳足够多的试题；试题含有内容、答案、题型、难度、知识点和加入时间等信息。 系统能支持不同科目；系统有一个好的图形界面；试题不允许重复出现；试卷符合要求的96%以上即可结束，允许教师调整。能进行试卷分析。
功能分析
用户：教师、学生、题库维护人员。
用户的各自问题：
教师：出一份合理的试卷，并能根据样式打印与输出；学生：通过生成一些模拟试题，进行在线学习和检查学习结果；题库维护人员：添加、更新、删除试题。
精化后的问题：
教师：自动出卷、手动出卷、试卷编辑、试卷输出；学生：随机抽卷、在线练习、在线评价；题库维护人员：试题管理。
系统的功能需求：
自动出卷：根据教师要求自动生成一份合理的试卷；手动出卷：教师手动从候选试题中挑选题目；试卷编辑：更新试题；试卷输出：根据某个样式输出试卷。随机抽卷：随机抽取试题，生成一份试卷；在线练习：学生可以在线做练习和查看答案；在线评价：根据测试结果，评价学生的表现；试题管理：管理人员维护题库中的试题；
2.短信系统案例
问题描述
基本目的：利用快捷的短信业务，发送即时消息以支持企事业单位进行信息通知、通告等各种服务，以及用短信进行客户服务。短信发送：客户选择若干个目标人员，编辑内容，立即或定时发送通知信息。短信人工应答：用户查看收到的短信内容，并可回复。短信自动应答：根据短信询问内容，并依据规则自动回复询问者。短信接收：接收外部短信。短信确认：确认接收方是否接收。客户资料维护：添加、删除和更新用户。接口要求：支持移动终端通过串口通信，支持与移动网关通信。
功能分析
用户：收发人员、管理人员用户的各自问题：
收发人员：负责发送短信给用户或接受用户短信；管理人员：添加、更新、删除用户。 功能需求：
用户：
短信发送：填写发送内容、选择发送用户、指明是否要回执、然后（通过无线终端或短信网关）发送短信；短信接收：从无线终端或短信网关读取短信内容，并查看； 管理员：
用户管理：添加用户、更新用户、删除用户。系统设置
3.SafeHome系统案例
问题描述
房主通过使用报警控制面板或计算机等多种方式与住宅安全功能交互：
输入密码以便能进行其他交互操作。查询安全区的状态。查询传感器的状态。在紧急情况时按下应急按钮。激活或关闭安全系统。 考虑到房主使用控制面板的情况，系统激活的基本用例(场景)：
房主观察控制面板，以确定系统是否已准备好接收输入。如果系统尚未就绪，“not ready”消息将显示在LCD显示器上，房主必须亲自动手关闭窗户或门以使得该消息消失。房主使用键盘输入4位密码，该密码和系统中存储的有效密码相比较。如果密码不正确，控制面板将鸣叫一声并自动复位以等待再次输入。如果密码正确，控制面板等待进一步的操作。房主选择“stay”或“away”启动系统。“stay”只激活外部传感器，“away”激活所有的传感器。当激活时，房主可以看到一个红色的警报灯。 功能分析
需求分析中开发人员要从用户那里了解（ A ）。
A、软件做什么
B、用户使用界面
C、输入的信息
D、软件的规模
需求分析是（ A ）。
A、软件开发工作的基础
B、软件生存周期的开始
C、由系统分析员单独完成的
D、由用户自己单独完成的
（21.综合.1）某经营文具用品企业需要构建一个在线购物系统，下图是某个用户通过系统下订单的效果图。
我的全部订单
订单编号：2016010008625
订单生成时间：2022-05-22 18:20:15
送货地址：福州市大学城区学院路2号
付款方式：货到付款
商品编号商品名称购买数量单价（元）A0023涂改带205.00B04210.7mm签字笔103.00B04220.5mm签字笔102.50
总价：155.00
（1）要达到这样的效果，该如何设计相关类？给出主要类图
（2）为了促销，该企业决定推出618活动：满100元减5元、满200元减15元、满300元减30元。考虑到将来还会有双十一、双十二等不同促销手段的活动，你将如何修改设计方案，以适应上述要求？给出设计方案并说明运用了哪些设计原则。
（1）主要类图设计如下：
（2）为了促销，可以使用策略模式来修改设计方案，以适应不同的促销手段。策略模式是一种行为型设计模式，它定义了一系列算法，并将每一个算法封装起来，使它们可以相互替换。策略模式让算法独立于使用它的客户端。
具体来说，可以定义一个抽象类或接口促销策略，它有一个抽象方法计算优惠金额。然后定义不同的促销策略类，如618活动、双十一活动等，它们都实现或继承促销策略类，并重写计算优惠金额方法。最后，在订单类中增加一个属性促销策略，并在计算总价方法中调用促销策略的计算优惠金额方法。
这样做的好处是，可以根据不同的活动动态地选择不同的促销策略，而不需要修改订单类的代码。这符合开闭原则（对扩展开放，对修改关闭）和单一职责原则（每个类只负责一件事）。
修改后的设计方案如下：
（21.综合.4）互联网技术和智能手机的普及，使得人们出行方式发生了改变，人们可以通过叫车系统呼叫或预约汽车，送顾客到目的地，系统根据行程的距离、用车时段、车型以及是否拼车等方式计算出行费用，用户到达目的地后再结算费用并评价司机服务。其中叫车系统提供三种出行方案：快车、出租车和顺风车。其中快车方式，用户可以选择车型，不同车型价格不同；出租车方式，用户可以添加调度费来召唤出租车；顺风车方式，用户可以选择是否拼车。如果用户的用车时间恰恰是在高峰时段，那么总费用将上浮40%。用户可以通过充值的方式给自己账户充钱，也可以通过绑定银行卡的方式，结算费用时直接扣去银行卡余额。叫车系统对于司机需要认证，主要通过身份证和机动车驾驶证，同时，根据用户用车后的评价，给予司机奖励和提成，差评率高的司机将进入黑名单，好评率高的司机将优先推荐。
（1）使用用例图表述系统的功能。
（2）使用类图表述支撑系统功能的主要分析类和类间关系，每个类要给出必要的属性与操作。
(1)用例图
(2)类图
数据流图所描述的是实际系统的物理模型
用户取钱例子
外部实体：储户、日历处理(数据变换)：检验、登录、付款数据存储：帐卡、存折
使用分层的方式表示：
第一个数据流模型 (第0层DFD，也称环境图)表示整个系统，随后的数据流图改进环境图，在每个后续层提供更多的细节。当把DFD逐步细化时，分析师同时也就完成了系统功能分解。与此同时，当数据在应用系统中的多个处理间流动时，DFD的精炼结果导致了相应的数据精化。
导出数据流图的指导原则：
(1) 第0层DFD（也称环境层DFD或顶层DFD）将系统描述成一个泡泡；
(2) 仔细标记主要的输入和输出；
(3) 通过把选定的处理、数据对象和数据存储分离为下一层表示而开始精化过程，即逐步求精，一次精化一个处理；
(4) 使用有意义的名称，标记所有的箭头和泡泡；
(5) 从一层转至另一层时，注意保持信息流的连续性；
(6) 一次精化一个泡泡。
SafeHome案例
根据语法解析：
动词是SafeHome的处理，在后续的DFD中用泡泡表示；名词是外部实体(方框)、数据或控制对象(箭头)、数据存储(双横线)。 在任何DFD层次中对某个泡泡的处理叙述文字进行语法解析，可以产生许多如何精化到下一个层次的有用信息。
例如，第0层DFD可以扩展为6个处理
顺序图将交互关系表示为一个二维图：
用时间函数表明事件如何引发从一个对象到另一个对象的转移。箭头：代表一个事件；时间纵向向下度量，消息从左到右排列；纵向矩形：表示处理某个活动所用的时间。
为每个类呈现了主动状态和导致这些主动状态变化的事件每个箭头表示某个对象从一个主动状态转移到另一个主动状态。每个箭头上的标注都体现触发状态转移的事件。
管理各种关系模型中的信息，具体信息包括：
一般信息：名字、别名、描述等；定义信息：数据类型、长度、结构；使用特点：值的范围、使用频率、使用方式；控制信息：来源、使用它的程序；分组信息：父结构、从属结构、物理位置等； 数据元素组成数据对象的方式：
顺序：两个或多个分量以确定次序进行连接；选择：从两个或多个可能的元素中选取一个；重复：把指定的分量重复零次或多次。 符号：
= 等价于+和[ ]或 (选择一个，用|隔开分量)
字母或数字 = [字母字符 | 数字字符] { } 重复 ，(左右的数字分别为重复次数的上、下界)
字母数字串 = 0{字母或数字}7 (可重复0-7次) ( ) 可选 (即从括号从中任选一项，也可一项都不选)
如果数据流图的加工需要依赖多个逻辑条件的取值，使用判定表来描述比较合适一个表格，描述条件和条件导致的动作的集合：
问题描述
系统支持人工辅助出卷和自动出卷：
自动出卷：根据教师出卷要求，抽取题目，自动得到一份试卷；人工辅助出卷：根据教师出卷要求，抽取符合要求的题目，供教师选择。出卷要求包括总分，总难度及其比例，总题型及其比例，总知识点及其比例。 系统能进行题库管理：
包括试题录入、修改、删除等；至少有1000道不同类型的试题；能容纳足够多的试题；试题含有内容、答案、题型、难度、知识点和加入时间等信息。 系统能支持不同科目；系统有一个好的图形界面；试题不允许重复出现；试卷符合要求的96%以上即可结束，允许教师调整。能进行试卷分析。
功能分析
用户：教师、学生、题库维护人员。用户的各自问题：
教师：出一份合理的试卷，并能根据样式打印与输出；学生：通过生成一些模拟试题，进行在线学习和检查学习结果；题库维护人员：添加、更新、删除试题。 精化后的问题：
教师：自动出卷、手动出卷、试卷编辑、试卷输出；学生：随机抽卷、在线练习、在线评价；题库维护人员：试题管理。 系统的功能需求：
自动出卷：根据教师要求自动生成一份合理的试卷；手动出卷：教师手动从候选试题中挑选题目；试卷编辑：更新试题；试卷输出：根据某个样式输出试卷。随机抽卷：随机抽取试题，生成一份试卷；在线练习：学生可以在线做练习和查看答案；在线评价：根据测试结果，评价学生的表现；试题管理：管理人员维护题库中的试题；
顶层数据流图
一层数据流图
二级数据流图（自动出卷部分）
出卷功能初步的ER图：
“试卷”的数据字典：
“出卷要求”的数据字典：
问题描述
基本目的：利用快捷的短信业务，发送即时消息以支持企事业单位进行信息通知、通告等各种服务，以及用短信进行客户服务。短信发送：客户选择若干个目标人员，编辑内容，立即或定时发送通知信息。短信人工应答：用户查看收到的短信内容，并可回复。短信自动应答：根据短信询问内容，并依据规则自动回复询问者。短信接收：接收外部短信。短信确认：确认接收方是否接收。客户资料维护：添加、删除和更新用户。接口要求：支持移动终端通过串口通信，支持与移动网关通信。
功能分析
用户：收发人员、管理人员用户的各自问题：
收发人员：负责发送短信给用户或接受用户短信；管理人员：添加、更新、删除用户。 功能需求：
用户：
短信发送：填写发送内容、选择发送用户、指明是否要回执、然后（通过无线终端或短信网关）发送短信；短信接收：从无线终端或短信网关读取短信内容，并查看； 管理员：
用户管理：添加用户、更新用户、删除用户。系统设置
用例场景：
发送短信的场景描述：
用户输入短信内容；用户选择若干个发送人员；系统将明文短消息编码成格式化的短消息串；系统以串行方式将短信串传入无线移动终端。 接收短信的场景描述：
用户向串口发送指令从无线移动终端读取一组短消息串；系统将一组短信串解码成明文的短消息；系统将短消息写入数据库，并显示给用户。 人员维护的场景描述：
管理员添加一个新成员；管理员更新一个成员的信息；管理员删除一个成员。 系统设置的场景描述：
管理员修改基本信息：如短信客服中心号码、发送频率、延时等；系统保存设置信息。
类包括：
边界类：用于建立系统与其参与者之间交互的模型，经常代表对窗口、屏幕、打印机接口等抽象：
发送短信界面、接收短信界面、收发接口； 控制类：用于协调、排序、事务处理以及其它的对象控制：
发送短信、接收短信； 实体类：业务实体：
短信编/解码、发送的短信串、接收的短信串；
发送短信用例的协作图：
发送短信用例的顺序图(时序图)：
在结构化分析方法中，（ C ）表达系统内部数据运动的图形化技术。
A、数据字典
B、实体关系图
C、数据流图
D、状态转换图
数据流图（Data Flow Diagram，DFD）是一种图形化的工具，用于描述系统中数据的流动和处理过程。数据流图能帮助分析人员和开发人员更好地理解和描述系统的功能和数据流程，从而进行需求分析、系统设计和功能实现。
数据流图(DFD: Data Flow Diagram)描绘系统的逻辑模型。它是软件开发（ D ）阶段经常使用的工具。
A、软件维护
B、软件测试
C、详细(过程)设计
D、需求分析
数据流图可以通过图形化的方式描述系统的功能、数据流动和处理过程，帮助分析人员和开发团队理解系统的需求和功能。在需求分析阶段，数据流图可以用于捕捉和表示用户需求、业务过程以及数据在系统中的流动和处理。
（21.综合.4）互联网技术和智能手机的普及，使得人们出行方式发生了改变，人们可以通过叫车系统呼叫或预约汽车，送顾客到目的地，系统根据行程的距离、用车时段、车型以及是否拼车等方式计算出行费用，用户到达目的地后再结算费用并评价司机服务。其中叫车系统提供三种出行方案：快车、出租车和顺风车。其中快车方式，用户可以选择车型，不同车型价格不同；出租车方式，用户可以添加调度费来召唤出租车；顺风车方式，用户可以选择是否拼车。如果用户的用车时间恰恰是在高峰时段，那么总费用将上浮40%。用户可以通过充值的方式给自己账户充钱，也可以通过绑定银行卡的方式，结算费用时直接扣去银行卡余额。叫车系统对于司机需要认证，主要通过身份证和机动车驾驶证，同时，根据用户用车后的评价，给予司机奖励和提成，差评率高的司机将进入黑名单，好评率高的司机将优先推荐。
（1）使用用例图表述系统的功能。
（2）使用类图表述支撑系统功能的主要分析类和类间关系，每个类要给出必要的属性与操作。
（3）分析系统第0层和第1层的数据流图。
(1)用例图
(2)类图
(3)数据流图
第0层数据流图
第1层数据流图
（21.简答.1）请简要说明你对顺序图和状态图使用的看法？
顺序图（Sequence Diagram）：
顺序图主要用于描述系统中对象之间的交互和消息传递顺序。它展示了对象之间的时序关系，有助于理解系统的行为和交互流程。
顺序图适用于以下情况：
显示对象之间的消息传递和交互顺序，可以帮助捕捉系统的时序逻辑。描述用例场景或特定操作的流程，以便识别参与者和对象之间的交互。强调时间和顺序对系统行为的影响。
状态图（State Diagram）：
状态图主要用于描述系统或对象的状态和状态之间的转换。它展示了对象在不同状态下的行为和响应，以及导致状态转换的事件和条件。
状态图适用于以下情况：
描述对象的生命周期和状态转换，特别适用于具有复杂状态和状态变化的系统。显示系统的不同状态和状态之间的转换条件，有助于识别系统的行为和响应。捕捉对象或系统的状态行为和约束，以便更好地设计和实现系统。
综上所述，顺序图和状态图在软件系统建模中起着不同的作用。
顺序图主要关注对象之间的交互和消息传递顺序，
而状态图主要关注对象的状态和状态之间的转换。
选择使用哪种图取决于想要描述的系统行为和需求，以及希望强调的方面。通常，在系统设计和开发过程中，这两种图经常结合使用，以提供更全面和准确的系统模型。
软件的设计是将需求转变为软件陈述（表达）的过程。系统通过逐步求精，使得设计陈述逐渐接近源代码：
第一步是初步设计（Preliminary design），关注于怎么将需求转换成数据和软件框架。第二步是详细设计（Detail design），关注于将框架逐步精细化为具体的数据结构和软件的算法表达。设计行为、数据、算法和程序设计都需要由现代程序所需的界面设计这一清晰的行为来结合起来。
需求模型提供了创建四种设计模型所需信息：
数据/类设计：将类模型转化为设计类以及目标软件的结构；体系结构设计：定义了软件的主要构造元素间的联系；接口设计：描述了软件和协作系统之间、软件和使用人员之间的通信；构件级设计：将软件体系结构的构造元素变换为对软件构件的过程性描述。
抽象
两种不同的抽象
数据抽象：描述数据对象的数据集合。
定义数据类型和施加于该类型对象的操作。门的数据抽象包含一组描述门的属性 (例如，门的类型、转动方向、开门方法、重量和尺寸)。
过程抽象：具有明确和有限功能的指令序列。
过程抽象的命名暗示了功能，但是隐藏了具体的细节。这些功能实际上是由一系列更低级的功能或代码来实现的。过程抽象“开”将利用数据抽象“门”的属性中所包含的信息。过程抽象例：函数、功能性的类/对象 (开门包括：走到门前，伸出手并抓住把手，转动把手并拉门，从移动门走开等)。
体系结构
体系结构设计的属性
结构特性。
定义了系统的构件(如模块、对象、过滤器)、构件被封装的方式以及构件之间相互作用的方式。例如，对象封装了数据和过程，过程操纵数据并通过方法调用进行交互。 外部功能特性。
应当指出设计体系结构如何满足需求，这些需求包括：性能需求、能力需求、可靠性需求、安全性需求、可适应性需求以及其他系统特征需求。 相关系统族。
体系结构应当能抽取出在一类相似系统开发中经常遇到的重复性模式。本质上，设计应当能够重用体系结构构件。
模式
关注点分离
模块化
信息隐蔽
功能独立
功能独立性的指标：内聚与耦合
内聚度
内聚(cohesion)：一个模块内部各个元素彼此结合的紧密程度：
一个内聚的模块执行一个独立的任务，与程序的其他部分构件只需要很少的交互。一个内聚的模块应该 (理想情况下)只完成一件事情。为了实现良好的设计，应该避免“分裂型”构件 (某个构件执行多个无关功能)。尽量高！
七层次
巧合内聚(偶然内聚)：将几个模块中的相同程序代码段独立出来建立的模块 (无明显独立性)。
逻辑内聚（实用内聚）：完成一组逻辑相关任务的模块，由控制型参数来确定执行哪一种功能 (选择其中一个功能，内聚性不强)。
时间内聚：模块中的多个任务必须在一段时间内先后执行 (有时间约束，无明确的过程约束)。
过程内聚：模块内的多个任务必须按指定的过程执行。
通信内聚：模块内所有处理元素都集中在某个数据结构的一块区域中 (例如，对课程进行选、退课和查询)。
顺序内聚：指一个模块完成多个功能，这些功能又必须顺序执行 (更加单一的过程内聚)。
功能内聚：指一个模块中各个部分都是为完成一项具体功能而协同工作，紧密联系，不可分割的 (单个功能)。
耦合度
耦合(coupling)：模块之间相互关联的程度：
尽量低！
七层次
内容耦合：一个模块可以直接访问另一个模块的内部数据或内部功能。
公共耦合：多个模块共同访问某些公共数据元素。
外部耦合：多个模块间需要遵循同样的外部约束，例如通信协议、数据格式等。(遵循全局的约束)
控制耦合：模块间的交互参数包含控制信息，可影响另一个模块的执行逻辑。
标记耦合：模块间传递特定的数据结构。
数据耦合：模块间仅传递简单数据。
非直接耦合：两个模块可以相对独立工作。
软件详细设计的主要任务是确定每个模块的（ A ）。
A、算法和使用的数据结构
B、外部接口
C、功能
D、编程软件设计 (Software Design) 是软件开发的关键步骤，直接影响软件的质量。下述（ D ）不是软件设计阶段所应包含的工作？
A、软件(体系)结构
B、软件过程(构件)
C、用户接口
D、软件风险分析软件设计是软件开发的关键步骤，直接影响到软件的质量。软件设计复审是和软件设计本身一样重要的环节，其最主要的目的是（ C ）。
A、减少测试工作量
B、减少编程工作量
C、避免后期付出高代价
D、缩短软件开发周期
体系结构的概念
也称架构，它是系统的一个或多个结构。它包括：构件，构件的外部可见属性以及它们之间的相互关系。
单主机结构：
界面、数据和程序集中在单台主机上；不需要考虑多用户并发操作的问题。 C/S (Client/Server)结构：
常见的服务器端体现为关系数据库；客户端负责显示和业务逻辑处理；在部署和扩展性方面存在不足：系统升级需要一一更新所有客户端。 B/S (Browser/Server)结构：
瘦客户端：浏览器或客户端程序(Applet等)
以数据为中心的体系结构：
也称仓库。数据存储驻留在体系结构的中心，其他构件访问该数据存储，并进行各种数据操作(更新、增加、删除或修改)。黑板(变种)：当用户感兴趣的数据发生变化时，它将通知客户软件。
数据流体系结构
当输入数据经过一系列的计算构件和操作构件的变换形成输出数据时，可应用该体系结构。例如管道—过滤器模式：
拥有一组称为过滤器的构件，这些构件通过管道连接，管道将数据从一个构件传送到下一个构件。每个过滤器独立于其上游和下游的构件而工作，过滤器的设计要针对某种形式的数据输入，并且产生某种特定形式的数据输出 (到下一个过滤器)。然而，过滤器没有必要了解与之相邻的过滤器的工作。
优点：
易理解；容易并行运行。 问题：
适用于批处理，不易交互；流的协作需要考虑。
管道—过滤器模式
如果数据流退化成单线的变换，则称为批序列。这种结构接收一批数据，然后应用一系列连续的构件(过滤器)完成变换。
调用和返回体系结构
该体系结构风格能够设计出一个相对易于修改和扩展的程序结构，存在以下子风格：
主程序/子程序体系结构：将功能分解为一个控制层次结构，其中的**“主”程序调用一组程序构件，这些程序构件又去调用别的程序构件** (此时，对于被调者来说，这些主调者就是主程序)。
远程过程调用体系结构：构件分布在网络的多个计算机上。
面向对象体系结构
系统的构件封装了数据和应用到该数据上的操作。构件间通过消息传递进行通信与合作。
层次体系结构
定义了不同的层次，各个层次完成各自操作；每一层为上层提供服务，又接受下层的服务；优点：明确的抽象层次、易于增减或修改层次；问题：系统并不是总能分层。
有4种适用于构件级设计的基本设计原则，使用这些原则使得产生的设计在发生变更时能够适应变更并且减少副作用的传播。
单一职责原则：每个类只干一件事开闭原则 (The Open-Closed Principle, OCP)：模块应该对外延具有开放性，对修改具有封闭性；Liskov（里氏）替换原则：子类可以替换它们的基类；依赖倒置原则：依赖于抽象，而非具体实现 ；接口分离原则：多个用户专用接口比一个通用接口要好。
开闭原则
设计者应采用一种无需对构件自身内部(代码或内部逻辑)做修改就可以进行扩展的方式来说明构件。解决方法：抽象、多态，引入抽象基类，构件的变化通过引入新的派生类来完成。
对于各种不同的传感器，Sensor接口都向Detector构件呈现一致的视图。如果需要添加新类型的传感器，对Detector类无需进行任何改变
Liskov替换原则
子类可以替换它们的基类。
Liskov原则要求源自基类的任何子类必须遵守基类与使用该基类的构件之间的隐含约定：
“约定”既是前置条件—构件使用基类前必须为真；又是后置条件—构件使用基类后必须为真。当设计者创建了导出类 (子类)，则要确保这些导出类必须遵守前置条件和后置条件。
好处：
第一、保证系统或子系统有良好的扩展性。子类能够完全替换父类，可以保证系统或子系统在运行期内识别子类就可以了。第二、实现运行期内绑定 (编译时就可以确定对象使用的形式，而不必到执行阶段)，既保证了面向对象多态性的顺利进行，又节省了大量的代码重复或冗余。避免了类似instanceof这样的语句，或者getClass()这样的语句，这些语句是面向对象所忌讳的。第三、有利于实现契约式编程。契约式编程有利于系统的分析和设计，指在分析和设计的时候，定义好系统的接口，然后在编码的时候实现这些接口即可。在父类里定义好子类需要实现的功能，而子类只要实现这些功能即可。
依赖倒置原则
依赖倒置原则，即父类不能依赖子类，它们都要依赖抽象类：
一旦类的使用者依赖某个具体的类，那么对该依赖的扩展就无从谈起；而依赖某个抽象类，则只要实现了该抽象类的子类，都可以被类的使用者使用，从而实现了系统的扩展。 一个系统或子系统要拥有良好的扩展性和实现运行期内绑定，有两个必要条件：
第一是里氏替换原则(子类可以替换父类，例如运动员可以替换人，人的所有属性与操作运动员都具备)；第二是依赖倒置原则(父类不能依赖于子类，例如人不能依赖于运动员，运动员的某些属性与操作有些人不具备)。
接口分离原则 (Interface Segregation Principle, ISP)
ISP原则建议设计者应该为每个主要的客户类型都设计一个特定的接口。只有那些与特定客户类型相关的操作才应该出现在该客户的接口说明中。一个肥接口（包含众多接口的总接口）应该分解成多个专门接口
内聚性
描述为构件的专一性。
内聚性意味着构件或者类只封装那些相互关联密切，以及与构件或类自身有密切关系的属性和操作。
内聚性分类
功能内聚：
主要通过操作来体现，当一个模块中的各个部分只完成某一组特定操作并返回结果时，就称此模块是功能内聚的。(最好的内聚)顺序内聚
模块中各个处理元素密切相关，必须顺序执行，前一功能元素的输出就是下一功能元素的输入。过程内聚：模块内的多个任务必须按指定的过程执行。通信内聚：模块内所有处理元素都集中在某个数据结构的一块区域中。（模块中所有成分引用共同的数据）时间内聚
模块各个功能的执行与时间有关，通常要求所有功能必须在同一时间段内执行。逻辑内聚
模块把几种相关的功能组合在一起，每次被调用时，由传送给模块的判定参数来确定该模块应执行哪一种功能。实用内聚
逻辑上不能纳入其他内聚类型的相关实用程序放在一起，形成实用内聚 (巧合内聚)。（将多处出现的相同的一组语句用函数或者类进行封装）
构件之间彼此联系紧密程度的一种定性度量。随着构件相互依赖的增加，构件的耦合程度也会增加。
内容耦合：一个模块可以直接访问另一个模块的内部数据或内部功能。
公共耦合：多个模块共同访问某些公共数据元素。
外部耦合：多个模块间需要遵循同样的外部约束，例如通信协议、数据格式等。(遵循全局的约束)
控制耦合：模块间的交互参数包含控制信息，可影响另一个模块的执行逻辑。
标记耦合：模块间传递特定的数据结构。
数据耦合：模块间仅传递简单数据。
非直接耦合：两个模块可以相对独立工作。
耦合性的分类
内容耦合 (耦合度最高，最不推荐)
免责声明：本文章由“知识和经验”发布如果文章侵权，请联系我们处理，本站仅提供信息存储空间服务如因作品内容、版权和其他问题请于本站联系