软件工程

Author: RiddMa

README.md

@@ -3,4 +3,6 @@
 ![GitHub last commit](https://img.shields.io/github/last-commit/BakaNetwork/computerArchitecture)
 
 - 进军教育蓝海
-- [Github Pages](https://bakanetwork.github.io/ComputerArchitecture/#/计算机系统结构.md)
+- [系统结构](https://bakanetwork.github.io/ComputerArchitecture/#/计算机系统结构.md)
+- [软件工程](https://bakanetwork.github.io/ComputerArchitecture/#/极限复习eXtremeReviewing.md)
+

_navbar.md

@@ -1,2 +1,4 @@
 - [README](./README.md)
 - [计算机系统结构](./计算机系统结构.md)
+- [软件工程](./极限复习eXtremeReviewing.md)
+

index.html

@@ -17,7 +17,7 @@
     <div id="app"></div>
     <script>
         window.$docsify = {
-            name: 'MJJ的计算机体系结构笔记',
+            name: 'Ridd的计算机体系结构笔记',
             repo: 'https://github.com/BakaNetwork/ComputerArchitecture',
             loadNavbar: true,
         }

极限复习.assets/image-20210619221424589.png

@@ -0,0 +1,230 @@
+# 软件工程概述
+
+软件的定义：软件是包括程序、数据及其相关文档的完整集合。
+
+软件工程定义：运用工程化原则和方法，组织软件开发解决软件危机。
+
+软件工程的目标：在<u>给定成本和时间</u>的前提下，开发出满足用户需求且具有<u>正确性、可用性</u>等因素的软件产品。
+
+软件工程的终极目标：摆脱手工生产软件的状况，逐步实现软件研制和维护的自动化。
+
+# 生命周期模型
+
+软件工程项目三个基本目标：合理的进度、有限的经费、一定的质量。
+
+戴明环：PDCA——Plan，Do，Check，Action。
+
+<u>软件工程过程</u>是为了获得软件产品，在软件工具的支持下由软件工程师完成的一系列软件工程活动。主要活动：
+
+* 软件规格说明：规定软件功能及其使用限制。
+* 软件开发：产生满足规格说明的软件。
+* 软件确认：通过有效性验证以保证软件能够满足客户要求。
+* 软件演进：为了满足客户变更要求，软件在使用过程中不断地改进。
+
+软件生命周期概念：软件产品从考虑其概念开始，到该产品不再使用为止的整个时期。
+
+软件生命周期六个基本步骤：制定计划P、需求分析D、设计D、程序编码D、测试C、运行维护A
+
+传统模型种类：瀑布模型、演化模型、增量模型、喷泉模型、V&W模型、螺旋模型、构件组装模型、快速应用开发模型、原型方法。
+
+软件生命周期模型：一个框架，描述整个软件生命周期内，软件开发、运行、维护所实施的全部过程、活动、任务。同时描述生命周期不同阶段产生的软件工件（Artifact），明确活动的执行角色等。
+
+## 模型
+
+瀑布模型：<u>**是所有其他软件生命周期模型的基础**</u>。
+
+* 文档驱动，本阶段的工作对象来自于上一阶段活动的输出文档。
+* 优点：
+	* 降低开发复杂度、提高透明性可管理性。
+	* 推迟了软件实现，强调必须先分析和设计。
+	* 以文档评审等手段指导整个开发过程。
+* 缺点：
+	* 缺乏灵活性，无法解决需求不明或不准确的问题。
+	* 风险控制能力较弱。
+	* 文档过多时，增加工作量。文档并不能完全反映实际项目情况，导致错误结论。
+* 适用范围：为早期软件开发消除非结构化软件、降低复杂度、促进软件工程化有显著作用。（就是没什么用）
+
+演化模型：
+
+* 提倡两次开发：第一次得到试验性的原型产品，探索可行性，明确需求。第二次在此基础上开发成品。
+* 优点：
+	* 明确用户需求、提高系统质量、降低开发风险。
+* 缺点：
+	* 难于管理、结构较差、技术不成熟。
+	* 可能会抛弃瀑布模型的文档控制优点。
+	* 缺乏设计，可能导致软件系统结构较差。
+* 适用范围：需求不清楚、小型系统、开发周期短。
+
+增量模型
+
+* 首先对系统最核心或最清晰的需求进行分析、设计、实现、测试。再按优先级逐步对后续的需求进行上述开发工作。<u>结合了瀑布模型和演化模型的优点。</u>
+* 优点：
+	* 第一次增量实现系统核心功能，增强客户使用系统的信心。
+	* 先开发核心功能，项目总体失败风险较低。
+	* 最高优先级的功能先开发，得到最多测试，保障可靠性。
+	* 增量在同一体系指导下进行集成，提高稳定性和可维护性。
+* 缺点：
+	* 难以选择增量粒度。
+	* 难以确定所有需求。
+
+喷泉模型（迭代模型）：
+
+* 高情商：各个开发阶段没有特定次序要求，可以并行进行，可以随时补充遗漏的需求（低情商：想到什么做什么，瞎JB写）。
+* 优点：提高开发效率、缩短开发周期。
+* 缺点：难于管理。
+* 适用于：需求不明晰。
+
+V和W模型：
+
+* 在瀑布模型基础上改进，把测试活动提前，使得模型能够驾驭风险。
+
+螺旋模型：
+
+* 分为四个象限螺旋上升：制定计划、风险分析、实施工程、客户评价——进入下一回路。
+* 适用于：开发周期长、风险高的大型软件。
+
+构件组装模型：
+
+* 模块化思想，使用复用构件库的组件搭建系统。
+
+* 优点：
+	* 软件复用、提高效率。
+	* 允许多项目同时开发，降低费用、提高可维护性。
+* 缺点：
+	* 缺乏通用构建组装标准风险较大。
+	* 构建可重用性与系统高效性不易协调。
+	* 过分依赖构件，构件质量影响产品质量。
+
+快速应用开发模型（RAD）：
+
+* 开发周期60-90天，分小组同步进行软件各部分开发。
+* 缺点：时间短，需要强沟通配合。不适合所有应用。
+* 适用于：信息管理系统的开发。
+
+原型方法：和增量好像也没什么区别。
+
+* 主要用于明确需求。
+
+RUP模型：基于瀑布模型演化而来。
+
+* 软件生命周期分解为4各阶段：初始阶段、细化阶段、构造阶段、移交阶段。每个阶段结束于一个重要的里程碑。
+	* 初始阶段：软件目标里程碑。细化阶段：体系结构里程碑。构造阶段：运行能力里程碑。移交阶段：产品发布里程碑。
+* 特点：用例驱动，软件体系结构为核心，应用迭代及增量。
+
+XP极限编程：基于敏捷建模思想，也是瀑布模型演化而来。
+
+* 强调用户满意，开发人员可以对需求的变化作出快速反应。
+
+# 软件需求分析
+
+需求分析的必要性：允许开发人员对问题细化并构建分析模型：
+
+* 数据模型：哪些数据进出系统、哪些数据需要存储？
+* 功能模型：对数据进行处理的功能有哪些？
+* 行为模型：数据进出系统和被系统功能处理的场景。
+
+需求分析的对象：用户要求。
+
+需求分析的任务：准确地定义新系统的目标，<u>回答</u>系统“做什么”的问题，**编写需求规格说明书**（结果）。
+
+需求分析的目标：导出目标系统的逻辑模型，<u>解决</u>目标系统“做什么”的问题。
+
+需求分析的操作性原则：
+
+* 表示和理解问题的**信息域**。
+* 定义软件**功能**。
+* 表示软件**行为**。
+
+用户需求说明书与软件需求规格说明书的区别：前者主要采用自然语言来表达用户需求，后者采用规范的建模语言表示。<u>后者是前者的细化，更多地采用计算机语言和图形符号来刻画需求。软件需求规格说明书是软件系统设计的直接依据。</u>
+
+需求规格说明书的内容：需求分析模型。（描述系统需要做什么，而非如何做系统）
+
+* 给出**当前系统及目标系统**的逻辑视图，以及**当前系统**的物理视图。
+	* 逻辑模型给出软件要达到的功能和处理数据之间的关系，而非实现细节。
+	* 物理模型给出业务环境中的业务实体和业务处理流程，是抽象出当前系统逻辑模型的基础。
+
+常用的建模分析方法有：SA（面向数据流的结构化分析方法）、JSD（面向数据结构的Jackson方法）、OOA（面向对象的分析方法）等。
+
+# 面向对象分析
+
+UML：面向对象的统一<u>建模</u>语言。是一种<u>建模语言规格说明</u>，是一种表示的标准。不是过程也不是方法，但允许任何一种过程和方法使用它。
+
+4+1视图：从不同视角为系统架构建模，形成系统的不同视图。分别为：
+
+* 用例视图（用户模型视图、场景视图）：强调从用户角度看到的或需要的系统功能。
+* 逻辑视图（结构模型视图、静态视图）：展现系统的静态或结构组成及特征。
+* 进程试图（行为模型视图、过程视图、协作视图、动态视图）：描述设计的并发和同步等特性，关注系统非功能性需求。
+* 构件视图（实现模型视图、开发视图）：关注代码的静态组织与管理。
+* 部署视图（环境模型视图、物理视图）：描述硬件的拓扑结构以及软件和硬件的映射问题，关注系统非功能性需求（性能、可靠性等）。
+
+<img src="极限复习.assets/image-20210619221424589.png" alt="image-20210619221424589" style="zoom: 67%;" />
+
+UML的9个基本图：
+
+* <u>用例图Use Case Diagram：从用户的角度描述系统的功能。</u>
+* <u>类图Class Diagram：描述系统的静态结构（类及其相互关系）。</u>
+* 对象图：描述系统在某个时刻的静态结构（对象及其相互关系）。
+* <u>顺序图Sequence Diagram：按时间顺序描述系统元素间的交互。</u>
+* <u>协作图Collaboration Diagram：按照时间空间的顺序描述系统元素间的交互和他们之间的关系。</u>
+* 状态图：描述系统元素（对象）的状态条件和响应。
+* 活动图：描述了系统元素之间的活动。
+* 构件图：描述了实现系统的元素（类或包）组织。
+* 部署图：描述了环境元素的配置并把实现系统的元素映射到配置上。
+
+UML视图与图的关系：
+
+* 用例视图——用例图。
+* 逻辑视图——类图、对象图、顺序图/协作图。
+* 进程试图——状态图、活动图。
+* 构件视图——构件图。
+* 部署视图——部署图。
+
+识别概念类或属性：
+
+* 属性一般是可以赋值的（如数字、文本），而概念类不可以。
+* 如果对一个名词是概念类还是属性不确定，将其作为概念类处理。
+* 不存在名词到类的映射机制，因为自然语言具有二义性。
+
+领域模型：领域内概念类或对象的抽象可视化表示。（将客观世界中的事物可视化抽象化）
+
+* 创建领域模型的步骤：
+	1. 找出当前需求中的候选概念类。
+	2. 在领域模型中描述这些概念类。用问题域中的词汇对概念类命名，将与当前需求无关的概念类排除。
+	3. 在概念类之间添加必要的关联来记录关系。用关联、继承、组合/聚合表示。
+	4. 在概念类中添加用来实现需求必要的属性。
+
+UML图的画法：
+
+* 类的基本结构：类名+属性+操作()。
+	* 构建领域模型时，不需要操作()。
+
+<img src="极限复习.assets/image-20210619234536567.png" alt="image-20210619234536567" style="zoom:50%;" />
+
+
+
+* 类之间的关系：
+
+![image-20210619234402936](极限复习.assets/image-20210619234402936.png)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+

极限复习.assets/image-20210619234402936.png

@@ -595,6 +595,28 @@ BHT 两个步骤：
 > - <u>一组向量指令的处理时间</u>
 > - 向量处理机的性能评估（MFLOPS 或一个浮点运算的时间）
 
+## 向量基本概念和处理方法
+
+向量处理机：设置了向量数据表示和向量指令的流水线处理机。
+
+向量处理机方式：
+
+- 横向处理方式：向量按 column 的方式从左到右横向进行。适用于一般处理机，不适用于向量处理机的并行处理。
+- 纵向处理方式：向量按 row 的方式从上到下纵向进行。将整个向量按相同运算处理完之后，再进行别的运算。不产生数据相关，对向量长度 N 没有限制。
+- 纵横处理方式：把向量分成若干组，组内按纵向方式处理，依次处理各组。对向量长度 N 没有限制，但以每 n 个元素分一组处理，n 的值固定。
+
+## 向量处理机结构
+
+存储器-存储器结构：适合纵向处理方式。
+
+- 源向量和目的向量都存放在存储器中，运算的中间结果需要送回存储器。
+- 对应的向量分量能并发访问，计算结果能并行地保存。
+- 普通存储器的 3 倍带宽：一个时钟周期内读出两个操作数并写回一个结果。
+
+寄存器-寄存器结构：适合纵横处理方式。
+
+-
+
 # 第九章 互连网络
 
 > <u>互连函数</u>