《高级软件工程》课程总结

参考资料：代码中的软件工程

一. 工欲善其事必先利其器

第一部分主要介绍了软件工程相关工具的使用，如VSCode、git、vim等，其中给我帮助最大的时git和正则表达式的学习。

1、git

git的基本逻辑操作

常用git命令：

命令	作用
git init	初始化一个本地版本库
git status	查看当前工作区（workspace）的状态
git add [FILES]	把文件添加到暂存区（Index）
git commit -m "wrote a commit log infro”	把暂存区里的文件提交到仓库
git log	查看当前HEAD之前的提交记录，便于回到过去
git reset —hard HEAD^^/HEAD~100/commit-id/commit-id	回退
git reflog	可以查看当前HEAD之后的提交记录，便于回到未来
git checkout -b mybranch	创建并切换到新分支

2、正则表达式

通配符	作用
.	匹配任意一个字符
+	匹配出现一次或多次的字符
*	匹配出现零次或多次的字符
?	匹配出现零次或一次的字符
{m, n}	某个字符出现m到n此
[abc]	匹配 a, b, c 中的字符
\w	等价于[A-Za-z0-9_]
\d	等价与 [0-9]

二. 代码中的软件工程

在这一部分主要学习了代码的编写规范，特别是接口部分印象深刻，定义一个简洁易懂的接口对我们日常阅读代码帮助非常大。

1、代码规范和代码风格

代码风格的原则：简明、易读、无二义性。

编写高质量代码的基本方法

• 通过控制结构简化代码
• 通过数据结构简化代码
• 要有错误处理
• 拒绝修修补补要不断重构代码

2、模块化软件设计

基本原理

模块化（Modularity）是在软件系统设计时保持系统内各部分相对独立，以便每一个部分可以被独立地进行设计和开发。这个做法背后的基本原理是关注点的分离 (SoC, Separation of Concerns)分解成易解决的小问题,降低思考负担。
每个模块只有一个功能，易于开发，并且bug会集中在少数几个模块内，容易定位软件缺陷，也更加容易维护。
软件设计中的模块化程度便成为了软件设计有多好的一个重要指标，一般我们使用耦合度 （Coupling）和内聚度（Cohesion）来衡量软件模块化的程度。

软件设计的基本方法

KISS（keep it simple&stupid）原则

• 一行代码只做一件事
• 一个块代码只做一件事
• 一个函数只做一件事
• 一个软件模块只做一件事

使用本地化外部接口来提高代码的适应能力

先写伪代码会更好一些

3、可重用软件设计

接口

接口就是互相联系的双方共同遵守的一种协议规范，在我们软件系统内部一般的接口方式是通过定义一组API函数来约定软件模块之间的沟通方式。
五大基本要素

• 接口的目的；
• 接口的前置条件；
• 接口的协议规范；
• 接口的后置条件；
• 接口的质量属性。

通用接口定义的基本方法

• 参数化上下文
• 移除前置条件
• 简化后置条件

三. 从需求分析到软件设计

1、获取需求的主要方法

需求类型

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

需求分析的两类基本方法

• 原型化方法
  可以很好地整理出用户接口方式（UI，User Interface），比如界面布局和交互操作过程。

• 建模的方法
  可以快速给出有关事件发生顺序或活动同步约束的问题，能够在逻辑上形成模型来整顿繁杂的需求细节。

2、用例建模

基本概念

用例（Use Case）的核心概念中首先它是一个业务过程（business process），经过逻辑整理抽象 出来的一个业务过程，这是用例的实质。什么是业务过程？在待开发软件所处的业务领域内完成特定业务任务（business task）的一系列活动就是业务过程。
四个必要条件

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

• 抽象用例（Abstract use case）：只要用一个干什么、做什么或完成什么业务任务的动名词短语，就可以非常精简地指明一个用例。
• 高层用例（High level usecase）：需要给用例的范围划定一个边界，也就是用例在什么时候什么地方开始，以及在什么时候什么地方结束；
• 扩展用例（Expanded usecase）：需要将参与者和待开发软件系统为了完成用例所规定的业务任务的交互过程一步一步详细地描述出来，一般我们使用一个两列的表格将参与者和待开发软件系统之间从用例开始到用例结束的所有交互步骤都列举出来。扩展用例最后可以用两列表格描述。

四. 软件科学基础概论

1、软件中的特殊机制

回调函数

回调函数是一个面向过程的概念，是代码执行过程的一种特殊流程。回调函数就 是一个通过函数指针调用的函数。把函数的指针（地址）作为参数传递给另一个 函数，当这个指针调用其所指向的函数时，就称这是回调函数。回调函数不是该函数的实现方直接调用，而是在特定的事件或条件发生时由另外的一方调用的， 用于对该事件或条件进行响应。
多态

在面向对象语言中，接口的多 种不同的实现方式即为多态。多态是实例化变量可以指向不同的实例对象，这样同一个实例化变量在不同的实例对象上下文环境中执行不同的代码表现出不同的行为状态 ，而通过实例化变量调用实例对象的方法的那一块代码却是完全相同的，这就顾名思义，同一段代码执行时却表现出不同的行为状态，因而叫多态。
闭包

闭包是变量作用域的一种特殊情形，一般用在将函数作为返回值时，该函数执行所需的上下文环境也作为返回的函数对象的一部分，这样该函数对象就是一个闭包。

2、设计模式

设计模式的本质是面向对象设计原则的实际运用总结出的经验模型。
根据设计模式可以完成的任务类型分为三类：

• 创建型模式：用于描述“怎样创建对象”，它的主要特点是“将对象的创建与使用分离”。比如单例模式、原型模式、建造者模式等属于创建型模式。
• 结构型模式：用于描述如何将类或对象按某种布局组成更大的结构，比如代理模式、适配器模式、桥接模式
  、装饰模式、外观模式、享元模式、组合模式等属于结构型模式。
• 行为型模式：用于描述程序在运行时复杂的流程控制，即描述多个类或对象之间怎样相互协作共同完成单个对象都无法单独完成的任务，它涉及算法与对象间职责的分配。比如模板方法模式、策略模式、命令模式、职责链模式、观察者模式等属于行为型模式。

常用设计模式
单例（Singleton）模式：某个类只能生成一个实例，该类提供了一个全局访问点供外部获取该实例，典型的应用如数据库实例。
原型（Prototype）模式：将一个对象作为原型，通过对其进行复制而克隆出多个和原型类似的新实例，原型模式的应用场景非常多，几乎所有通过复制的方式创建新实例的场景都有原型模式。
代理（Proxy）模式：为某对象提供一种代理以控制对该对象的访问。即客户端通过代理间接地访问该对象，从而限制、增强或修改该对象的一些特性。代理模式是不要和陌生人说话原则的体现，典型的应用如外部接口本地化将外部的输入和输出封装成本地接口，有效降低模块与外部的耦合度。
职责链（Chain of Responsibility）模式：为了避免请求发送者与多个请求处理者耦合在一起，将所有请求的处理者通过前一对象记住其下一个对象的引用而连成一条链；当有请求发生时，可将请求沿着这条链传递，直到有对象处理它为止。通过这种方式将多个请求处理者串联为一个链表，去除请求发送者与它们之间的耦合。
设计模式背后的设计原则

开闭原则
Liskov替换原则
依赖倒置原则
单一职责原则
迪米特法则
合成复用原则

3、常见软件架构

3、1 MVC 架构
MVC即为Model-View-Controller（模型-视图-控制器），MVC是一种设计模式，以MVC设计模式为主体结构实现的基础代码框架一般称为MVC框架，如果MVC设计模式决定了整个软件的架构，不管是直接实现了MVC模式还是以某一种MVC框架为基础，只要软件的整体结构主要表现为MVC模式，我们就称为该软件的架构为MVC架构。
MVC中M、V和C所代表的含义

• Model（模型）代表一个存取数据的对象及其数据模型。

• View（视图）代表模型包含的数据的表达方式，一般表达为可视化的界面接口。

• Controller（控制器）作用于模型和视图上，控制数据流向模型对象，并在数据变化时更新视图。控制器可以使视图与模型分离开解耦合。

3、2 MVVM 架构
MVVM模式和MVC模式一样，主要目的是分离视图（View）和模型（Model），有几大优点：

• 低耦合。视图（View）可以独立于Model变化和修改，一个ViewModel可以绑定到不同的"View"上，当View变化的时候Model可以不变，当Model变化的时候View也可以不变。
• 可重用性。你可以把一些视图逻辑放在一个ViewModel里面，让很多View重用这段视图逻辑。
• 独立开发。开发人员可以专注于业务逻辑和数据的开发（ViewModel），设计人员可以专注于页面设计。
  可测试。界面素来是比较难于测试的，测试可以针对ViewModel来写。

五. 软件危机与软件过程

1、软件危机

没有银弹

“在10年内无法找到解决软件危机的杀手锏（银弹）。 软件中的根本困难，即软件概念结构(conceptual structure)的复杂性，无法达成软件概念的完整性和一致性,自然无法从根本上解决软件危机带来的困境。
软件生命周期
分析、设计、实现、交付和维护五个阶段

• 分析阶段的任务是需求分析和定义,分析阶段一般会在深入理解业务的情况下，形成业务概念原型
• 设计阶段分为软件架构设计和软件详细设计，前者一般和分析阶段联系紧密，一般合称为“分析与设计”；后者一般和实现阶段联系紧密，一般合称为“设计与实现”。
• 实现阶段分为编码和测试，其中测试又涉及到单元测试、集成测试、系统测试等。
• 交付阶段主要是部署、交付测试和用户培训等。
• 维护阶段一般是软件生命周期中持续时间最长的一个阶段，而且在维护阶段很可能会形成单独的项目，从而经历分析、设计、实现、交付几个阶段，最终又合并进维护阶段。

2、V模型

V模型也是在瀑布模型基础上发展出来的，单元测试、集成测试和系统测试是为了在不同层面验证设 计，而交付测试则是确认需求是否得到满足。 通过将瀑布模型前后两端的过程活动结合起来，提高过程活动的内聚度，改善软件开发效率。

六、学习感想

在本学期《高级软件工程》的课程学习中，首先对于git等工具的使用让我学习到了规范的代码管理平台的使用，有助于后期的团队项目开发和个人项目管理，其次对一些代码规范和设计模式的深入了解，发现了自己之前写代码的一些坏习惯，然后学习到了规范的团队工程项目开发流程，更让我对软件工程这门学科有了更好的认识。