一、软件构造基础
1.1 软件构造的多维度视图
按阶段划分:构造时/运行时视图
按动态性划分:时刻/阶段视图
按构造对象划分:代码/构件视图
构造阶段 Build-Time View
Code:代码的逻辑组织
functions
classes
methods
interfaces
Component:代码的物理组织
files
directories
packages
libraries
buildtime+moment+code level
源代码、函数、类、方法、接口
三个层面
词汇:使用的语句、字符串、变量、注释(半结构化)
语法:语法树AST、流程图(彻底结构化)
语义:源代码实现的目标 & 组成部分联系情况
buildtime+period+code level
Code Churn:add、modified、delete
buildtime+moment+component level
source code change to files
文件被压缩为package、library
与库文件链接——静态链接:库拷贝进入代码形成整体,执行的时候无需提供库文件
Static Linking——happens in build time, hard to update.
bulidtime+period+component level
different version!
Software Configuration Item(SCI)配置项
运行阶段 Run-Time View
程序被载入目标机器
Code:逻辑实体在内存中呈现?
Components:物理实体在物理硬件环境中呈现?
Moment:特定时刻形态?
Period:随时间变化?
we focus on:
Executable programs, Libraries, Configuration and data files, Distributed Programs.
Dynamic Linking——happens in runtime, easy to update and sharing.
动态链接:库文件不会在build阶段加入可执行文件,仅做出标记。程序运行时根据标记装载库到呢内存。发布软件时,需要将所依赖的所有动态库copy给client。
Runtime+moment+code level
Snapshot diagram & memory dump
Runtime+period+code level
UML图
执行跟踪tracing
用日志记录程序执行的调用次序
Runtime+moment+code level
UML!
Runtime+moment+component level
Event logging——system level
1.2 软件构造的阶段划分、各阶段的构造活动
∅=>code
programming(ADT/OOP)
static analysis
code=>component
ADT/OOP, Reusability, Maintainability
Compile, static link, package, install
buildtime=>runtime
install/deploy
debug, robustness, correctness
moment=>period
version control
dynamic link, loading, execution
1.3 内部/外部的质量指标
外部质量因素——用户感受得到、影响使用,外部影响因素大于内部。
正确性 Correctness(Rep)
i. 遵守规格说明书
ii. 分层:从底层到顶层,都要正确,每一层默认基础都是正确的
iii. 设法测试
健壮性 Robustness 包含Rep
健壮性:对异常情况做出适当反映
异常取决于规格说明,是其没有涉及的部分
易扩展性 Extendibility
易于调整、适应变化(软件是易变的)
改变的多少(与规模密切相关、越大越难以扩展)
Decentralization 离散化:模块自治性越强,变化时对其余模块影响越小
复用性 Reusability
利用已有的、复用性好的程序,开发成本少
相似的模式、利用共性
模块化
兼容性 Compatibility
尽可能地标准化
效率 Efficiency
对硬件资源尽可能少的需求
与其他性质存在矛盾,不能一味追求效率
可移植性 Portability
便于将软件产品移植到各种环境
易用性 Ease of use
用户:轻松掌握使用、包括安装、运行、GUI等
功能性
(冲突)过多新功能 --> 损失一致性(兼容性)、影响易用性
先实现主要功能、提高质量,再丰富功能
时效性 Timeliness
Others
a. 可验证性
b. 完整性 Integrity
i. 保护组件(程序和数据)在未经授权时不会被修改
c. 可修复性
d. 经济
i. 与时效性相关
ii. 系统能够按照等于或低于预算完成的能力
内部质量因素——影响使用代码的相关人员、软件本身和开发者
内部质量因素通常用作外部质量因素的部分度量
LOC——lines of code
Cyclomatic Complexity 圈复杂度
衡量一个模块判定结构的复杂程度
Architecture-related factors
Coupling 耦合度 --> 低
Cohesion 内聚度 --> 高
可读性
易理解性
清晰 Clearness
复杂度
大小 Size
权衡 Tradeoff
因素之间相互影响、矛盾、相关
经济性 与 功能性/可复用性 矛盾
有效性/可复用性 与 轻便性 矛盾
更高效、对硬件和软件有高要求
时效性 与 可扩展性 矛盾
完整性 与 易用性
首要:正确性!
五大质量要求:健壮,可扩展,可复用,可理解,效率。
二、软件构造过程
2.1 传统软件开发过程模型
两种基本类型:线性过程、迭代过程
现有模型:(前四个不涉及迭代)
瀑布过程:线性整体推进,无迭代好管理,但无法适应需求变化
增量过程:多个瀑布穿行,适应需求增加
V字模型:
它是瀑布模型的一个扩展,不同于瀑布模型的线性向下,其过程图呈V字,水平轴和垂直轴分别表示时间或项目完整性(从左到右)和抽象级别(最上层的粗粒度抽象)
原型过程:
在原型上持续不断的迭代(开发出来之后由用户试用/评审,发现问题反馈给开发者,开发者修改原有的实现,继续交给用户评审)发现用户变化的需求。循环往复这个过程,直到用户满意为止。时间代价高,但开发质量也高
螺旋模型:
这是一个很复杂的过程,多轮迭代基本遵循瀑布模式,每轮迭代有明确的目 标,遵循原型过程,进行严格的风险分析,方可进入下一 轮迭代
选择依据:
用户参与度(适应变化的能力)
开发效率/管理复杂度
开发软件的质量
2.2 软件配置管理SCM与版本控制系统VCS
SCM ≥ VCS
软件配置管理SCM
追踪和控制软件的变化
软件配置项SCI:软件中发生变化的基本单元(文件:Component-Level)
版本控制系统VCS
本地版本控制系统:仓库存储于开发者本地机器,无法共享和合作
集中式版本控制系统:仓库存储于独立的服务器,支持多开发者之间的协作
分布式版本控制系统:仓库存储于:独立的服务器 + 每个开发者的本地机器
2.3 Git
基本指令
添加文件:git add xxx.xxx
提交文件:git commit -m "message"
push到远程仓库:git push origin master
从远程仓库pull:git pull origin master
管理变化
Branch&Merge
新建分支:git checkout -b branch_name
切换分支:git checkout branch_name or git checkout master
选择一个分支与当前分支合并:git merge branch_name2(之前已有指令git checkout branch_name1)
工作原理和结构
Object Graph
版本之间的演化关系图
一条边A->B表征了“在版本B的基础上作出变化,形成了版本A”
Commit
每个commit指向一个父亲
分支:多个commit指向一个父亲
合并:一个commit指向两个父亲
管理变化:
Git存储发生变化的文件(而非代码行),不变化的文件不重复存储
2.4 GitHub
基于网络的Git服务器并提供互联网托管服务