SoftwareConstruction——Basic&Progress

一、软件构造基础


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服务器并提供互联网托管服务

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值