高软课程总结

高软课程总结
本学期的上课的主要内容包括：
• 工欲善其事必先利其器——Typing - VSCode - Git - Vim - RegEx
• 代码中的软件工程——一个工程化C语言项目范例
• 需求分析与设计——从分析到设计的基本方法
• 软件系统设计——软件的结构、特性和描述方法
• 工程过程与项目管理——软件危机的前生后世
以下我根据个人对重点的理解进行分析和总结课程主要内容。

正则中的两种模式：
greedy 贪婪匹配找到符合正则表达式模式的字符串的最长可能部分，并将其作为匹配返回。相反还有
lazy 懒惰匹配，是找到符合正则表达式模式的字符串的最小可能部分。你可以将正则表达式t[a-z]i应用于字符串"titanic"。这个正则表达式基本上是以 t 开始的模式，以 i 结
尾，并且之间有0个、1个或多个字母。 正则表达式是默认的是 greedy 贪婪匹配，所以匹配将返回"titani"。它可以找到最大的子字符串，以符 合该模式。 但是可以使用?字符将其更改为 lazy 懒惰匹配。“titanic”匹配调整后的t[a-z]?i正则表达式会返回[“ti”]。
捕获组复用
可能搜索的某些模式在字符串中多次出现，手动重复这些正则表达式是浪费时间的。有一个更好的方法 可在你的字符串中有多个重复子串时进行指定，那就是capture groups 捕获组。用括号(xxx)可以定义 capture groups 捕获组，用于查找重复的子串，即把会重复的模式的正则表达式放在括号内。
要指定重复字符串的出现位置，可以使用反斜杠“\”，然后使用数字。该数字从 1 开始，并随着用括号定 义的捕获组数量而增加。比如\1 来匹配前面通过括号定义的第一个捕获组。
使用 capture groups 捕获组来匹配字符串中连续出现三次的数字，每个数字由空格分隔，如 (\d+)\s\1\s\1。（”1 1 1“匹配）（“1 2 3 ”不匹配）其实就是（）里就可以形成一个捕获组，正则表达式会缓存捕获组所匹配的串，应该是查找时的复用使 用\，\1 来匹配前面通过括号定义的第一个捕获组。

高质量需求的特点
需求是可测试的，可解决冲突（需求有优先级顺序），正确的、一致的、无二义性、完整的、可行的、 无与主要目标不相关的需求、可追溯的

需求类型

1. 功能需求：根据所需的活动描述所需的行为
2. 质量需求或非功能需求：描述软件必须具备的一些质量特性（响应时间）
3. 设计约束: 设计决策的约束，例如选择的平台或接口组件
4. 过程约束: 对可用于构建系统的技术或资源的限制

需求分析的两类基本方法
原型化方法:
可以很好地整理出用户接口方式（UI，User Interface），比如界面布局和交互操作过程。（原型化技术 的基本特征：（1）不要求在系统开发之初就完全掌握系统的所有需求；（2）原型需要反复的修改。原型法强调用户和开发人员不断对原型进行不断修改和补充，直到用户感到满意为止。）
建模的方法:
可以快速给出有关事件发生顺序、对象或活动同步约束的问题，能够在逻辑上形成模型来整顿繁杂的需求细节。

软件设计基本方法
KISS（keep it simple&stupid）原则
• 一行代码只做一件事
• 一个块代码只做一件事
• 一个函数只做一件事
• 一个软件模块只做一件事
使用本地化外部接口，本质上是一种设计模式，代理模式,即客户端通过代理间接地访问该对象，从而限制、增强或修改该对象的一些特性。能够有效降低模块与外部的耦合度。

用例满足的四个必要条件

必要条件一 :它是不是一个业务过程?
必要条件二:它是不是由某个参与者触发开始?
必要条件三:它是不是显式地或隐式地终止于某个参与者?
必要条件四: 它是不是为某个参与者完成了有用的业务工作?

用例的三个抽象层级

1. 抽象用例（Abstract use case）。只要用一个干什么、做什么或完成什么业务任务的动名词短语，
   就可以非常精简地指明一个用例。
   例如：“打电话” 2. 高层用例（High level use case）。需要给用例的范围划定一个边界，也就是用例从什么地方开
   始，以及在什么时候什么地方结束；
   例如：“打电话”这一用例的开始状态就是用户拿起电话机听筒准备拨号，终止状态就是用户听到了
   接通电话的铃声反馈。
2. 扩展用例（Expanded use case）。需要将参与者和待开发软件系统为了完成用例所规定的业务任
   务的交互过程一步一步详细地描述出来，一般我们使用一个两列的表格将参与者和待开发软件系统
   之间从用例开始到用例结束的所有交互步骤都列举出来。 扩展用例最后可以用两列表格描述。
   用例建模的基本步骤
3. 第一步，从需求表述中找出用例，往往是动名词短语表示的抽象用例； 2. 第二步，描述用例开始和结束的状态，用TUCBW和TUCEW表示的高层用例； 3. 第三步，对用例按照子系统或不同的方面进行分类，描述用例与用例、用例与参与者之间的上下文
   关系，并画出用例图； 4. 第四步，进一步逐一分析用例与参与者的详细交互过程，完成一个两列的表格将参与者和待开发软
   件系统之间从用例开始到用例结束的所有交互步骤都列举出来扩展用例。
   其中第一步到第三步是计划阶段，第四步是增量实现阶段。

统一过程的核心要义是什么

统一过程（UP，Unified Process）的核心要义是用例驱动（Use case driven）、以架构为中心 （Architecture centric）、增量且迭代（Incremental and Iterative）的过程。用例驱动就是我们前文中用例建模得到的用例作为驱动软件开发的目标；以架构（MVC/MVVM）为中心的架构是后续软件设计的结果，就是保持软件架构相对稳定，减小软件架构层面的重构造成的混乱；增量且迭代体现在下 图中。
增量：在预定的时间区间内渐进增加产品功能，强调软件在发布不同版本时，软件功能数量渐增的过 程。
迭代：是在实现软件的每一功能时反复求精的过程，是提升软件质量的过程，是从模糊到清晰的过程。

模块化的基本原理

模块化（Modularity）是在软件系统设计时保持系统内各部分相对独立，以便每一个部分可以被独立地 进行设计和开发。这个做法背后的基本原理是关注点的分离 (SoC, Separation of Concerns)。根源是由于人脑处理复杂问题时容易出错，把复杂问题分解成一个个简单问题，从而减少出错的情形。

本地化外部接口是什么含义
接口就是互相联系的双方共同遵守的一种协议规范，在我们软件系统内部一般的接口方式是通过定义一组API函数来约定软件模块之间的沟通方式
在面向过程的编程中，接口一般定义了数据结构及操作这些数据结构的函数；（我感觉已经很类似 于面向对象的类了）

而在面向对象的编程中，接口一般是在类或接口类中定义一些公有的（public）属性和方法。（函 数或方法具体包括名称、参数和返回值等）

接口的5个基本要素

1. 接口的目的
2. 接口的前置条件 （参数）
3. 接口的协议规范（例如传递的参数是个双方都知道的规定好的某个数据结构；又如http协议，png 图片格式，json数据格式定义etc…）
4. 接口的后置条件 （返回值返回的是什么）
5. 接口的质量属性（如响应时间）

通用接口定义的基本方法

1. 参数化上下文(使用参数来传递信息,函数内的上下文环境不依赖函数外的上下文环境而依赖于传递进来的参数)
2. 移除前置条件(sum函数中使用数组传递参数,不再限定参数个数)
3. 简化后置条件（返回值返回的是什么）(使sum返回的是数组全部元素的和，而不是数组中哪几个数（哪几个数这就是个额外的后置条件）的和)

关系数据模型 分布式数据库
关系数据库
就是平时一直学的那些以行和列的形式存储数据，以便于用户理解，关系型数据库这一系列的行和列被
称为表，一组表组成了数据库。
MongoDB是非关系型，分布式数据库
三种基本的设计方案：内嵌，子引用，父引用
在选择方案时需要考虑的两个关键因素：1）一对多中的多是否需要一个单独的实体；2)这个关系中集合
的规模是一对很少，很多，还是非常多。
一对很少且不需要单独访问内嵌内容的情况下可以使用内嵌多的一方。内嵌
一对很多且很多的一端内容因为各种理由需要单独存在的情况下可以通过数组的方式引用多的一方的。
子引用
一对非常多的情况下，请将一的那端引用嵌入进多的一端对象中。父引用
双向关联Two-Way Referencing：其实就是两边都互相存有，易于搜寻关系，但修改关系时（就是将
A_person和A_task的关系换成另一个B_person和A_task的关系）也需要修改两个对象了，无法原子更
新。
反范式化（其实就是把可能经常要用到的那个数据和id一样也冗余存储过来）意味着你不需要执行一个
应用层级别的join去显示一个产品所有的零件名字，当然如果你同时还需要其他零件信息那这个应用层
的join是避免不了的。
反范式化在节省你读的代价的同时会带来更新的代价：如果你将零件的名字冗余到产品的文档对象中，
那么你想更改某个零件的名字你就必须同时更新所有包含这个零件的产品对象。（所以应当只冗余读多
改少的属性）
反序列化冗余属性的方法可以用于把多的那方冗余到一的这方（一对很（较）多），同样也可以将一的
这方属性冗余过去多的那方（一对非常多）。
总结：
使用双向引用来优化你的数据库架构，前提是你能接受无法原子更新的代价。
可以在引用关系中冗余数据到one端或者N端。
在决定是否采用反范式化时需要考虑下面的因素：
你将无法对冗余的数据进行原子更新。
只有读写比 （多读少写）比较高的情况下才应该采取反范式化的设计。

依赖倒置原则的含义及其应用价值
依赖倒转原则 (Dependence Inversion Principle) 高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象 。由于在软件设计中，细节具有多变性，而抽象层则相对稳定，因此以抽象为基础搭建起来的架构要比以细节为基础搭建起来的架构要稳定得多。 （这里的抽象指的是接口或者抽象类，而细节是指具体的实现类。）
先使用接口或者抽象类制定好规范和契约，之后的实现则尽量面向接口的编程来降低类间的耦合性。

MVC架构为什么更灵活以及MVVM架构为什么更智能（10分）
MVC: 为了包容需求上的变化而导致的用户界面的修改不会影响软件的核心功能代码，可以采用将模型（Model）、视图（View）和控制器（Controller）相分离的思想，则可以自行实现V和M之间的业务逻辑处理更加灵活。
MVVM: View和Model之间没有联系，通过ViewModel进行交互，而且Model和ViewModel之间的交互 是双向的，因此视图的数据的变化会同时修改数据源，而数据源数据的变化也会立即反应到View上。

执行视图、部署视图、分解视图等各种视图的含义
同一个软件架构，由于选取的视 角不同（Perspective）可以得到不同的视图
一般来说，我们常用的几种视图有分解视图、依赖视图、泛化视图、执行视图、实现视图、部署视图和工作任务分配视图。
分解视图 （获得软件模块）：分解是构建软件架构模型的关键步骤，分解视图也是描述软件架构模 型的关键视图，一般分解视图呈现为较为明晰的分解结构（breakdown structure）特点。分解视图用软件模块勾划出系统结构，往往会通过不同抽象层级的软件模块形成层次化的结构。
依赖视图 ：依赖视图展现了软件模块之间的依赖关系。比如一个软件模块A调用了另一个软件模块B，那么我们说软件模块A直接依赖软件模块B。如果一个软件模块依赖另一个软件模块产生的数据，那么这两个软件模块也具有一定的依赖关系。
泛化视图 ：泛化视图展现了软件模块之间的一般化或具体化的关系，典型的例子就是面向对象分析和设计方法中类之间的继承关系。值得注意的是，采用对象组合替代继承关系，并不会改变类之间的泛化特征。因此泛化是指软件模块之间的一般化或具体化的关系，不能局限于继承概念的应用。
执行视图 ：执行视图展示了系统运行时的时序结构特点，比如流程图、时序图等。执行视图中的每一个执行实体，一般称为组件（Component），都是不同于其他组件的执行实体。如果有相同或相似的执行实体那么就把它们合并成一个。
实现视图 ：
实现视图是描述软件架构与源文件之间的映射关系。比如软件架构的静态结构以包图或设计类图的方式来描述，但是这些包和类都是在哪些目录的哪些源文件中具体实现的呢？一般我们通过目录和源文件的命名来对应软件架构中的包、类等静态结构单元，这样典型的实现视图就可以 由软件项目的源文件目录树来呈现。
部署视图 ：部署视图是将执行实体和计算机资源建立映射关系。这里的执行实体的粒度要与所部署的计算机资源相匹配，比如以进程作为执行实体那么对应的计算机资源就是主机，这时应该描述进程对应主机所组成的网络拓扑结构，这样可以清晰地呈现进程间的网络通信和部署环境的网络结构特点。当然也可以用细粒度的执行实体对应处理器、存储器等。
工作任务分配视图 ：工作分配视图将系统分解成可独立完成的工作任务，以便分配给各项目团队和成员。工作分配视图有利于跟踪不同项目团队和成员的工作任务的进度，也有利于在个项目团队和成员之间合理地分配和调整项目资源，甚至在项目计划阶段工作分配视图对于进度规划、项目评估
和经费预算都能起到有益的作用。

没有银弹的含义

即软件概念结构(conceptual structure)的复杂性，无法达成软件概念的完整性和一致性，自然无法从根本上解决软件危机带来的困境。

简述v模型

V模型是将开始一个特定过程的过程活动和评估该特定过程的过程活动成对出现，从而便于软件开发过 程的组织和管理。

简述敏捷宣言的核心思想

个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划