高级软件工程-课程总结

一定要努力哇

已于 2022-07-03 21:02:13 修改

阅读量434

点赞数 1

分类专栏：高级软件工程文章标签：软件工程

于 2022-07-03 20:59:31 首次发布

本文链接：https://blog.csdn.net/weixin_44831373/article/details/125571660

版权

高级软件工程专栏收录该内容

1 篇文章 0 订阅

订阅专栏

高级软件工程课程内容总结

一、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 reset —hard commit-id/commit-id的头几个字符 # 回退

Git团队版本库的用法

建议团队项目的每一个开发者都采用的工作流程大致如下：

Step1：克隆或同步最新的代码到本地存储库

git clone  仓库地址
git pull

Step2：为自己的工作创建一个分支，该分支应该只负责单一功能模块或代码模块的版本控制；

git checkout -b mybranch
git branch

Step3：在该分支上完成某单一功能模块或代码模块的开发工作；多次进行如下操作：

git add FILES
git commit -m "commit log"

Step4：最后，先切换回master分支，将远程origin/master同步最新到本地存储库，再合并mybranch到master分支，推送到远程origin/master之后即完成了一项开发工作。

git checkout master
git pull
git merge --no-ff mybranch 关闭快进式合并
git push

二、正则表达式

Vim的常用匹配

/word 向光标之下寻找⼀个名称为 word 的字符串
?word 向光标之上寻找⼀个字符串名称为 word 的字符串。
n 这个n是英⽂按键。代表重复前⼀个搜寻的动作。
N 这个N是英⽂按键。为『反向』进⾏前⼀个搜寻动作。
/yes|no|maybe 搜索多个字符串⽤｜
\c 表示⼤⼩写不敏感，⽐如/ignorecase\c
\C 表示⼤⼩写敏感

通配符

“.”表示任意⼀个字符
“?”表示前⼀个字符是否存在，也就是存在 0 次或 1 次
“+”表示前⼀个字符出现⼀次或多次
“*”表示前⼀个字符出现 0 次、 1 次或多次。
⼤括号{ }：指定模式的下限和上限数
- 匹配"aaah"中出现 3 到 5 次的 a，你的正则表达式将是a{3,5}h；
- 匹配"haaah"与⾄少出现 3 次的字⺟ a，正则表达式将是/ha{3,}h；
- 匹配"hah"中出现 3 次的字⺟ a，你的正则表达式将是/ha{3}h。
⽅括号[ ]：定义⼀组希望匹配的字符
- 创建正则表达式/b[aiu]g匹配"bag"， "big"和"bug"
连字符“-”：定义要匹配的字符范围
[a-e]：匹配小写字⺟a到e
字符“^”：定义不想要匹配的字符
在方括号之外的正则表达式中
插⼊字符“^”⽤于表示字符串的开头。
美元字符“$”表示字符串的末尾。

三、模块化

模块化的含义

模块化是在软件系统设计时保持系统内各部分相对独立，以便每⼀个部分可以被独⽴地进⾏设计和开发。这个做法背后的基本原理是关注点的分离 (SoC)分解成易解决的⼩问题,降低思考负担。每个模块只有⼀个功能，易于开发，并且bug会集中在少数⼏个模块内，容易定位软件缺陷，也更加容易维护。

编写高质量代码方式

1.通过控制结构简化代码(if else/while/switch)
2.通过数据结构简化代码
3.⼀定要有错误处理： Debug版本中所有的参数都要验证是否正确;Release版本中从外部(⽤户或别的模块)传递进来的参数要验证正确性。 肯定如何时⽤断⾔;可能发生时用错误处理。
4.注意性能优先的代价

人力成本远⼤于所消耗的计算资源成本时，提⾼代码编写的⼯作效率将更有价值；
质量保证的⼈⼒成本和质量保证的成效也⽐所消耗的计算资源成本更有价值；
性能优先的策略往往会让代码很难理解，结果需要消耗更多的⼯时；
⾯向机器的代码修改起来更困难， 可扩展性差，同样会消耗更多⼯时。

5.拒绝修修补补要不断重构代码

四、接口

接口的含义

接⼝就是互相联系的双⽅共同遵守的⼀种协议规范，在我们软件系统内部⼀般的接口⽅式是通过定义⼀组API函数来约定软件模块之间的沟通⽅式。换句话说，接⼝具体定义了软件模块对系统的其他部分提供了怎样的服务，以及系统的其他部分如何访问所提供的服务。

⾯向过程的编程中，接⼝⼀般定义了数据结构及操作这些数据结构的函数
⾯向对象的编程中，接⼝是对象对外开放（public）的⼀组属性和方法的集合

函数或⽅法具体包括名称、参数和返回值等。

接口的五个基本要素

1.接⼝的目的
2.接⼝使⽤前所需要满⾜的条件，⼀般称为前置条件或假定条件
3.使⽤接⼝的双⽅遵守的协议规范
4.接⼝使⽤之后的效果，⼀般称为后置条件
5.接⼝所隐含的质量属性（如响应时间）

五、需求

高质量需求特点

需求可测试
- 拟合标准形成了判断建议解决⽅案是否满⾜要求的客观标准：为可量化的需求设置合适的标准很容易、主观质量要求难以满⾜
- 帮助使需求可测试的三种⽅法：为每个副词和形容词指定定量描述、⽤实体的特定名称替换代词、确保每个名词都在需求⽂档中的⼀个位置定义
解决冲突
- 不同的涉众有不同的需求集：潜在的冲突想法
- 需要优先考虑需求
- 优先级划分可能将需求分为三类
  - 基本要求：绝对必须满⾜
  - 可取的：⾮常可取，但不是必需的
  - 可选：可能，但可以消除
需求特点
- 正确性、⼀致性、⽆⼆义性、全部、可⾏性、相关性、可测试、可追溯

需求分析的两类方法

原型化方法
- 原型化⽅法可以很好地整理出⽤户接⼝⽅式（UI， User Interface），⽐如界⾯布局和交互操作过程。
建模的方法
- 建模的⽅法可以快速给出有关事件发⽣顺序或活动同步约束的问题，能够在逻辑上形成模型来整顿繁杂的需求细节。

六、用例

用例的基本要素

⼀个⽤例应该由业务领域内的某个参与者所触发。
用例必须能为特定的参与者完成⼀个特定的业务任务。
⼀个用例必须终⽌于某个特定参与者，也就是特定参与者明确地或者隐含地得到了业务任务完成的结果。

用例建模的基本步骤

从需求表述中找出⽤例，往往是动名词短语表示的抽象⽤例；
描述⽤例开始和结束的状态，⽤TUCBW和TUCEW表示的⾼层⽤例；
对⽤例按照⼦系统或不同的⽅⾯进⾏分类，描述⽤例与⽤例、⽤例与参与者之间的上下⽂关系，并画出⽤例图；
进⼀步逐⼀分析⽤例与参与者的详细交互过程，完成⼀个两列的表格将参与者和待开发软件系统之间从⽤例开始到⽤例结束的所有交互步骤都列举出来扩展用例。
其中第⼀步到第三步是计划阶段，第四步是增量实现阶段。

七、设计模式

分类

根据作用对象
- 类模式：⽤于处理类与⼦类之间的关系，这些关系通过继承来建⽴，是静态的，在编译时刻便确定下来了。⽐如模板⽅法模式等属于类模式。
- 对象模式：⽤于处理对象之间的关系，这些关系可以通过组合或聚合来实现，在运⾏时刻是可以变化的，更具动态性。由于组合关系或聚合关系⽐继承关系耦合度低，因此多数设计模式都是对象模式。
根据任务类型
- 创建型模式：⽤于描述“怎样创建对象”，它的主要特点是“将对象的创建与使⽤分离”。⽐如单例模式、原型模式、建造者模式等属于创建型模式。
- 结构型模式：⽤于描述如何将类或对象按某种布局组成更⼤的结构，⽐如代理模式、适配器模式、桥接模式、装饰模式、外观模式、享元模式、组合模式等属于结构型模式。
  结构型模式分为类结构型模式和对象结构型模式
  前者采⽤继承机制来组织接⼝和类，后者⾤⽤组合或聚合来组合对象。由于组合关系或聚合关系⽐继承关系耦合度低，所以对象结构型模式⽐类结构型模式具有更⼤的灵活性。
- ⾏为型模式：⽤于描述程序在运⾏时复杂的流程控制，即描述多个类或对象之间怎样相互协作共同完成单个对象都⽆法单独完成的任务，它涉及算法与对象间职责的分配。⽐如模板⽅法模式、策略模式、命令模式、职责链模式、观察者模式等属于⾏为型模式。
  ⾏为型模式分为类⾏为模式和对象⾏为模式，前者采⽤继承在类间分配⾏为，后者采⽤组合或聚合在对象间分配⾏为。由于组合关系或聚合关系⽐继承关系耦合度低，所以对象⾏为模式⽐类⾏为模式具有更⼤的灵活性。

七大设计原则

开闭原则：软件应当对扩展开放，对修改关闭
里氏替换原则： 继承⽤法的原则，也就是什么时候应该使⽤继承，什么时候不应该使⽤继承，以及其中蕴含的原理。通俗来讲就是：⼦类可以扩展⽗类的功能，但不能改变⽗类原有的功能。
依赖倒置原则：⾼层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节， 细节应该依赖抽象。其核⼼思想是：要⾯向接⼝编程，不要⾯向实现编程。
在软件设计中，细节具有多变性，⽽抽象层则相对稳定，因此以抽象为基础搭建起来的架构要⽐以细节为基础搭建起来的架构要稳定得多。这⾥的抽象指的是接⼝或者抽象类，⽽细节是指具体的实现类。
依赖倒置原则在模块化设计中降低模块之间的耦合度和加强模块的抽象封装、提⾼模块的内聚度上具有普遍的指导意义。
单⼀职责原则：⼀个类应该有且仅有⼀个引起它变化的原因，否则类应该被拆分。核⼼就是控制类的粒度大小、提⾼其内聚度。
迪⽶特法则： 最少知道原则，如果两个软件实体⽆须直接通信，那么就不应当发⽣直接的相互调⽤，可以通过第三⽅转发该调⽤。其⽬的是降低类之间的耦合度，提⾼模块的相对独⽴性。
合成复⽤原则：⼜叫组合/聚合复⽤原则，要求在软件复⽤时，要尽量先使用组合或者聚合关系来实现，其次才考虑使⽤继承关系来实现。如果要使⽤继承关系，则必须严格遵循Liskov替换原则。通常类的复⽤分为继承复⽤和对象组合复⽤两种。
- 继承复⽤的缺点
  优点：简单、易实现
  缺点：继承复⽤破坏了类的封装性、⼦类与⽗类的耦合度⾼、限制了复⽤的灵活性，实现是静态的
- 合成复⽤
  优点：可以将已有对象纳⼊新对象中，使之成为新对象的⼀部分，新对象可以调⽤已有对象的功能。维持了类的封装性、新旧类之间的耦合度低、复⽤的灵活性⾼，可以在运⾏时动态进⾏
接⼝隔离原则

八、架构

软件架构风格和策略

管道-过滤器：⾯向数据流的软件体系结构，最典型的应⽤是编译系统，对源代码处理的过滤器通过管道连接起来，实现了端到端的从源代码到编译⽬标的完整系统。
客户-服务：客户代码通过请求和应答的⽅式访问或者调⽤服务代码。客户是主动的，服务是被动的。具有典型的模块化特征，降低了系统中客户和服务构件之间耦合度，提⾼了服务构件的可重⽤性。
P2P：客户-服务模式的⼀种特殊情形， P2P架构中每⼀个构件既是客户端⼜是服务端，即每⼀个构件都有⼀种接⼝，该接⼝不仅定义了构件提供的服务，同时也指定了向同类构件发送的服务请求。
发布-订阅：有两类构件：发布者和订阅者。如果订阅者订阅了某⼀事件，则该事件⼀旦发⽣，发布者就会发布通知给该订阅者。观察者模式体现了发布-订阅架构的基本结构。由于订阅者数量庞⼤往往在消息推送时采⽤消息队列的⽅式延时推送。
CRUD：代表了⼀种围绕中心化管理系统关键数据的软件架构⻛格。 CRUD 是创建（Create）、读取（Read）、更新（Update）和删除（Delete）四种数据库持久化信息的基本操作的助记符，表示对于存储的信息可以进⾏这四种持久化操作。
层次化：从垂直纵深的⻆度将软件单元按层次化组织，每⼀层为它的上⼀层提供服务，同时⼜作为下⼀层的客户。如⽹络中的OSI模型

软件架构的描述方法

软件架构模型是通过⼀组关键视图来描述的，同⼀个软件架构，由于选取的视⻆和抽象层次不同可以得到不同的视图，这样⼀组关键视图搭配起来可以完整地描述⼀个逻辑⾃洽的软件架构模型。
每个视图都是从不同的⻆度对软件架构进⾏描述和建模，⽐如从功能的⻆度、从代码结构的⻆度、从运⾏时结构的⻆度、从⽬录⽂件的⻆度，或者从项⽬团队组织结构的⻆度。

分解视图：分解是构建软件架构模型的关键步骤，分解视图也是描述软件架构模型的关键视图，⼀般分解视图呈现为较为明晰的分解结构特点。分解视图⽤软件模块勾划出系统结构，往往会通过不同抽象层级的软件模块形成层次化的结构。

分解视图中常⻅的软件模块术语：⼦系统、包、类、组件、库、软件模块、软件单元
依赖视图：展现了软件模块之间的依赖关系。能帮助找到没有依赖关系的软件模块或⼦系统，以便独⽴开发和测试，同时进⼀步根据依赖关系确定开发和测试软件模块的先后次序，变更和维护中理清对其他软件模块带来影响范围。
泛化视图：展现了软件模块之间的⼀般化或具体化的关系，典型的例⼦就是⾯向对象分析和设计⽅法中类之间的继承关系。值得注意的是，采⽤对象组合替代继承关系，并不会改变类之间的泛化特征。有助于描述软件的抽象层次，从⽽便于软件的扩展和维护。
执行视图：展示了系统运行时的时序结构特点，⽐如流程图、时序图等。执⾏视图中的每⼀个执⾏实体，⼀般称为组件，可以最终分解到软件的基本元素和软件的基本结构，因⽽与软件代码具有⽐较直接的映射关系。
实现视图：描述软件架构与源文件之间的映射关系。典型的实现视图就可以由软件项⽬的源⽂件⽬录树来呈现。有助于维护时在海量源代码⽂件中找到具体的某个软件单元的实现。
部署视图：将执⾏实体和计算机资源建立映射关系。这⾥的执⾏实体的粒度要与所部署的计算机资源相匹配。有助于分析⼀个设计的质量属性。
⼯作任务分配视图：将系统分解成可独⽴完成的⼯作任务，以便分配给各项⽬团队和成员。

对软件工程的个人理解

在了解软件工程之前，我们要先了解什么是软件，简单而言，软件就是程序和数据以及相关文档的总称。而软件工程通俗而言就是用工程化的方式开发软件。而软件工程的特性包括不可视性与主观性、软件规模与复杂性、易变性与不确定性、精确性与模糊性。通过本学期对软件工程的学习，对MVC架构和MVVM架构有了进一步的认识。

MVC架构

在这里插入图片描述
MVC 是一种使用 MVC（Model View Controller 模型-视图-控制器）设计创建 Web 应用程序的模式
**Model（模型）**表示应用程序核心（如数据库）。
**View（视图）**显示效果（HTML页面）。
**Controller（控制器）**处理输入（业务逻辑）。
MVC 模式同时提供了对 HTML、CSS 和 JavaScript 的完全控制。

Model（模型）是应用程序中用于处理应用程序数据逻辑的部分。通常模型对象负责在数据库中存取数据。
View（视图）是应用程序中处理数据显示的部分。通常视图是依据模型数据创建的。
Controller（控制器）是应用程序中处理用户交互的部分。通常控制器负责从视图读取数据，控制用户输入，并向模型发送数据。

优点

耦合性低
重用性高
生命周期成本低
MVC使开发和维护用户接口的技术含量降低。
部署快
可维护性高
分离视图层和业务逻辑层也使得WEB应用更易于维护和修改。
有利软件工程化管理

缺点

没有明确的定义
不适合小型，中等规模的应用程序
增加系统结构和实现的复杂性
视图与控制器间的过于紧密的连接
视图对模型数据的低效率访问
一般高级的界面工具或构造器不支持模式

典型应用：前端开发框架Anuglar

<input  ng-model="ball.basketball"  />

.contronller('BallController', ($scope) => {
    const ball = {
        basketball: '我是蔡徐坤'
    }
    
    $scope.ball = ball
})

input是MVC中的V（view）视图。
controller是MVC中的C（controller）控制器。
ball是MVC中的M（model）模型。

MVVM架构

MVVM是Model-View-ViewModel的简写。它本质上就是MVC 的改进版。MVVM 就是将其中的View 的状态和行为抽象化，让我们将视图 UI 和业务逻辑分开。当然这些事 ViewModel 已经帮我们做了，它可以取出 Model 的数据同时帮忙处理 View 中由于需要展示内容而涉及的业务逻辑。微软的WPF带来了新的技术体验，如Silverlight、音频、视频、3D、动画……，这导致了软件UI层更加细节化、可定制化。同时，在技术层面，WPF也带来了诸如Binding、Dependency Property、Routed Events、Command、DataTemplate、ControlTemplate等新特性。MVVM（Model-View-ViewModel）框架的由来便是MVP（Model-View-Presenter）模式与WPF结合的应用方式时发展演变过来的一种新型架构框架。它立足于原有MVP框架并且把WPF的新特性糅合进去，以应对客户日益复杂的需求变化。
在这里插入图片描述
模型：模型是指代表真实状态内容的领域模型（面向对象），或指代表内容的数据访问层（以数据为中心）。
视图：就像在MVC和MVP模式中一样，视图是用户在屏幕上看到的结构、布局和外观（UI）。
视图模型：视图模型是暴露公共属性和命令的视图的抽象。MVVM没有MVC模式的控制器，也没有MVP模式的presenter，有的是一个绑定器。在视图模型中，绑定器在视图和数据绑定器之间进行通信。
绑定器：声明性数据和命令绑定隐含在MVVM模式中。在Microsoft解决方案堆中，绑定器是一种名为XAML的标记语言。绑定器使开发人员免于被迫编写样板式逻辑来同步视图模型和视图。在微软的堆之外实现时，声明性数据绑定技术的出现是实现该模式的一个关键因素。