5_1 软件工程

软件工程（Software Engineering），是指应用计算机科学、数学及管理科学等原理，以工程化的原则和方法来解决软件问题的工程。

架构设计：软件架构为软件系统提供了一个结构、行为和属性的高级抽象

架构设计组成：由构建的描述、构建的相互作用（连接件）、指导构件集成的模式以及这些模式的约束组成

                本质：指定系统组织结构和拓扑结构；显示系统需求和构件之间的对应关系，提供一些设计决策的基本原理

                目的：解决好软件的复用、质量和维护问题，是研究软件架构的根本目的

软件架构研究的主要内容：描述、风格、评估、形式化方法

软件架构设计的一个核心问题是能否达到架构级的软件复用

软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式

软件架构风格包括：数据流风格（管道/过滤器）、调用/返回风格（面向对象）、独立构件风格（事件驱动的系统）、虚拟机风格（解释器）、仓库风格（数据库系统）

软件架构风格示例——管道/过滤器：每个构件都有一组输入/输出。构件读取输入的数据流，经过内部处理后，产生输出数据流。

软件架构风格示例——面向对象模式：基于构件的软件开发（CBD）,对象调用对象。

软件架构风格示例——层次结构：采用层次化组织方式，将复杂问题逐步分层。，每一层都为下一层提供服务，并使用下一层提供的功能。

软件架构风格示例——事件驱动模式：构件并不直接调用过程，而是触发一个或多个事件。典型应用包括各种图形界面工具。

软件架构评估：在架构评估过程中，评估人员最关注的是系统的质量属性（可用性、可修改性、性能、安全性、可测试性、易用性）

敏感点：一个或多个构件（或之间的关系）的特性，敏感点只影响一个软件质量属性。

权衡点：影响多个质量属性的特性，权衡点同事影响多个软件质量属性，例如安全级别就是一个权衡点，会影响安全性和性能。

软件架构评估的方式：调查问卷法、度量法、场景评估法。

需求分析：软件需求是指用户对新系统在功能、行为、性能、设计约束等方面的期望

IEEE：软件需求是指用户解决问题或达到目标所需的条件或能力。软件需求就是必须完成的事以及必须具备的品质。

需求的层次：业务需求：反映企业或客户对系统高层次的目标要求。

                  用户需求：用户的具体目标，或用户要求系统必须能完成的任务。

                  系统需求：从系统的角度来说明软件的需求，包括功能需求、非功能需求和设计约束等。

                        功能需求：规定了开发人员必须在系统中实现的软件功能，通常通过系统特性的描述表现出来的

                        非功能需求：系统必须具备的属性或品质

                        设计约束：限制条件或补充规约，通常是对系统的约束说明

需求的特征：正确性、完整性、可行性、一致性、划分优先级、可理解性、可验证性（有方法可检测需求是否实现了）、可追踪性、可修改性、无歧义性

需求过程（重点）：需求获取：确定和理解项目干系人的需求和约束的过程。方法包括用户访谈、问卷调查、采样、情节串联板、联合需求计划等

                需求分析：提炼、分析和审查已经获取到的需求，以确保所有项目干系人清楚各项需求的含义，发现遗漏和不足。方法包括SA方法和OOA方法等

                编写规约：形成软件需求规格说明书SRS，是相关方对需求的共同理解，是开发的基础。

                需求验证与确认：在系统分析阶段检测SRS中的错误，节省时间和资金。

结构化分析方法SA（Structured Analysis）：结构化分析是软件工程中的一种方法，其建立的模型的核心是数据字典。

结构化分析有三个层次的模型：数据模型：实体-联系图（E-R），提供了表示实体类型、属性和联系的方法，用来描述现实世界的概念模型

                功能模型：数据流图（DFD），从数据传递和加工角度，用图形方式表示信息系统中数据的移动方式

                行为模型：状态转换图（STD），描述系统的状态和引起系统状态转换的事件，指出作为特定事件达到结果将执行哪些动作

统一建模语言UML：是一个通用的可视化建模语言，它是面向对象分析和设计的一种标准化表示，用于对软件进行描述、可视化处理、构造和建立软件系统的文档。

UML包含的三种结构：事物、关系、图（三种基本构造块）

UML中的事物：结构事物：类、接口、协作、用例、活动类、构件和节点

                        行为事物：交互和状态机

                        分组事物：包

                        注释事物：UML模型的解释部分

UML中有14种图，重点是类图、用例图、顺序图、活动图

类图（重点）：类图用来显示系统中的类、接口、协作以及它们之间的静态结构和关系，是UML中最常见的图

类图的3个基本组成部分：类名、属性、方法

类之间的关系：泛化（重点，实线空心三角箭头，箭头从子类指向父类）、关联（实线）、依赖（虚线箭头）、实现（虚线空心三角箭头）、聚合（实线空心菱形）、组合（实线实心菱形）

泛化：表示is-a的关系，是对象之间耦合度最大的一种关系，子类继承父类的所有细节。

聚合：表示has-a的关系，是一种不稳定的包含关系，没有整体，局部也单独存在。

组合：表示contains-a的关系，是一种强烈的包含关系，部分不能脱离整体单独存在。

类似类图的有对象图，包图，组件图，组件结构图。

部署图：也称配置图，显示系统中软件和硬件的物理架构。

用例图（重点）：展现系统功能，主要用来描述“用户、需求、系统功能单元”之间的关系，展示了一个外部用户能够观察到的系统功能模型图。

用例图包含的元素：参与者、用例、子系统（图看着像小人砸鸡蛋）

用例之间的四种关系：关联、泛化、包含、扩展（虚线箭头）

顺序图：展现了一组对象或参与者以及它们之间可能发送的消息，顺序图是强调消息的时间次序的交互图，也叫时序图

活动图：是一种特殊的流程图，告诉我们活动之间的依赖关系。

UML中的视图：逻辑视图、实现视图、进程视图、部署视图、用例视图

面向对象分析OOA：将运用面向对象的方法分析问题域，建立基于对象、消息的业务模型，形成对客观世界和业务本身的正确认识。

面向对象设计OOD：是OOA的延续，对分析阶段会给出的问题域模型，用面向对象方法设计出软件基础架构（概要设计）和完整的类结构（详细设计），以实现业务功能。

构建用例模型的阶段：1、识别参与者；2、合并需求获得用例；3、细化用例描述；4、调整用例模型

软件设计：是定义一个系统的架构、组件、接口和其他特征的过程，并得到这个过程的结果

软件设计阶段：软件架构设计和软件详细设计

软件设计方法：结构化设计SD和面向对象设计OOD

设计原则：高内聚低耦合。内聚性指块内联系，耦合性指块间联系

面向对象软件设计七大原则：

                开闭原则：对扩展开放对修改关闭

                里氏替换原则：任何基类可以出现的地方，子类一定可以出现

                依赖倒置原则：针对接口编程，依赖于抽象而不依赖于具体

                接口隔离原则：使用多个隔离的接口，比使用单个接口要好

                迪米特法则：一个实体应当尽量少地与其他实体发生相互作用

                合成复用原则：尽量使用合成/聚合的方式，而不是使用继承

                单一职责原则：设计功能单一的类，不要在一个类中实现多个功能

设计模式：代表了最佳的实践，它使人们可以方便地复用成功的软件设计。每一个模式描述了一个不断重复发生的问题，以及该问题的解决方案。

设计模式分类：创建型模式：工厂模式、抽象工厂模式、单例模式、建造者模式、原型模式

                结构型模式：适配器模式、桥接模式、组合模式、装饰器模式、外观模式、享元模式、代理模式

                行为模式：责任链模式、命令模式、解释器模式、迭代器模式、中介者模式、备忘录模式、观察者模式、状态模式、策略模式。。。

软件实现：软件配置管理：软件配置管理通过标识产品的组成元素、管理和控制变更、验证、记录和报告配置信息，来控制产品的演进和完整性。

软件编码：程序设计语言、程序设计风格、程序复杂性度量

程序设计风格包括4个方面：源程序文档化、数据说明、语句结构和输入/输出方法

编码效率：程序效率、算法效率、存储效率、I/O效率

软件测试：软件测试是为评价和改进产品质量、识别产品缺陷和问题而进行的活动，是在将软件交付给客户之前所必须完成的重要步骤。

软件测试的目的是通过测试发现软件错误。

软件测试过程的主要模型：V模型、W模型、H模型、X模型

V模型反映了测试活动与分析和设计的关系，V模型的价值在于它非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。

相对于V模型，W模型增加了软件各开发阶段中同步进行的验证和确认测试活动。W模型相当两个V模型的叠加，一个是开发的V，一个是测试的V；

W模型体现了“尽早地和不断进行软件测试”的基本原则。

按开发阶段划分：单元测试、集成测试、系统测试、验收测试

单元测试又称模块测试，是针对软件设计的最小单元进行正确性检验的工作，单元测试必须是可重复的

集成测试又称组装测试、联合测试，是在单元测试的基础上，将所有模块按照设计要求组装成子系统或系统进行的测试活动

集成测试关注的是模块间的接口，接口之间的数据传递关系，依据是系统的高层设计

系统测试的目的是在真实系统工作环境下通过与系统的需求定义作比较，检验完整的软件配置项能否和系统正确连接。系统测试更多是站在用户的角度上对系统做功能性的验证。

验收测试又称交付测试、发布测试或确认测试，是在软件产品完成了功能测试和系统测试之后、产品发布之前所进行的软件测试活动。

静态测试：静态测试是指不运行程序，通过人工对程序和文档进行分析与检查；又称为静态分析技术。

动态测试：动态测试是指通过人工或使用工具运行程序进行检查、分析程序的执行状态和程序的外部表现。

静、动态测试——两者区别：静态测试用于预防，动态测试用于校正；多次的静态测试比动态测试效率高。

黑盒测试：也称功能测试，主要针对软件界面和软件功能进行测试。如果外部特性本身设计有问题或规格说明的规定有问题，黑盒测试发现不了。

黑盒测试设计方法包括：等价类划分法、边界值分析法、错误推测法、因果因法、判定表法、正交试验设计法、功能图法

白盒测试：又称结构测试，把程序看成装在一个透明的白盒子里，清楚了解程序结构和处理过程，检查是否所有的结构及路径都是正确的，检查软件内部动作是否按照设计说明书的规定正常进行。

白盒测试主要用于单元测试。

静态白盒测试技术：人工代码检查、静态结构分析、静态质量度量。

各种覆盖测试都是白盒测试。

部署交付：软件部署与交付属于软件开发的后期活动，即通过配置、安装和激活等活动来保障软件制品的后续运行。

持续交付：持续交付是一系列开发实践方法，用来确保让代码能够快速、安全地部署到生产环境中。

评价软件交付能力的指标：1、仅涉及一行代码的改动需要花费多少时间才能部署上线，这是核心指标。

                                2、开发团队是否在以一种可重复、可靠的方式执行软件交付。

持续部署：1）持续部署方案：常用的持续部署方案有Kubernetes+Docker和Matrix系统两种。

                2）部署原则：部署包全部来自统一的存储库；

                                        所有的环境使用相同的部署方式；

                                        所有的环境使用相同的部署脚本。。。

                3）部署层次：完整的镜像部署包括三个环节：Build-Ship-Run

                4）不可变服务器：不可变服务器是一种部署模式，指除了更新和安装补丁程序以外，不对服务器进行任何更改。

                                        现阶段使用容器部署不但继承和优化了虚拟机部署的优点，而且很好地解决了第三方依赖库的重构问题，

                                        容器部署就像一个集装箱，直接把所有需要的内容全部打包并进行复制和部署。

                5）蓝绿部署和金丝雀部署：蓝绿部署是指在部署的时候准备新旧两个部署版本，通过域名解析切换的方式将用户使用环境切换到新版本中。

                                                        金丝雀部署是指当有新版本发布的时候，先让少量用户使用新版本，并且观察新版本是否存在问题。

部署与交付的新趋势：工作职责和人员分工的转变；大数据和云计算基础设施的普及进一步给部署带来新的飞跃；研发运维的融合；

过程管理：软件过程能力：是组织基于软件过程、技术、资源和人员能力达成业务目标的综合能力。

软件过程能力成熟度：是指组织在提升软件产品开发能力或软件服务能力过程中，各个发展阶段的软件能力成熟度。

成熟度模型（CSMM）：软件过程能力成熟度模型旨在通过提升组织的软件开发能力帮助顾客提升软件的业务价值。

4大能力域：治理、开发与交付、管理与支持、组织管理。

20个能力子域：战略与治理、目标管理、需求、设计、开发、测试、部署、服务、开源应用、项目策划、项目监控、项目结顶、风险管理、质量保证、配置管理、供应商管理、过程管理、人员能力管理、组织资源管理、过程能力管理。

CSMM定义了5个等级，1级：初始级；2级：项目规范级；3级：组织改进级；4级：量化提升级；5级：创新引领级。