原文链接，摘抄了些知识点：https://blog.csdn.net/qq_36146165/article/details/78988521
软件工程是：
（1）将系统化的、规范化、可量化的方法应用于软件的开发、运行和维护，即将工程化方法应用于软件。
（1）将系统化的、规范化、可量化的方法应用于软件的开发、运行和维护，即将工程化方法应用于软件。
Process Model
惯用过程模型是为了改变软件开发的混乱状态，促使软件开发更加有序。
|
瀑布模型（waterfall model）：又被称为经典生命周期（classic life cycle），它提出了一个系统的、顺序的软件开发方法。
优点：
有利于大型软件开发过程中人员的组织、管理，从而提高了大型软件项目开发的质量和效率。
当需求确定、工作采用线性的方式完成的时候瀑布模型是一个很有用的过程模型。
一个有用的过程模型，其中需求是固定的，工作将以线性方式完成。
缺点:
过于理想，缺乏灵活性，容易产生需求偏差。
实际的项目很少遵守瀑布模型提出的顺序。
客户通常很难清除的描述所有的需求。
客户必须要有耐心，因为只有在项目接近尾声的时候，他们才能的带执行的程序。
适用范围：需求确定，工作能够采用线性的方式完成的软件。
|
|
|
V模型（V-model）：
描述了质量保证动作同沟通、建模相关动作以及早期构建相关的动作之间的关系。
V模型强调软件开发的协作和速度，将软件实现和验证有机地结合起来，在保证较高的软件质量情况下缩短开发周期。
优点：适合工程量小、人力资源少并且开发过程中改动不大的项目
缺点：错误发现时间迟，产生的风险代价高
|
|
|
增量过程模型（Incremental Model）：
增量过程模型侧重于每一个增量都提交一个可以运行的产品。
优点：
1.能在较短的时间内向用户提交可完成部分工作的产品。
2.逐步增加产品功能可以使用户有充裕的时间学习和适应新产品，从而减少一个 全新的软件可能给客户组织带来的冲击。
3. 规避技术风险
4. 可并行开发构件，加快开发的进度
5. 对于在业务截止日期之前完全实施的人员配置非常有用。
缺点：
（1）并行开发构件有可能遇到不能集成的风险，软件必须具备开放式的体系结构；
（2）增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而是软件过程的控制失去整体性。
适用范围：
（1）进行已有产品升级或新版本开发，增量模型是非常适合的； （2）对完成期限严格要求的产品，可以使用增量模型；
（3）对所开发的领域比较熟悉而且已有原型系统，增量模型也是非常适合的。
（4）项目在既定的商业要求期限之前不可能找到足够的开发人员
|
|
|
演化过程模型（Evolutionary Model）
演化模型是迭代的过程模型。
原型开发（prototyping ）：当需求很模糊的时候，原型开发可以帮助软件开发人员和利益相关者更好地理解究竟需要做什么。
优点：
开发者与用户充分交流，可以澄清模糊需求，需求定义比其他 模型好得多
开发过程与用户培训过程同步
为用户需求的改变提供了充分的余地
开发风险低，产品柔性好
开发费用低，时间短
系统易维护，对用户更友好
缺点：
1、 没有考虑软件的整体质量和长期的可维护性。
2、 大部分情况是不合适的操作算法被采用目的为了演示功能，不合适的开发工 具被采用仅仅为了它的方便，还有不合适的操作系统被选择等等。
3、 由于达不到质量要求产品可能被抛弃，而采用新的模型重新设计。
适用范围：
尽管原型可以用作独立的流程模型，但它更常用作一种可以在任何流模型的上下文中实现的技术。
|
|
|
螺旋模型（Spiral Model）
螺旋模型是一种风险驱动型的过程模型生成器，对于软件集中的系统，它可以指导多个利益相关者的协同工作。
优点：
它结合了原型的迭代性质和瀑布模型的系统性和可控性特点。
1. 强调风险
2. 强调阶段质量
3. 提供纠错的机会
4. 使用原型作为风险降低机制，进一步使开发人员能够在产品演变的任何阶段应用原型方法。
缺点：
1. 每个阶段都要提出被选方案，进行风险分析，研发周期长，效率低
2. 必须要转业的风险分析人员的参与
3. 如果没有发现和管理重大风险，问题无疑将会发生。
适用范围：大型项目
|
|
|
协同模型（concurrent development model）
有时候又称为协同工程，它允许软件团队表述本章所描述的任何模型中的迭代和并发元素。
协同建模提供了项目当前状态的准确画面。
适用范围：所有类型的软件开发，协同模型通常更适合涉及不同工程团队的产品工程项目。
|
|
|
统一过程（Unified Process）
统一过程模型
统一过程模型是一种“用例驱动、以体系结构为核心、迭代及增量”的软件 过程框架，由UML方法和工具支持。它是一种增量模型，定义了五个阶段：
a、起始阶段，包括用户沟通和计划活动，强调定义和细化用例
b、 细化阶段，包括用户沟通和建模活动，重点是创建分析和设计模型。
c、构件阶段，细化模型设计，并将设计模型转化为软件构件实现
d、 转化阶段，将软件从开发人员传递给最终用户，并由用户完成 beta 测试和验 收测试
e、生产阶段，持续地监控软件的运行，并提供技术支持。
优点：
1. 任何功能开发后就进入测试过程，及早进行验证
2. 早期风险识别，采取预防措施
缺点：
1. 需求必须在开始之前完全弄清楚，否怎有可能在架构上出现错误
2. 必须有严格的过程管理，以免使过程退化为原始的试→错→改模式
3．如果不加控制的让用户过早接触没有测试完全，版本不稳定的产品可能对用 户和开发团队都带来负面的影响。
|
|
|
Agile Development
敏捷宣言（Agile development manifesto）：
个人和这些个人之间的交流胜过了开发过程和工具
可运行的软件胜过了宽泛的文档
客户合作胜过了合同谈判
对变更的良好响应胜过了按部就班地遵循计划
极限编程（Extreme Programming (XP)）：
极限编程是敏捷软件开发使用最广泛的一个方法。
极限编程过程:
1.策划：
开始创造“用户故事”
敏捷团队评估每个故事并分配一个成本（开发周数）
故事被分组到一个可交付增量
承诺在交付日期进行
在第一次递增之后，“项目速度”用于帮助估计后续发行版本的发布日期和进度安排，确定是否对整个开发项目中的所有故事有过分承诺。
2.设计
遵循KIS（保持简洁）原则
鼓励使用CRC（类-责任-协作者）卡（见第8章）
对于困难的设计问题，建议创建“尖峰解决方案” - 一个设计原型
鼓励“重构”： 重构是以不改变代码外部行为而改进其内部结构的方式来修改软件系统的过程。
3.编码
在编码开始之前，建议对故事进行单元测试
鼓励“结队编程”
4.测试
所有的单元测试每天都执行
“验收测试”，由客户规定技术条件，并且着眼于客户可见的、可评审的系统级的特征和功能。
|
|
|
设计概念
1.抽象（Abstraction）：
过程抽象是指具有明确和有限的指令序列（描述动作）
数据抽象是描述数据对象的冠名数据集合（描述动作怎么做）
2.体系结构（Architecture）：软件的整体结构和这种结构为系统提供概念完整方式。构件表示主要的系统元素及其交互。
3.模式（Patterns）：模式承载了已证实的解决方案的精髓。设计模式描述了在某个特定场景与可能影响模式应用和使用方法的“影响力”中解决某个特定的设计问题的设计结构。
4.关注点分离（Separation of concerns）：它表明任何复杂问题如果被分解为可以独立解决和优化的若干块，该复杂问题能够更容易的被处理。
5.模块化（Modularity）：模块化是关注点分离最常见的表现。模块化设计使得开发工作更易规划。
6.信息隐蔽（Hiding）：隐蔽意味着通过定义一系列独立的模块可以得到有效的模块化，独立模块互相之间只交流实现软件功能所必须的那些信息。隐蔽定义并加强了对模块内过程细节的访问约束和对模块所使用的任何局部数据结构的访问约束。
7.功能独立（Functional independence）：开发具有“专一”功能和低耦合性的模块即可实现功能独立。
8.求精（Refinement）：通过连续精化过程细节层次来实现程序的开发，通过逐步分解功能的宏观陈述直到形成程序设计语言的语句来进行层次开发。
抽象和精化是互补的概念。
9.方面（Aspects）：一个方面作为一个独立的模块进行实施，而不是作为“分割的”或者和许多构件“纠缠的”软件片段进行实施。设计体系结构应当支持定义一个方面，该方面即一个模块，该模块能够使该关注点经过它横切的所有其他关注点而得到实施。
10.重构（Refactoring）：重构是使用这样一种方式改变软件系统的过程：不改变代码的外部行为而是改进其内部结构。
11.面向对象的设计概念（OO design concepts）:
面向对象概念（类、对象、继承、消息和多态）
12.设计类（Design Class）：提供设计细节，使程序得以实施。
设计概念强调了：
（1）抽象的必要性，它提供了一种创造可重用软件构件的方法
（2）体系结构的重要性，它使得能够更好地理解系统整体结构
（3）基于模式的工程的有益性，它是一项用于已证明能力的软件的设计技术
（4）关注点分离和有效的模块化的价值，他们使得软件更容易理解、更容易测试以及更容易维护。
（5）信息隐藏的直接作用，当错误发生时，它能够减少负面影响的传播
（6）功能独立的影响，他是构造有效模块的标准
（7）求精作为一种设计方法的作用
（8）横切系统需求方面的考虑
（9）重构的应用，他是为了优化已导出的设计
（10）面向对象的类和与类相关特征的重要性
|
基本设计原则
开闭原则（Open-Closed Principle ，OCP）：模块应该对外延具有开放性，对修改具有封闭性。
依赖倒置原则（Dependency Inversion Principle ，DIP）：依赖于抽象，而非具体实现。
Liskov替换原则（Liskov Substitution Principle (LSP)）：子类可以替换他们的基类。
接口分离原则（The Interface Segregation Principle (ISP)）：多个客户专用接口比一个通用接口好
发布复用等价性原则（The Release Reuse Equivalency Principle，REP）：复用的粒度就是发布的粒度
共同封装原则（The Common Closure Principle (CCP)）：一同变更的类应该合在一起
共同复用原则（The Common Reuse Principle (CRP））：不能一起复用的类不能被分到一组
内聚性（Cohesion）：内聚性意味着构件或者类只封装那些相互关联密切，以及与构件或类自身有亲密关系的属性和操作。
功能内聚：主要通过操作来体现，当一个模块只完成某一组特定操作并返回结果时，就称此模块是功能内聚的。
分层内聚：高层能够访问低层的服务，但低层不能访问高层的服务。
通信内聚：访问相同数据的所有操作被定义在同一个类中。（数据的查询，访问，存储）
耦合性（Coupling）：
耦合是类之间彼此联系程度的一种定性度量。
随着类（构件）相互依赖越来越多，类之间的耦合程度亦会增加。
内容耦合：暗中修改其他构件的内部数据，这违反了信息隐蔽原则
公用耦合：当大量的构件都要使用同一个全局变量时发生这种耦合
控制耦合：当操作A调用操作B，并向B传递控制标记时，就会发生这种耦合。
标记耦合：当类B被声明为类A某一操作中的一个参数类型时，就会发生这种耦合。
数据耦合：当操作需要传递长串的数据参数时，就会发生这种耦合。
例程调用耦合：当一个操作调用另一个操作时，就会发生这种耦合。
类型使用耦合：当构件A使用了在构件B中定义的一个数据类型时，就会发生这种耦合。
包含或者导入耦合：当构件A引入或者包含一个构件B的包或者内容时，就会发生这种耦合。
外部耦合：当一个构件和基础设施构件进行通信和协作时，就会发生这种耦合。
为什么要高内聚?
模块之间的关系越紧密,出错就越少!
为什么要低耦合?
子程序间的关系越复杂,就会产生更多的意想不到的错误!会给以后的维护工作带来很多麻烦!
高内聚低耦合，是软件工程中的概念，是判断设计好坏的标准，主要是面向对象的设计，主要是看类的内聚性是否高，耦合度是否低。
|
