软件工程（双语）

教材《软件工程 实践者的研究方法》 双语教学

”过程决定质量，复用决定效率”

介绍

软工的本质

程序=数据结构+算法
软件=程序+文档（需求、模型、说明书）

软件应用有：

• 系统软件
• 应用
• 工程/科学软件
• 嵌入式
• 产品线软件
• 移动应用
• AI软件
• ……

随着硬件的飞速发展，软件也必须更新

• web apps
• mobile apps
• 云计算（IAAS,PAAS,SAAS)：公有云、私有云

软件产品线：可复用

软件工程

人犯错，得到error，导致fault，在系统里导致failure
在开发以前，团队要保持互相目标的一致性，设计是其中重要的活动，软件应该高质量，可持续。

定义：软件工程是对稳定健康的工程学原则的使用和建立，是为了得到经济的、可信赖的、高效率的在真实机器上运行的软件。
定义2：软件工程是对系统的、规范的、可度量的应用，发展、操作、保持软件，即工程学在软件上的应用。

软工和计科的关系：
cs：硬件、编译器、操作系统、编程语言，关注理论和基础
se：工程向，解决实际问题，注重实践

分层技术：
工具
方法
过程模型
质量焦点

Activities活动 大
Actions 动作 中
Tasks 任务 小

过程框架：

• 框架活动 framework activities
  • 沟通 communication
  • 计划 planning
  • 建模（原型）modeling：分析需求analysis of requirements->设计design
  • 构建construction：生成代码code generation->测试 testing
  • 部署 deployment
• 普适性活动 umbrella activities
  • 追踪控制 tracking and control
  • 风险管理 risk management
  • 质量保证 quality assurance
  • 技术审查 technical review （自动化、人工）（结对编程pair programming）
  • 度量measurement
  • 配置管理cofiguration management
  • 可复用性 reusability management
  • 准备和发布 work product preparation and production

调整流程模型adapting a process model：

• 活动、动作和任务流以及他们之间的相关性
• 在每个框架活动中定义动作、任务的程度（？
• 工作产品被定义和需要的程度
• 质量保障活动被应用的方式
• 项目追踪和控制活动被应用的方式
• 细节和过程被描述的严密的总程度
• 顾客和利益相关者参与项目的程度
• 软件工程团队的自主性等级
• 团队组织和角色被规定的程度

实践的本质

• 理解问题（沟通和需求分析）
  • 谁是利益相关者？
  • 需要什么数据、函数、特性？
  • 是否可以划分问题？
  • 分析模型是否可以图形化？
• 计划解决方案（建模和软件设计）
  • 是否之前做过类似的？
  • 是否可重用？
  • 子问题可以被定义吗？
  • 设计模型可以被创造吗？
• 实施方案（写代码）
  • 解决和计划一致吗？源代码可追溯到设计模型吗？
  • 有检查过代码吗？算法有正确性证明吗？能改进吗？
• 检查结果（测试和质量检验）
  • 有合乎情理的检测策略吗？
  • 结果和数据一致吗？经过利益相关者的验证吗？

普遍原则：

• 这一切存在的原因 the reason it all exists
• KIS原则 KEEP IT SIMPLE,STUPID
• 保持愿景 maintain the vision
• 你生产的就是别人消费的 what you produce,others wll consume
• 开放 be open to the future
• 对复用要高瞻远瞩 plan ahead for reuse
• 思考 think!

软件的奥秘：

• 影响管理者、顾客（以及其他非技术的利益相关者）、从业人员
• 坚持现实

它是如何开始的：

• 安全屋（？）safehome
  • 所有的软件项目都沉淀于商业的需求
    • 需要修正现有应用的缺陷
    • 将运行的系统升级为符合新商业环境的需求
    • 增加功能、特性的需求
    • 建立新产品、新服务、新系统的需求

软件过程 software process

在我如今看来，语言其实是开发的细枝末节。而在大学时代、在课桌上令人昏昏欲睡的《软件工程》才是软件开发中的髓质与灵魂。——周爱民《大道至简》

软件过程结构

• 将通信记录为正式文档
• 规划模块接口设计
• 在集成测试之前应该自行测试本人模块
• 代码审查（少用全局变量）
• 成立代码质量团队
• 集成测试，隔离不同模块的错误
• 软件架构师
• 规范更改会议

软件过程

通用过程模型


定义框架活动
通信：电话、会议纪要、邮件、签字
明确任务集：工作任务、相关工作产品、质量保证点、项目里程碑

过程模式process patterns

描述了工作中遇到的与过程相关的问题
明确遇到问题的环境以及给出一种或多种经过验证的解决方案
过程模式提供了一种在软件过程背景下通用解决问题的方案

• 步骤模式
• 任务模式
• 阶段模式

例子：

例2：软工第一次作业 第2题

过程模型 process models

包括：

• 瀑布模型 the waterfall model
  • 线性
  • the v-model
• 增量过程模型 incremental process model
• 演化过程模型 evolutionary process model
  • prototyping 原型模型
  • spiral 螺旋模型
• 协同模型 concurrent model
• 其他过程模型
  • 基于构件的开发 component based development
  • 形式化方法 formal methods
  • 面向方面的开发 AOSD
  • 统一过程 unified process

瀑布模型

适用：线性的，适合小型、需求固定项目。真实项目很少使用这一模型
优点：结构简单，软件开发管理严格，文档齐全，容易理解和实施，推迟实现
缺点：在后期才能有可工作的版本；不适应需求的变化；需要客户需求非常明确；早期无法发现缺陷

改进：v-model
在线性基础上增加迭代

结构简单,强调软件开发过程的阶段性和顺序性，对软件开发管理严格,文档齐全，但早期无法发现缺陷，不适应需求经常发生变更的环境，要等很长时间才能得到最终产品。

增量过程模型 Incremental Process Model

优点：用户可以不断看到软件的可运行版本；有助于明确后期增量的需求；降低开发风险；重要功能首先被交付，得到最多的测试
缺点：需要软件具备开放式的体系结构；需求难以详细定义；容易失去控制，变得边做边改

演化过程模型 Evolutionary Models

Prototyping 原型模型
原型开发如果很粗糙，则必须扔掉
优点：逐步开发出完整的软件；适合用户对细节一无所知的情况
缺点：为了快速开发上线，写出来一堆屎山代码，最后变成了系统的组成部分

软件原型工具：axure rp
例：软工第一次作业 第3题

The Spiral 螺旋模型
优点：甲方持续参与；开发风险被控制；对大型复杂软件适用；可扩展
缺点：风险分析的失败；难以控制；需要专业的开发团队

例：软工第一次作业 第4题

协同（并发）模型concurrent models

其他过程模型

• 基于构件的开发 component based development 重用
• 形式化方法 formal methods 强调数学
• 面向方面的开发 AOSD
• 统一过程 unified process 与UML紧密结合；用例驱动，以架构为中心，迭代和增量
  优点：质量文件很重要；甲方持续参与；允许需求更改；对于维护工作得很好
  缺点：用例并不总是精确；棘手的软件增量集成；阶段重叠会导致问题；需要专业技术团队
  

UML unified modeling language
用例图示例

UML用例描述
UP Phases

敏捷开发 agile development

什么是敏捷？

• 对变化的快速响应
• 所有利益相关者之间的有效沟通
• 吸引客户加入团队
• 组织一个团队，掌控所完成的工作
• 快速渐进地交付软件
• 12条敏捷开发原则：
  详见：软工第一次作业 第5题

敏捷和花费的关系，实线是传统开发过程，灰线是敏捷开发过程，虚线是理想花费。可见敏捷开发可以降低成本。

计划是短暂的，让顾客描述需求，迭代地开发软件，提供多个软件增量。

橄榄球争球框架：scrum framework

• 从挤压的任务中分配优先级，每日开会15分钟
• 随着产品的构建，测试和文档记录也在进行中
• 工作发生在冲刺（sprint）中，由现有需求的待定项(backlog)衍生而来。

优点pros：

• 甲方有优先权
• 团队可以做决定
• 轻量级文档
• 支持频繁更新

缺点cons：

• 成本难以控制
• 不适用大型、安全性要求高的软件
• 需要专业团队

极限编程 extreme programming(xp)

最广泛使用的敏捷过程

设计：

• Follows the KIS (keep it simple) principle遵循保持简洁的原则
• Encourage the use of CRC cards (see Chapter 9)鼓励使用CRC卡片
• For difficult design problems,suggests the creation of “spike solutions”—a design prototype对于复杂的设计问题，建议创建spike解决方案-一种设计原型
• Encourages “refactoring”（重构）—an iterative refinement of the internal program design鼓励重构-一种迭代求精的内部程序设计

编程：

• 单元测试
• 结对编程

测试

• 每天执行所有模块测试
• 用户定义验收测试

看板框架 kanban framework

开发运维 Development Operatios (DevOps)

需求 requirement

属于建模中的需求分析和设计阶段

理解需求

任务：

• inception 起始 提出一系列问题（确定利益相关者）
• elicitation 获取 导出利益相关者的要求（协作需求收集，会议，用户场景，获取工作产品，开发用例）
• elaboration 细化，创建一个分析模型，用以说明软件的数据，功能和行为要求（基于场景的元素、基于类的元素、行为元素）
• negotiation 协商 就可交付系统达成一致，这对于开发人员和客户来说是切合实际的（确定关键利益相关者）
• 规格说明 specification （书面文件、一套模型、一个形式化的数学模型、一组用户使用场景（用例）、原型）
• 确认 validation 审查机制
• 需求管理—帮助项目组在项目进展中标识、控制和跟踪需求以及需求变更的一组活动

例子，安全屋：

需求建模

基于场景的方法 Scenario-Based Methods

面向对象建模 UML（ Unified Modeling Language ）
基于场景的建模

1. Creating a preliminary use case
   创建初始用例
   
   

2. Refining a preliminary use case
   细化初始用例

3. Writing a formal use case
   编写正规的用例 UML：用例图、活动图、泳道图等。
   
   
   
   

基于类的方法 Class-Based Methods

基于类的分析模型元素包括类和对象、属性、操作、CRC模型、协作图和包

1. 带有下划线的名词或名词词组可以确定为类,并将其输入一个简单的表。
2. 标出同义词。
3. 如果需要某个类（名词）实现一个解决方案，那么它就是解决方案空间的一部分；否则，如果只要求某个类来描述一个解决方案，那么它就是问题空间的一部分。

属性描述了已经选择要包含在分析模型中的类

定义操作 对正在处理的叙述进行语法分析并查看动词

CRC Modeling 类-职责-协作者建模

关联和依赖

类和接口：
分析类名称前面的加号表示类具有公共可见性，因此可以从其他包访问。减号表示元素对所有其他包都是隐藏的。#符号表示一个元素只能被包含在给定包中的类访问。

1. 依赖关系：是一种使用关系，它是对象之间耦合度最弱的一种关联方式，是临时性的关联。在代码中，某个类的方法通过局部变量、方法的参数或者对静态方法的调用来访问另一个类（被依赖类）中的某些方法来完成一些职责。（虚线+箭头）
   

2. 关联关系：是对象之间的一种引用关系，用于表示一类对象与另一类对象之间的联系，关联关系是类与类之间最常用的一种关系，分为一般关联关系、聚合关系和组合关系。在代码中通常将一个类的对象作为另一个类的成员变量来实现关联关系（实线+上面的箭头）
   

3. 聚合关系：是关联关系的一种，是强关联关系，是整体和部分之间的关系，是 has-a 的关系。聚合关系也是通过成员对象来实现的，其中成员对象是整体对象的一部分，但是成员对象可以脱离整体对象而独立存在。（实现+空心菱形）
   

4. 组合关系：是关联关系的一种，也表示类之间的整体与部分的关系，但它是一种更强烈的聚合关系，是 cxmtains-a 关系。在组合关系中，整体对象可以控制部分对象的生命周期，一旦整体对象不存在，部分对象也将不存在，部分对象不能脱离整体对象而存在（实线+实心菱形）
   

5. 泛化关系：是对象之间耦合度最大的一种关系，表示一般与特殊的关系，是父类与子类之间的关系，是一种继承关系，是 is-a 的关系。在代码实现时，使用面向对象的继承机制来实现。（实线+空心箭头）
   

6. 实现关系：接口与实现类之间的关系。在这种关系中，类实现了接口，类中的操作实现了接口中所声明的所有的抽象操作。（虚线+空心箭头）
   
   例子：
   
   
   分析模型的各种元素（例如用例、分析类）以将它们打包为一个分组的方式进行分类。
   

流程、行为、模式 Flow, Behavior, Patterns

行为模型表明软件将如何响应外部事件或激励。
状态转换图：
初态●
终态●外面一个空圈
中间状态（状态名|状态变量|活动表）
时间表达：箭头

设计 design

概念

耦合

• 内容耦合
• 公共耦合
• 控制耦合
• 数据耦合

内聚

内聚表示模块的相对功能强度。 模块内聚程度越高越好。
 Coincidental cohesion(偶然内聚): Unrelated functions, processes,or data are found in the same module(for convenience).
 Logical cohesion(逻辑内聚): Logically related functions or data are placed in the same module.
 Temporal cohesion(时间内聚): The functions are related only by the timing involved.
 Procedural cohesion(过程内聚): Functions are grouped together in a module to ensure a certain order of performance
 Communicational cohesion(通信内聚): All the functions in a module operate on or produce the same data set
 Fuctional cohesion(功能内聚): Every processing elements is essential to the performance of a single function.

体系结构设计

体系结构：软件的整体结构以及该结构为系统提供概念完整性的方式。
结构特性：定义系统的构件（例如，模块，对象，过滤器）、构件封装方式和构件交互作用的方式。
外部功能特性：如何满足需求，包括性能、能力、可靠性、安全性、可适应性和其他系统特征需求。
相关系统族：体系结构设计应该抽取在一类相似系统开发中经常用到的重复性模式。在本质上，设计应该可以重用体系结构构件。

• 以数据为中心的体系结构
• 数据流体系结构
• 调用和返回体系结构
• 层次体系结构

构件级设计

OMG统一建模语言规范将组件定义为：系统中模块化，可部署和可替换的部件，它封装了实现并公开了一组接口。
构件包含一组协作类
构件包含处理逻辑，实现处理逻辑所需的内部数据结构，以及能够保证构件被调用和实现数据传递的接口。


原则：

• 开闭原则。模块对于扩展具有开放性，对于修改具有封闭性
• 利斯科夫替换原则。子类可以替换它的基类。
  
• 依赖倒置原则。依赖于抽象，而非具体实现。
  
• 接口分离。多个客户专用接口比一个通用接口好

步骤：

UI设计

User Interface Design
黄金准则：

• Place the user in control
• Reduce the user’s memory load
• Make the interface consistent

软件质量

MTBF（mean-time-between-failure） = MTTF（mean-time-to-failure） + MTTR（mean-time-to-repair）
Availability = [MTTF/(MTTF + MTTR)] x 100%

测试

单元测试

集成测试

自上而下/自底向上

高阶测试

Performance Testing
定义：通过自动化测试工具段模拟正常、峰值以及异常负载条件，对软件的各项性能指标进行的一种测试。
软件性能指标：1、响应时间 2、并发用户数 3、吞吐量 4、资源利用率

回归测试

考题

基本路径测试：覆盖所有的可能情况最少使用的测试用例个数
圈复杂度=边数-点数+2/判断+1/被封闭的区域的个数+1
圈复杂度详解

画程序流程图和控制流图（CFG)

黑盒测试/白盒测试

软件配置管理 SCM

组织团队结构

度量、进度安排