软件构造复习第三章 软件构造过程与配置管理

软件开发生命周期 Software Development Lifecycle (SDLC)

1. From 0 to 1 从无到有
   SDLC的示意图如下
   
   可以看到 软件计划，分析需求，设计软件，软件实现，测试与集成，软件维护，再到软件计划 形成了一个闭环，这就是软件开发的生命周期。
2. From 1 to n 从有到好
   开发出来的软件需要经历版本的迭代，从初始的版本逐渐升级。

Traditional Software Process Models

基本类型可以为线性过程(Linear)和迭代过程(Iterative)
现有的传统软件开发模型：

• 瀑布过程 Waterfall (Linear, non-iterative)
• 增量过程 Incremental (non-iterative)
• V字模型 V-Model (for verification and validation)
• 原型过程 Prototyping (iterative)
• 螺旋模型 Spiral (iterative)
  选择何种开发模型的影响因素有：
• 用户的参与程度 也就是软件适应变化的能力的要求有多高
• 开发的效率、管理的复杂度
• 开发出的软件的质量

瀑布过程 Waterfall (sequential, non-iterative)

瀑布过程的特点

• 线性推进
• 阶段划分清楚
• 整体推进
• 无迭代
• 管理简单
• 无法适应需求的增加/变化

开发流程
需求(Requirement)$\to$设计(Design)$\to$实现(Implementation)$\to$验证(Verification)$\to$维护(Maintenance)

增量过程 Incremental (non-iterative)

增量过程的特点

• 线性推进
• 增量式(多个瀑布的串行)
• 无迭代
• 比较容易适应需求的增加

V字模型 V-Model (for verification and validation)

可以认为是瀑布模型的扩展
该模型将开发流程在**代码实现(Implementation)**弯曲，来更好的展示开发生命周期的每个阶段与其相关的测试阶段之间的关系。
下图为示意图

水平轴表示时间或项目完整性（从左到右）
垂直轴表示抽象级别

原型过程 Prototyping (iterative)

开发过程如下

该过程的主要特点就是在原型上持续不断的迭代，发现用户变化的需求。循环往复这个过程，直到用户满意为止。 时间代价高，但开发质量也高
迭代：开发出来之后由用户试用/评审，发现问题反馈给开发者，开发者修改原有的实现，继续交给用户评审。

螺旋模型 Spiral (iterative)

非常复杂的过程：

• 多轮迭代基本遵循瀑布模式
• 每轮迭代有明确的目标 ，遵循原型过程， 进行严格的风险分析， 方可进入下一轮迭代

Agile Development

敏捷开发：通过快速迭代和小规模的持续改进，以快速适应变化
敏捷宣言的核心价值

• 个体和互动高于流程和工具 Individuals and interactions over processes and tools
• 工作的软件高于详尽的文档 Working software over comprehensive documentation
• 客户合作高于合同谈判 Customer collaboration over contract negotiation
• 响应变化高于遵循计划 Responding to change over following a plan

Agile = 增量 + 迭代 每次迭代处理一个小规模增量

• 极限的用户参与
• 极限的小步骤迭代
• 极限的确认/验证

Software Configuration Management (SCM) and Version Control System (VCS)

软件配置管理Software Configuration Management (SCM)

追踪和控制软件的变化，包括修订控制，基线的建立
软件配置项Software Configuration Item (SCI)：软件中发生变化的基本单元（例如：文件）
基线baseline：软件持续变化过程中的“稳定时刻”（例如：对外发布的版本）
CMDB配置管理数据库：用于存储软件的各配置项随时间发生变化的信息+基线

Versioning 版本控制

版本：为软件的任一特定时刻（Moment）的形态指派一个唯一的编号，作为身份标识
古老的版本控制方法：通过复制文件并修改文件名
版本控制存在的原因：
对于个人开发者

• 回滚到上一个版本
• 比较两个版本的差异
• 备份软件版本历史
• 获取备份
• 合并 Merging versions that are offshoots of the same earlier version

对于团队协作

• 在多个开发者之间共享和协作
• 记录每个开发者的动作，便于“审计”

版本控制的一些术语：

• Repository: a local or remote store of the versions in a project 仓库：即于SCM中的CMDB
• Working copy: a local, editable copy of a project that we can work on 工作拷贝：在开发者本地机器上的一份项目拷贝
• File: a single file in the project 文件：一个独立的配置项
• Version or revision: a record of the contents of the project at a point in time 版本：在某个特定时间点的所有文件的共同状态
• Change or diff: the difference between two versions 变化：即code churn，两个版本之间的差异
• Head: the current version HEAD：程序员正在其上工作的版本

Version Control System (VCS)分类

• Local VCS本地版本控制系统： 仓库存储于开发者本地机器，无法共享和协作
• Centralized VCS集中式版本控制系统：仓库存储于独立的服务器，支持多开发者之间的协作
• Distributed VCS 分布式版本控制系统：仓库存储于独立的服务器+每个开发者的本地机器

Git as an example of SCM tool

Git：Git
Git百科：Git百度百科
一个Git仓库包含三个部分

• .git目录 本地的CMDB (a repository storing all version control data)
• Working目录 工作目录：本地文件系统
• Staging area (in memory) 暂存区：隔离工作目录和Git仓库

每个文件都处于以下三个状态之一

• 已修改 Modified (the file in working directory is different from the one in git repository, but is not in staging area)
• 已暂存 Staged (the file is modified and has been added into the staging area)
• 已提交 Committed (the file keeps same in working directory and git directory)

Git 中的 Object graph

Object graph 版本之间的演化关系图。
图中一条边 A$\to$B表示 在版本B的基础上做出变化，形成版本A

Commits: 图中的顶点
Commit（除了起始）的指向有三种情况：

• 指向一个父亲
• 多个 Commit指向同一个父亲 分支 ，一个分支branch 也就是指向某个commit（A branch is just a name that points to a commit.）
• 一个 Commit 指向两个父亲：合并

下面两幅图展示了git创建与合并分支的实例

Git与传统VCS之间的不同

传统VCS存储版本之间的变化（行）

Git存储发生变化的文件（而非代码行）， 不变化的文件不重复存储
文件未发生变化，则后续多个版本始终指向同一个文件
文件发生变化了，存储两份不同的文件，两个版本指向不同的文件

Github: a web-based Git server and Internet hosting service.
Basic process: commit, branch and merge
Collaboration process: fork and pull request

General process of software construction

Programming

程序的构造语言Construction languages
从用途上划分可分为

• Programming languages (e.g., C, C++, Java, Python) 编程语言
• Modeling languages (e.g., UML) 建模语言
• Configuration languages (e.g., XML) 配置语言
• Build languages (e.g., XML) 构建语言

从形态上划分

• Linguistic-based 基于语言学的构造语言
• Mathematics-based (formal) 基于数学的形式化构造语言
• Graphics-based (visual) 基于图形的可视化构造语言

接下来基于构造语言用途划分叙述

Programming languages 编程语言

常见的编程语言包括C,Java,Python等等，这里介绍编程时所使用的集成开发环境。
Integrated development environment (IDE): comprehensive facilities to programmers for software development.
集成开发环境通常由以下部分组成：

• 源代码编辑器、智能代码补全工具、代码重构工具
• File management tool 文件管理
• Library management tool 库管理
• Class browser, object browser, class hierarchy diagram 软件逻辑实体可视化
• Graphical User Interface (GUI) builder 图形化用户界面构造器
• Compiler, interpreter 编译器、解释器
• Build automation tools 自动化build工具
• Version control system 版本控制系统
• Extensible by more external third-party tools 外部的第三方工具

Modeling languages 建模语言

建模语言是一种人工语言，可以用来表达信息、知识或系统，其结构由一组一致的规则定义，目的是可视化、推理、验证和交流系统的设计，常用的如UML语言。
UML Unified Modeling Language

Configuration languages 配置语言

配置语言写成的配置文件配置好程序的参数以及初始设置。
例如Key-Value texts (.ini, .properties, .rc, etc) , XML, YAML, JSON
可以区分开稳定和不稳定的部分，以及在程序运行时改变程序的行为

Review and static code analysis

Review 代码评审
形式有：结对编程，走查，正式评审会议，自动化评审
Static code analysis 利用工具进行的静态代码分析（程序不运行）
常见java的静态分析工具：CheckStyle, SpotBugs, PMD

Dynamic code analysis / profiling

动态分析：要执行程序并观察现象、收集数据、分析不足
Profiling 剖析：对代码的运行时状态和性能进行度量，发现代码中的潜在问题

Debugging and Testing

测试：发现程序是否有错误
调试：定位错误、发现错误根源

Refactoring

重构：在不改变功能的前提下优化代码 目的是为了让代码易于维护，以及更加模式化

Narrow-sense process of software construction (Build)

• Build system: components and process
• Build variants and build language
• Build tools: Make, Ant, Maven, Gradle, Eclipse

Validate$\to$Compile$\to$Link$\to$Test$\to$Package$\to$Install$\to$Deploy

build-time$\to$run-time 借助于工具，将软件构造各阶段的活动“自动化” (编译、打包、静态分析、测试、生成文档、部署、…) 尽可能脱离“手工作业”，提高构造效率