HIT 软件构造 4 :第1,3讲复习

目录

一、软件构造的多维度视图和质量目标

1. 软件构造的多维度视图(必考考点之一)

(1) Build-time Views

(2) Runtime Views

2. Software construction: Transformation between views

3. Quality properties of software systems(内部/外部质量指标,考点之一)

(1) External quality factors

(2) Internal quality factors

(3) Tradeoff between quality properties

4 Five key quality objectives of software construction

二、软件构造过程与配置管理

1. 软件配置管理SCM与版本控制系统VCS

(1) SCM

(2) VCS

2. Git的结构、工作原理和基本指令

(1) Git结构与工作原理

(2) Git的基本指令


一、软件构造的多维度视图和质量目标

目的:从三个维度看软件系统的构成,将“软件构造”看作“不同视图之间的转换”。

提纲:

按阶段划分:构造时/运行时视图

按动态性划分:时刻/阶段视图

按构造对象的层次划分:代码/构件视图

不同试图的转换关系:

空->代码;代码->构件;构造时->运行时;时刻->阶段

软件构造的5个关键要素:

1.便于阅读 2. 方便改写 3. 有可复用性 4.避免bug 5. 高效运行

1. 软件构造的多维度视图(必考考点之一)

总览图:(很重要,必考)

(1) Build-time Views

Build-time (构造阶段): idea -> requirement -> design -> code -> installable / executable package

code: 源代码和逻辑结构(函数、类、方法、接口)

Component :代码的物理组织(文件、目录、包、库)

moment:特定时刻的软件状态

period:软件形态随时间变化

(1) Build-time, moment, and code-level view

源代码是如何按基本程序块(如函数、类、方法、接口等)进行逻辑组织的,以及它们之间的依赖关系。三种相互关联的形式:

词汇层面:面向词法的源代码

半结构化:近乎自然语言的风格+遵循特定的编程语法  前者:方便程序员  后者:方便编译器

语法层面:面向语法的程序结构:例如抽象语法树(AST)

AST:彻底结构化,将源代码变为一棵树,对树做各种操作==对源代码的修改

语义层面:面向语义的程序结构:如类图

语义:源代码具体想实现什么目标? 源代码---现实世界

使用类图(UML)来描述接口、类、属性、方法以及它们之间的关系。基于图形的或正式定义的。通常是图形化或形式化的。在设计阶段建模,并转换为源代码。它是根据用户需求进行面向对象分析和设计的结果。

(2) Build-time, period, and code-level view

随时间变化。

代码变化:行增加、修改与删除,使文件从一个版本变化到另一版本。

(3) Build-time, moment, and component-level view

§ 源代码被物理地组织成文件,这些文件进一步组织到目录中去;

§ 文件被封装到包中,逻辑上是组件和子系统。

§ 可重用模块以库的形式出现。

库包括:1. 操作系统提供的库 2. 编程语言提供的库 3. 第三方公司提供的库 4. 自己积累的库

编程时和build时,需告诉IDE和JVM在哪里寻找某些库,可以使用静态链接和动态链接。

静态链接中,库被拷贝进入代码形成整体,执行的时候无需提供库文件。静态链接发生在构造阶段(build time)

(4) Build-time, period, and component-level view

各项软件实体随时间如何变化?1. Software Configuration Item(SCI),配置项 2.Version 版本

VCS - Version Control System(标注考点之一)

评价图描述了软件的开发过程和阶段。

软件版本控制是将唯一的版本名或唯一的版本号分配给计算机软件的唯一状态的过程。

–在给定的版本号类别(主要、次要)中,这些编号通常按递增顺序分配,并与软件的新开发相对应。

(2) Runtime Views

运行时:程序被载入目标机器,开始执行

code:逻辑实体在内存中你如何呈现

component:物理实体在物理硬件环境如何呈现

moment:特定时刻状态

period:随时间如何变化

一些高级概念:

可执行程序:CPU执行的机器可读指令序列,以及相关的数据值。是一个完全编译的程序,可以加载到计算机内存中并执行。

                原生机器码:执行代码的最快方式,因为程序完全访问CPU的功能 

                程序完全解释执行:运行时系统将整个源代码加载到内存中并对其进行解释 

                解释型字节码:字节码与本机代码类似,只是CPU不能直接理解它们。首先将它们转换                  为本机代码,或者在程序执行时解释它们。因此,字节码环境要求在程序旁边加载额外                  的解释器或编译器。

                执行Perl或Python脚本的简单动作会自动触发字节码的生成。

库:可以被不同程序重用的常用目标代码的集合。大多数操作系统都包含一组开发人员可以重用的标准库,而不是要求每个程序都提供自己的库。库不能直接在目标机器上加载和执行;它必须首先与可执行程序链接。

配置文件和数据文件:不是可执行文件。它们提供了程序可以从磁盘加载的有用数据和配置信息。

分布式程序:这种类型的软件由多个可执行程序组成,这些程序通过网络相互通信,或者只是作为多个进程在同一台机器上运行。与具有单一单片程序映像的更传统的软件形成了对比。

动态链接:库文件不会在build阶段被加入可执行软件,仅仅做出标记。程序运行时,根据标记装载库至内存。发布软件时,将程序所依赖的所有动态库都复制给用户。

(5) Run-time, moment, and code-level view

快照图:关注目标计算机内存中可变级别的执行状态

代码快照图(code Snapshot diagram):描述程序运行时内存里变量层面的状态

内存信息转储(Memory dump):硬盘上的一个文件,其中包含一个进程内存内容的副本,当某个进程被某种内部错误或信号中止时产生。

–调试器可以加载转储文件并显示其中包含的有关正在运行的程序状态的信息。

–信息包括寄存器的内容、调用堆栈和所有其他程序数据(计数器、变量、开关、标志等)。

–这是为了分析程序的状态,程序员查看内存缓冲区以查看在发生故障时正在处理哪些数据项

(6) Run-time, period and code-level view

执行跟踪(Execution tracing):用日志方式记录程序执行的调用次序

UML中的序列图:程序单元(对象)之间的交互

并发多线程(Concurrent multi-streads)

(7) Run-time, moment, and component-level view

UML中的部署图(Deployment diagram

(8) Run-time, period, and component-level view

事件日志(event logging):记录为系统管理员提供了诊断和审核有用的信息。

事件日志:系统层面

2.Software construction: Transformation between views

空 -> 代码:编程/编码(ADT/OOP);审查、静态分析/检查

代码 -> 组成部分:设计(ADT/OOP;可重用性;可维护性);构建:编译、静态链接、打包、安装等

构建时间 -> 运行时间:安装/部署;调试、单元/集成测试(健壮性和正确性)

moment -> period:版本控制;加载、动态链接、执行(转储、分析、日志记录);并发线程

3. Quality properties of software systems(内部/外部质量指标,考点之一)

外部质量因素:诸如速度或易用性之类的质量,其在软件产品中的存在或不存在可能被其用户检测到。  外部质量因素影响用户。

内部质量因素:适用于软件产品的其他质量,如模块化或可读性,只有能够访问实际软件文本的开发人员才能感知。 内部质量因素影响软件本身和它的开发者

外部质量取决于内部质量。

(1) External quality factors

1. 正确性

§ 正确性是软件产品执行其规范所定义的精确任务的能力。按照预先定义的“规约”执行

§ 正确是首要品质,是最重要的质量指标。

保证正确性的方法:

1. 测试与调试,发现不正确、消除不正确

2. 防御性编程,在写程序的时候就确保正确性

3. 形式化方法,通过形式化验证发现问题

2. 健壮性

健壮性是软件系统对异常情况做出适当反应的能力。(健壮性:针对异常情况的处理)

–正确性:软件的行为要严格的符合规约中定义的行为

–健壮性:出现规约定义之外的情形的时候,软件要做出恰当的反应,出现异常时不要“崩溃”

健壮性与“异常情况”有关,这意味着正常和异常情况的概念总是与某一特定规范相关

3.可拓展性

可扩展性:使软件产品适应规范变化的容易程度。(对软件的规约进行修改,是否足够容易)

规模越大,扩展起来越不容易

提高可扩展性有两个基本原则:简约主义设计和分离主义设计

4.可复用性

可重用性:软件元素为许多不同应用程序的构造服务的能力(一次开发,多次使用)

发现共性

5. 兼容性(Compatibility)

兼容性:将软件元素与其他元素相结合的容易程度。(不同的软件系统之间相互可容易的集成)

保持设计的同构性

6.性能

性能毫无意义,除非有足够的正确性,对性能的关注要与其他质量属性进行折中,过度的优化导致软件不再适应变化和复用

7.可移植性(Portability)

可移植性:将软件产品转移到各种硬件和软件环境的容易程度。(软件可方便的在不同的技术环境之间移植)

8.易用性

易用性:容易学、安装、操作、监控,给用户提供详细的指南

结构简单:一个设计良好的系统,按照一个清晰的、经过深思熟虑的结构构建,往往比一个杂乱无章的系统更容易学习和使用。

了解用户:一个好的设计师必须努力理解系统的预期用户群体。

9. 功能性(Functionality)

功能性:系统提供的可能性范围。

程序设计中一种不适宜的趋势,即软件开发者增加越来越多的功能,企图跟上竞争,其结果是程序极为复杂、不灵活、占用过多的磁盘空间。添加新功能可能会导致一致性丧失,忽略整体品质。

解决方法:每增加一小点功能,都确保其他质量属性不受到损失。

10.及时性

及时性:软件系统在用户需要时或之前发布的能力。

一个伟大的软件产品如果出现得太晚,可能会完全失去它的目标。

11.其他性质

可验证性:准备验收程序,特别是测试数据,以及在验证和运行阶段检测故障和跟踪错误的程序的容易程度。

完整性:是软件系统保护其各种组件(程序、数据)免受未经授权的访问和修改的能力。

可修复性:促进缺陷修复的能力。

经济性:与及时性相伴而生的是一个系统在其分配的预算之内或之下完成的能力。

(2) Internal quality factors

§ 与源代码相关的因素,如代码行(LOC)、圈复杂度等

§ 与架构相关的因素,如耦合、内聚等

§ 可读性

§ 可理解性

§ 清晰度

§ 大小

(3) Tradeoff between quality properties

正确的软件开发过程中,开发者应该将不同质量因素之间如何做出折中的设计决策和标准明确的写下来。虽然需要折中,但“正确性”绝不能与其他质量因素折中。

最重要的四个质量因素:

正确性、健壮性、可拓展性与可复用性。

4 Five key quality objectives of software construction

本课程的质量考虑

§ 优雅美丽的代码 -> 易于理解

§ 重用设计 -> 开发成本低

§ 低复杂性 -> 随时准备更改,易于扩展

§ 健壮性和正确性 -> 安全无bug,不易出错

§ 性能和效率 -> 运行效率高

二、软件构造过程与配置管理

此部分仅针对2021年考点。

1. 软件配置管理SCM与版本控制系统VCS

(1) SCM

软件配置管理(SCM):追踪和控制软件的变化,实现修订控制(revision comtrol)和建立基线(baseline)。

软件配置项(SCI):软件中发生变化的基本单元(例如:文件)

基线(baseline):软件持续变化过程中的“稳定时刻”(例如:对外发布的版本)

CMDB——配置管理数据库: 存储软件的各配置项随时间发生变化的信息 +基线

(2) VCS

版本:为软件的任一特定时刻(Moment)的形态指派一个唯一的编号,作为“身份标识”

古老的版本控制方法:通过复制文件并修改文件名

版本控制的必要性:

个人:1.回滚到上一个版本 2.比较两个版本的差异 3. 备份软件版本历史 4. 获取备份 5. 合并

团队:1.在多个开发者之间共享和协作 2. 记录每个开发者的动作,便于“审计”

多个版本之间,形成线性或分支结构

版本控制术语:

1. 仓库:即于SCM中的CMDB

2. 工作拷贝:在开发者本地机器上的一份项目拷贝

3. 文件:一个独立的配置项

4. 版本:在某个特定时间点的所有文件的共同状态

5. 变化:即code churn,两个版本之间的差异

6. HEAD:程序员正在其上工作的版本

VCS分类:

本地版本控制系统: 仓库存储于开发者本地机器,无法共享和协作

集中式版本控制系统:仓库存储于独立的服务器,支持多开发者之间的协作

分布式版本控制系统:仓库存储于独立的服务器+每个开发者的本地机器

2. Git的结构、工作原理和基本指令

(1) Git结构与工作原理

1. Git存储库

Git存储库有三个部分:

.git目录(存储所有版本控制数据的存储库) 本地的CMDB

–工作目录(本地文件系统)                          

–暂存区(内存中)隔离工作目录和Git仓库

每个文件都属于以下三种状态之一:

–修改(工作目录中的文件与git存储库中的文件不同,但不在暂存区域)   已修改

–暂存(文件已修改,并已添加到暂存区域)                                               已暂存

–提交(文件在工作目录和git目录中保持相同)                                            已提交

2. Git中的对象图

我们对Git所做的所有操作——克隆、添加、提交、推送、日志、合并等等——都是在一个图形数据结构上进行的操作,该结构存储了项目中所有版本的文件,以及描述这些更改的所有日志条目。

对象图是Git项目的历史,是一个有向无环图(DAG)。一条边 A->B表征了“在版本B的基础上作出变化,形成了版本A”

3. commits:对象图中的节点

历史图中的每个节点都是项目的commit a.k.a.版本a.k.a.修订版:该时间点上所有文件的完整快照。

1. 每个commit指向一个父亲

2. 多个commit指向同一个父亲:分支

3. 一个commit 指向两个父亲:合并

分支只是指向commit的名称。HEAD指向当前的commit。我们需要记住我们在哪个分支上工作。所以HEAD指向当前分支,这个分支指向当前的commit。

Git表示具有树节点的commit。

对于任何合理大小的项目,大多数文件在任何给定的修订版中都不会更改。存储文件的冗余副本将是浪费,所以Git不会这样做。相反,Git object graph只存储单个文件的每个版本一次,并允许多个提交共享一个副本。每个commit还具有日志数据—谁、何时、短日志消息等。

与传统VCS的区别:

文件未发生变化,则后续多个版本始终指向同一个文件

文件发生变化了,存储两份不同的文件,两个版本指向不同的文件

4. 分支/合并(Branch/Merge)

分支是处于修订控制下的对象的副本,以便可以沿两个分支并行进行修改。

合并两个分支。

5.支持协作

本地存储库和远程存储库

(2) Git的基本指令

创建分支: $ git branch mybranch

切换分支: $ git checkout mybranch

创建并切换分支: $ git checkout -b mybranch

删除分支: $ git branch -d mybranch

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值