题型
- 填空:4个,8分
- 简答、写代码、改代码:9个,合计56分
- 设计题:3个,合计36分
简答与设计题: – 给出需求描述、ADT的基本代码 – 开展设计和代码:绘图/建模、设计、修改代码、写新 代码、写注释(AF/RI/Spec/Safety from Rep Exposure/Testing Strategy/Thread Safety Argument)、设计测试 用例、改进/优化各项质量指标等
一、二章考纲
- 软件构造的多维度视图
- 软件构造的阶段划分、各阶段的构造活动
- 内部/外部的质量指标
- 软件配置管理SCM与版本控制系统VCS
- Git的结构、工作原理、基本指令
- GitHub
本章核心在此图,红框内一定要记住
软件构造的多维度视图
- By phases: build- and run-time views
按阶段划分:构造时/运行时视图 - By dynamics: moment and period views
按动态性划分:时刻/阶段视图 - By levels: code and component views
按构造对象的层次划分:代码/构件视图
软件构造过程其实就是不同视图之间的转换:三维度、八视图
本章最核心内容便是上图,下面分别介绍
Build Time View
含义:idea => requirement => design => code =>installable / executable package
- Code-level view:代码的逻辑组织
functions, classes, methods, interfaces,
- Component-level view:代码的物理组织
files, directories, packages, libraries,
- Moment view:特定时刻的软件形态
- Period view: 软件形态随时间的变化
(1)Build-time, moment, and code-level view
- 词汇
基于词汇的半结构化源代码(Lexical-based semi-structured source code) - 语法:
面向语法的程序结构(Syntax-oriented program structure)
例如AST,已经彻底结构化,java中存在专门的AST class将源代码变为一棵树,对树做各种操作==对源代码做修改。 - 语义
面向语义的程序结构(Semantics-oriented program structure),通常是图形化或形式化的,用于表达“需求”和“设计”思想,再转化成code
例如:UML类图
(2)Build-time, period, and code-level view
Code churn 代码变化: Lines added, modified or deleted to a file
from one version to another.
(3)Build-time, moment, and component-level view
- Source code 》files 》directories
- file被封装到包内
- 复用模块以libraries形式存在
可利用Maven来管理配置文件,进而便捷地导入不同的库
- 将库集成到可执行程序中
1.静态链接
发生在Build Time,库被拷贝进入代码形成整体,执行的时候无需提供库文件
不依赖
缺点:难以升级
2.动态链接
库不会加入可执行文件,只做标记
运行时根据标记装载库至内存
发布软件时,记得将程序所有依赖的动态库都复制给用户
优点:易于升级
(4)Build-time, period, and component-level view
各项软件实体随时间会如何变化、SCI(配置项)、Version Control System (VCS)、Evolution Graph
Run Time View
- Code Level:逻辑实体在内存中如何呈现?
- Component Level:物理实体在物理硬件环境中如何呈现?
- Moment view:逻辑/物理实体在内存/硬件环境中特定时刻的形态如何?
- Period view:逻辑/物理实体在内存/硬件环境中的形态随时间如何变化?
(5) Run-time, moment, and code-level view
关注程序在运行时各个时刻的代码层面状态(内存等信息)
- 代码快照图:描述程序运行时内存里变量层面的状态
- Memory dump:当进程执行的过程中通过工具产生一个文件用来分析程序运行时的各个状态信息(eg:任务管理器)
(6)Run-time, period and code-level view
- UML中的时序图(不是类图)
- Execution tracing 执行跟踪(堆栈执行跟踪)
(7)Run-time, moment, and component-level view
- UML中的部署图
(8) Run-time, period, and component-level view
- 事件日志:系统层面(前面的一个是code层面)
软件构造的阶段划分、各阶段的构造活动
直接上图:
内部/外部的质量指标
外部质量取决于内部质量,前者影响用户,后者影响开发者
-
外部质量目标
正确性、健壮性、可扩展性、复用性、兼容性(不同的软件系统之间相互可容易的集成)、性能(过早优化是万恶之源)、可移植性( 软件可方便的在不同的技术环境之间移植)、易用性、功能性、及时性等 -
内部质量目标
- 源代码相关因素(Source code related factors),如代码行数(LOC),循环复杂度等
- 架构相关因素(Architecture-related factors),如耦合度聚合度等。
- 可读性
- 易理解性
- 清晰度
- 规模
-
折中
最重要的有4个:正确性(最重要)、健壮性、可拓展性、可复用性
软件配置管理SCM与版本控制系统VCS
-
SCM:软件配置管理,用来追踪和控制软件的变化的任务。
-
SCI:软件配置项,软件中发生变化的基本单元(例如:文件)
-
SCM ≥ VCS
Git的结构、工作原理、基本指令
结构
- .git directory :本地CMDB(配置管理数据库)。
- working directory(工作目录):本地文件系统。
- Staging area(暂存区): 隔离工作目录和Git仓库。
原理
在.git目录中存放着下图(样子会不太一样,但内容一致)
Object Graph:版本之间的演化关系图,一条边A->B表征了“在版本B的基础上作出变化,形成了版本A”,图中给个节点就是一次Commit
Git object graph stores each version of an individual file once, and
allows multiple commits to share that one copy.
与传统VCS区别如上图
基本指令
添加文件:git add readme.txt
提交文件:git commit -m “message”
push到远程仓库:git push origin master
从远程仓库pull:git pull origin master(取回远程主机某个分支的更新,再与本地的指定分支合并,git pull = git fetch + git merge)
- Git fetch:Git fetch会将数据拉取到本地仓库 - 它并不会自动合并或修改当前的工作。
- git pull:git pull是从远程获取最新版本并merge到本地,会自动合并或修改当前的工作。
GitHub
省略