2-1 软件生命周期与配置管理
主要内容:
软件开发的 基本过程
传统的软件开发过程模型
敏捷开发
软件配置管理
Git作为配置管理工具
软件生命周期(Software Development Lifecycle(SDLC))
交流
汇集需求
可行性研究
系统分析
软件设计
编写代码
测试
一体化
执行
维护
用户倾向
传统软件开发过程模型
两个基本过程:
线性过程
迭代过程
模型:
瀑布模型(Waterfall)
增量过程(Incremental )
V字模型(V-Model)
原型过程(Prototyping)
螺旋模型(Spiral)
选择合适的过程模型的依据:
用户参与程度有多大?--适应变化的能力
开发效率/管理复杂度
开发出的软件的质量
瀑布模型
需求->设计->实现->验证->维护
优点:
线性推进
阶段划分清楚
整体推进
无迭代
管理简单
缺点:
无法适应需求增加/变化
增量过程
每段内:交流->计划->建模(分析,设计)->构造(代码,测试)->部署
多段渐进进行,需求增加就可以开始进行下一段
优点:
线性推进
增量式(多个瀑布的串行)
无迭代
比较容易适应需求的增加
V字模型(瀑布模型的扩展 )
在瀑布模型的基础上增加了部署后验证的过程
原型过程
在原型上持续不断的迭代 发现用户变化的需求
迭代:开发出来之后由用户试用/评审,发现问题反馈给 开发者,开发者修改原有的实现,继续交给用户评审。
循环往复这个过程,直到用户满意为止。 时间代价高,但开发质量也高。
螺旋模型
非常复杂的过程:
多轮迭代基本遵循瀑布模式
每轮迭代有明确的目标,遵循“原型”过程,进行严格的风险分析,方可进入下一 轮迭代
敏捷开发(Agile Development)
通过快速迭代和小规模的持续改进,以快速适应变化。
敏捷 = 增量 + 迭代
每次迭代处理一个小规模增量
特点:
极限的用户参与
极限的小步骤迭代
极限的确认/验证
结对编程:两人一组,一人编程另一人全程在旁边观察指出错误
极限编程 (eXtreme Programming (XP)):
Scrum:
软件配置管理 Software Configuration Management (SCM) 和版本控制系统 Version Control System (VCS)
软件配置管理:追踪和控制软件的变化
核心:版本控制和基线的确立
软件配置项Software Configuration Item (SCI):软件中发生变化的基本单元(例如:文件)
基线( baseline):软件持续变化过程中的“稳定时刻”(例如:对外发布的版本)
配置管理数据库(CMDB):存储软件的各配置项随时间发生变化的信息 +基线
版本:为软件的任一特定时刻(Moment)的形态指 派一个唯一的编号,作为“身份标识”
版本控制系统的功能和优点
回滚到上一个版本
比较两个版本的差异
备份软件版本历史
获取备份
合并两个版本
在多个开发者之间共享和协作
记录每个开发者的动作,便于“审计”
Git
Git仓库
组成:
本地的CMDB:存储所有版本控制数据的存储库
工作目录:本地文件系统
暂存区:隔离工作目录和Git仓库
Git中的对象图
Git的所有操作都是在一个图数据 结构(对象图)上进行
从另一台机器/服务器复制git项目意味着复制 整个对象图
ObjectGraph:版本之间的演化关系图,一条边 A->B表征了“在版本B的基础上作出变化,形成 了版本A”
Commit
每个commit指向一个父亲
多个 commit指向同一个父亲:分支
一个commit 指向两个父亲:合并
Head指向了当前分支的当前commit
Git将所有commit表示为一个树。
若文件未发生变化,则后 续多个版本始终指向同 一个文件
若文件发生变化了,存储 两份不同的文件,两个 版本指向不同的文件
Git操作
下载并在本机安装设置Git环境
在工作目录中初始化新仓库 git init
git add 添加文件
git commit 提交
从现有仓库下载文件到本地:克隆 git clone [url]
要确定哪些文件当前处于什么状态,用git status命令
如果要查看具体修改了什么地方,可以用git diff命令,使用文件补丁 的格式显示具体添加和删除的行。
Git提供了一个跳过使用暂存区域的方式,只要在提交的时候,给 git commit 加上-a 选项,Git 就会自动把所有已经跟踪过的文件暂存起来 一并提交,从而跳过git add步骤;
使用git rm命令从Git中移除某个文件,把它从已跟踪文件清单(暂存 区域)中移除,并连带从工作目录中删除指定的文件。
分支是在版本控制下对对象的复制,以便可 以沿两个分支平行进行修改。
分支即同时存在的多个不同软件版本。
2-2软件构造的过程、系统和工具
主要内容:
广义的软件构造过程
Eclipse作为Java构造环境和工具
软件构造各阶段的常见工具
狭义的软件构造:build
常见的build工具
广义的软件构造过程
Build 构建
Programming (coding) 编码
Refactoring 重构
Debugging 调试
Testing 测试
Dynamic code analysis /profiling 性能分析
Code review Static code analysis 代码评审
Programming
从用途上划分:
编程语言 (e.g., C, C++, Java, Python)
建模语言 (e.g., UML)
配置语言 (e.g., XML)
构建语言 (e.g., XML, YAML, JSON)
从形态上划分:
基于语言学的构造语言
基于数学的形式化构造语言
基于图形的可视化构造语言
建模语言
建模语言是一种人工语言,用于表达信息、知识或系统,以一套一致的规则定义来可视化、推理、验证和交流系统的设计。
代码评审
类型:
结对编程
走查
正式评审会议
自动化评审
利用工具静态分析代码
动态性能分析
动态分析:要执行程序并观察现象、收集数据、分析不足
程序需要经过充分的测试
利用测试度量技术(如覆盖率)确保 代码的可能功能均被充分测试到
用来测量 程序的时空复杂度,特定指令或函数的调用频率或持续时间,发现代 码中潜在问题
调试和测试
测试:发现程序是否有错误
调试:定位错误、发现错误根源
测试和调试不会提升软 件质量,而是发现和解决缺陷的主要手段
软件质量应通过认真的分析需求、良好 的设计、高质量的编码来实现。
调试是最后的手段
重构
重构:在不改变功能的前提下优化代码
调整代码结构,调用关系,来优化代码。
IDE中有自动化优化工具,也有辅助优化工具。
构建
粗略理解build:build-time → run-time
借助于工具,将软件构造各阶段的活动“自动化” (编译、打包、静态分析、测试、生成文档、部署、…)
尽可能脱离“手工作业”,提高构造效率。
使用build的典型场景:
c,c#,java的汇编。
python中的包和测试
网页应用的编译和打包
Junit单元测试
代码静态分析
Java的文档导出
编译型语言:
编译后得到目标文件, 后续被链接入类库或者可执行程序中
最终得到可部署到目标机器的发布包
解释型语言:
解释后的源代码不会编译成目标代码,源文件本身储存在一个发布包中
编译工具的重点是转换源文件并将其存储在发布包中。
构建系统的组成
版本控制工具
源码树
对象树
编译工具(编译器,链接器,基于UML的代码生成器,文档生成器)
构建工具(编排构建过程,调用编译工具)
构建机器(构建工具执行的所在机器)
原生编译:目标机器与构建 机器同类
跨平台编译:软 件的构造和运行,分别在不同操作系统或不同CPU的两类计算机上进行
如何使用构建系统
开发人员(或私有)构建:开发人员从VCS获得源代码,并在私有工作区中构建软件。
发布版本:为测试组提供一个完整的软件包以进行验证。当测试人员确信软件具有足够高的质量时,就可以提供同样的软件包给客户。
健全性构建:构建过程确定当前源代码是否没有错误并通过一组基本的健全性测试。这种类型的构建每天可以发生很多次,并且趋向于完全自动化。
构建工具(JAVA)
Make
Ant
Maven
Gradle
Eclipse IDE