哈工大软件过程与工具

12.23 快考试了，要开始复习了。这学期学分绩还是比较重要的。加油，奥力给 一给洛！！

大纲：

---

1. 软件过程核心思想

• 软件工程的两个映射

1. 概念映射：问题空间的概念和解空间的模型化概念之间的映射
2. 业务逻辑映射：问题空间的处理逻辑与解空间处理逻辑之间的映射

• 软件工程所关注的对象

1. 产品
2. 过程

• 软件工程所关注的目标
  
  

• 软件工程的核心思想：
  分治，复用，折中，演化

---

软件过程模型

1. 瀑布模型

2. 增量模型




3.演化模型


快速原型法：

包括抛弃式原型和演化式原型



螺旋式模型

---

敏捷方法

---

极限编程：一种应用最广泛的敏捷开发模型

---

---

敏捷模型与其它模型的分析

---

软件项目管理

软件开发团队的组织方式
一窝蜂模式：没有明确分工，存活的时间一般都不长
**主治医生模式：**一个人带着其它人干
明星模式：

社区模式：linux操作系统的社区
交响乐团模式：门类齐全，各司其职
爵士乐模式：：


功能团队模式：

官僚模式：

产品结构分解：
项目管理里通常使用产品结构分解作为产品分解的工具

产出物：项目结束时需要提交的最终产品，在项目之初就可以准确预计

项目关注的四方面：
范围，时间，成本，质量

项目管理的主要任务：
可行性分析，进度安排，分线管理，质量管理，项目跟踪与控制

可行性分析与估算：
在项目开始之前，至少i要预估：
需要多少工作量
需要多少时间
需要多少人员
从而得出该项目是否可行

确定范围：
要交付给最终用户的功能和特性，输入输出数据，用户界面，系统的性能，约束条件，接口和可靠性，期望的时间，目标成本。

可行性分析：
技术可行性，经济可行性，时间可行性，资源可行性

项目进度计划与监控：

---

软件演化与配置管理
软件演化的处理策略：
软件维护：为了修改软件缺陷或新增功能而对整个软件进行的变更
软件再工程：为了避免软件退化而对软件的一部分进行重新设计，编码和测试
前者的力度比后者更小

软件维护的类型：
纠错性维护
适应性维护
完善性维护
预防性维护

完善性维护的比重最大，大部分是加强软件，而不是纠错

软件维护的内容：
程序维护
数据维护
硬件维护

软件配置管理SCM：
软件配置项SCI：
计算机程序
描述计算机程序的文档
数据

基线：软件开发过程中的里程碑
配置管理数据库：用于保存软件相关的所有配置项的信息以及配置项之间关系的数据库

持续集成：
敏捷开发的一项重要实践，自动化地构建，不是等到最后再做集成测试，而是每天都做
减少重复过程：使用自动化来完成

git与GitHub：
本地版本控制系统：采用简单的数据库或文件系统来记录本地文件的历次更新差异

集中化的版本控制系统：
有一个单一的集中管理的服务器，保存所有文件的修订版本，而协同工作的开发者通过客户端连到这台服务器，取出最新的文件或者提交更新
缺陷：单点故障，可靠性问题

分布式版本控制系统：
客户端并不只提取最新版本的文件快照，而是把原始的代码仓库完整地镜像下来

每一次的提取操作，实际上都是一次对代码仓库的完整备份

git的基本思想：

git中文件的三种状态：已提交，已修改，已暂存

git中管理项目的三个工作区域：
仓库：git目录
工作目录：本地目录
暂存区域：本质上就是一个文件，保存了下次将要提交的文件列表信息

git基本工作流程：
1.在工作目录中修改某些文件
2.对修改后的文件进行快照，然后保存在暂存区域
3.提交更新，将保存在暂存区域的文件快照永久转储到git目录中

基本git指令：
git+
$add$：告诉git对这些文件进行跟踪，然后提交
$commit$
$merge$
$status$：文件状态
$diff$：修改了哪些地方
$rm$：删除某个文件
$reset$：回滚
$log$:git查询工具
$commit-amend$：撤销上一次修改，形成新的提交，本质上合并暂存区的修改和最近依次的修改
git供一个使用暂存区域的方式，只要在提交的时候，给git commit加上-a选项。git就会自动把所有已经跟踪过的文件暂存起来一并提交，从而跳过git add
git checkout head将最后一次提交的结果复制到工作目录和暂存区，丢弃本地修改

git远程仓库指令
git+
$clone$：克隆
$remote$：获取当前配置的所有远程仓库
$remote+rm+pb$：从本地移除远程仓库
$rename+pb+pb1$：将远程仓库重命名
$fetch$：将远程仓库同步到本地
$pull=fetch+merge$慎用
$push$：推送

git分支命令：


git -branch：列出当前所有分支
git branch(name)在当前commit对象上新建一个分支指针
git使用一个叫做head的指针来获知你当前在哪个分支上工作
要切换到其它分支，使用git checkout
git branch -b创建一个新的分支并立即切换过去
git branch -d：删除一个分支
git log -decorate：查看当前各个分支所指的commit对象
git merge (name)：将该分支合并到当前分支

合并分支的本质：

1. 如果被合并的分支是当前commit对象的祖父节点，那么合并命令什么也不做
2. 否则，默认把当前commit对象和被合并的分支，以及他们的共同祖父节点commit节点进行一次三方合并

分支的衍合/变基
git rebase
merge和rebase的区别：
merge把两个父分支合并进行一次提交，提交历史不是线性的
rebase在当前分支上重演另一个分支的历史，提交历史是线性的

利用分支进行开发的流程：
1.长期分支：

2.特性分支：
创建特性分支，在提交了若干更新之后，把他们合并到主干分支，然后删除，从而支持迅速且完全的进行语境切换

远程分支：
远程仓库中分支的索引
远程分支只能看，不能修改

本地分支<–>远程分支：
push：推送本地分支至远程
git push [remote] [branch]

fetch:将远程分支同步到本地
git fetch [remote] [branch]

跟踪远程分支：

删除远程分支：

---

UML及其建模工具

模型及其介绍：
模型就是现实的简单化

软件系统用对象（类）作为其构造单元

视图是表达系统某一方面特征的UML建模元素的子集，分为：
用例视图
逻辑视图
进程视图
实现视图
部署视图

UML中的模型图：
类图
对象图
用例图
时序图
协作图
状态图
活动图
组件图
部署图
包图

事物：
结构事物：类，接口，协作，用例，活动类，组件，节点
行为事物：
分组事物
注释事物

UML中的关系
关联
依赖
泛化
实现
聚合

用例图：

用例图主要包含下面六个元素：
参与者
用例
关联关系：
表示参与者与用例之间的关系

包含关系
一个用例可以简单的包含其它用例具有的行为
包含用例执行，则被包含用例必须执行
include的箭头是包含的指向被包含的

扩展关系
基础用例被这姓时，一般不会涉及到扩展用例，只有当特定的条件发生，扩展用例才可能执行
extend用例是扩展用例指向原用例

泛化关系
一般与特殊的关系

示例：

要根据不同的系统确定系统的边界：

用例的粒度：

活动图：

活动图元素：
动作状态：
动作状态是指原子的，不可中断的动作

活动状态：
用于表达状态机中的非原子 的运行
可以分解成其它子活动或者动作状态
内部状态可以用另一个活动图来表示

开始点：

结束点：
整个活动的结束

子流程的结束：

分支：

分叉：

泳道：

实例：
图书馆馆员活动图：

类图/对象图：

描述类。接口及他们之间关系的图

属性的可见性：
公有public：+
私有private：-
protected：#
package:~

类之间的关系：
依赖关系：表示两个或多个模型元素之间语义上的关系

泛化关系
存在于一般元素和特殊元素之间的分类关系

关联关系
指明事物的对象之间的联系

聚合关系：

组合关系：

实现关系

实例

pornhub

---

软件需求与需求获取

软件需求：
一种清晰简洁无二义性的方式，描述用户对目标软件需求的期望，是在开发过程中对系统的约束

需求的分类：
业务需求：
客户对于系统的高层次目标要求，定义了项目的远景和范畴

用户需求：
从用户角度描述系统的功能型需求和非功能性需求，只涉及系统的外部行为而不涉及内部特性

功能需求：
系统应该提供的功能或服务，通常涉及用户或外部系统与该系统之间的交互，不考虑系统内部的实现细节

非功能性需求：
从各个角度对系统的约束和限制，反应了对软件系统质量和性能的额外要求

约束条件：系统设计和实现时必须满足的限制条件：

业务规则：对某些功能的可执行性或内部执行逻辑的一些限定条件：

外部接口需求：

好的需求应具备的特征：
完整性：描述清楚
正确性
可行性
必要性
划分优先级
无二义性
可验证性

需求工程：应用技术确定客户需求，帮助分析人员理解问题定义目标

需求开发所包含的活动
1）需求获取
对用户进行分类
聆听用户需求
分析整理用户需求
形成文档化描述
签字确认

2）需求分析
定义边界
建立原型
分析可行性
确定优先级
建立模型
创建数据字典

3）需求规格说明
4）需求验证
5）需求管理

需求获取方法：
收集现有书面资料
面对面访谈
需求研讨会
现场观察/体验
头脑风暴：自由畅谈，禁止批评，追求数量，有一名主持人，2名记录员

会后：修建，分组，排序
适用场合：产品型系统，需要具有创新性特征，尚投放市场，无明确的用户

---

面向对象的分析

1. 业务领域分析
2. 发现和定义对象和类
3. 识别对象的外部联系
4. 建立系统的静态结构模型
5. 建立系统的动态行为模型

分析类的类型：
实体类：表示系统存储和管理的持久性信息
必须存储的信息及其相关行为

边界类：表示参与者与系统之间的交互
用户界面，系统接口，设备接口

控制类：表示系统在运行过程中的业务控制逻辑
调度其他类来完成具体的任务