软件工程笔记

Software Engineering

The Nature of Software

Software

软件是：（1）指令的集合（计算机程序），通过执行这些指令可以满足预期的特性、功能和性能需求；（2）数据结构，使得程序可以合理利用信息；（3）软件描述信息，它以硬拷贝和虚拟形式存在，用来描述程序的操作和使用。

Softwatre Characteristics(The differences between software and hardware)

软件是被开发或设计的，而不是传统意义上的制造。

软件不会磨损（最根本的不同）

软件是定制的，而不是由组件构成

软件是退化的（不断的变更是软件退化的根本原因）

Software Engineering

Software process

软件过程是工作产品构建时所执行的一系列活动、动作和任务的集合。

Software engineering

软件工程是：（1）将系统化的、规范的、可量化的方法应用于软件的开发、运行和维护，即将工程化方法应用于软件；（2）对（1）中所述方法的研究。

Software Process Structure

Software Engineering Layers

工具、方法、过程、质量关注点

Generic Software Engineering Framwork Activities

沟通、策划、建模、构建、部署

Process Assessment and Improvement

用于过程改进的CMMI标准评估方法：启动、诊断、建立、执行、学习

用于组织内部过程改进的CMM评估

Process Flow

过程流描述了在执行顺序和执行时间上如何阻止框架中的活动、动作和任务。

线性过程流从沟通到部署顺序执行五个框架活动。

迭代过程流在执行下一个活动前重复执行之前的一个或多个活动。

演化过程流采用循环的方式执行各个活动，每次循环都能产生更为完善的软件版本。

并行过程流将一个或多个活动与其他活动并行执行。

Process Models

惯用过程模型：

瀑布模型（线性模型）

增量过程模型（核心产品、瀑布模型）

原型模型（演化过程模型、需求模糊、抛弃）：沟通、快速策划、建模快速设计、构建原型、部署交付及反馈

螺旋模型（演化过程模型、原型、瀑布）

并发开发模型

专用过程模型：

基于构建的开发模型

形式化方法模型

面向方面的软件开发模型

统一过程

起始、细化、构建、转换、生产

个人过程模型和团队过程模型

Agile Development

Agile

对软件生产率的高度重视，主要适用于需求模糊或快速变化下的、小型项目组的开发。在满足所需的软件质量要求的前提下，力求提高开发效率。

Agility

快速交付产品、对变更的有效响应、所有利益相关者之间有效沟通、灵活的项目计划、小而高度自主的团队

The Manifesto for Agile:

个人和他们之间交流胜过了开发过程和工具

可运行的软件胜过了宽泛的文档

客户合作胜过了合同谈判

对变更的良好响应胜过了按部就班地遵循计划

Extreme Programming(XP)

四个框架活动：策划、设计、编码、测试

关键点：用户故事、KIS、结对编程、重构、连续集成、增量交付

Other agile process

Scrum

动态系统开发方法（DSDM）

敏捷建模（AM）

敏捷统一过程（AUP）

Understanding Requirements

The definition of requirements engineering

需求工程是指致力于不断理解需求的大量任务和技术。

从软件过程的角度来看，需求工程是一个软件工程动作，开始于沟通活动并持续到建模活动。

需求工程在设计和构建之间建立起联系的桥梁。

Requirements Engineering Tasks

Inception（起始）、Elicitation（获取）、Elaboration（细化）、Negotiation（协商）、Specification（规格说明）、Validation（确认）、Requirements management（需求管理）

质量功能部署Quality Function Deployment(QFD)

常规Normal/期望Expected/兴奋Exciting

ERD

Use-case

场景通常称为用例，它描述了人们将如何使用某一系统。

Elicitation Work Products(Requirement Specification…)

（1）要求和可行性陈述；

（2）系统或产品范围的界限说明；

（3）参与需求获取的客户、用户和其他相关利益者的名单；

（4）系统技术环境的说明；

（5）需求列表以及每个需求适用的领域限制；

（6）一系列使用场景，有助于深入了解系统或产品在不同运行环境下的使用；

（7）任何能够更好地定义需求的原型。

Requirements Modeling：Scenario-Based Methods

Objectives of Requirements Model

需求模型必须实现三个主要目标：（1）描述客户需要什么；（2）为软件设计奠定基础；（3）定义在软件完成后可以被确认的一组需求。

Rules of Thumb（需求分析建模原则）

模型应关注在问题域或业务域内可见的需求，抽象的级别应该相对高一些。（不要陷入细节）

需求模型的每个元素都应能增加对软件需求的理解，并提供对信息域、功能和系统行为的深入理解。（增加对软件需求主体的理解）

关于基础结构和其他非功能的模型应推延到设计阶段再考虑。

最小化整个系统内的关联。（低耦合）

确认需求模型为所有利益相关者都带来价值。

尽可能保持模型简洁。

Elements of Requirements Analysis

UML

统一建模语言

Diagrams of UML for analysis modeling

Use-case diagram

Activity diagram

Class diagram

Collaboration diagram

State diagram

Sequence diagram

Deploment diagram

Requirements Modeling：Class-Based Methods

CRC

类-职责-协作者

类是系统操作的对象

职责是和类相关的属性和操作

协作者是提供完成某个职责所需要信息的类

Design Concepts

Design conceptions

关注点分离

模块化

信息隐蔽

重构

内聚

耦合

Object-oriented Design conceptions

类、属性、操作

多态Polymorphism

封装Encapsulation

继承Inheritance

Quality attributes-FURPS

功能性、易用性、可靠性、性能、可支持性

DFD

Four Design Models Elements

数据设计元素、体系结构设计元素、接口设计元素、构件级设计元素、部署级设计元素

Architectural Design

Software Architecture

程序或计算系统的软件体系结构是指系统的一个或者多个结构，它包括软件构件、构件的外部可见属性以及它们之间的相互关系。

Why is Architecture important?

软件体系结构提供了一种表示，有助于对计算机系统开发感兴趣的所有利益相关者开展交流

体系结构突出了早期的设计决策，这些决策对随后所有的软件工程工作有深远的影响

体系结构”构建了一个相对小的、易于理解的模型，该模型描述了系统如何构成以及其构件如何一起工作“

Architectural Styles

以数据为中心的体系结构

数据流体系结构

调用和返回体系结构

面向对象体系结构

层次体系结构

Component-level Design

Component definiton

系统中模块化的、可部署的和可替换的部件，该部件封装了实现并对外提供一组接口

Component-level(class-based) 基本设计原则

开闭原则（OCP）

Liskov 替换原则（LSP）

依赖倒置原则（DIP）

接口分离原则（ISP）

Interface Design

Golden Rules

把控制权交给用户

减轻用户的记忆负担

保持界面一致

User Interface Design Models

用户模型

设计模型

心理模型（系统感知）

实现模型

User Interface Design Process

（1）界面分析和建模；（2）界面设计；（3）界面构建；（4）界面确认。

Interface analysis and modeling

用户分析

任务分析和建模

显示内容分析

工作环境分析

Interface design

（1）定义界面对象和动作（操作）；（2）确定事件（用户动作），即会导致用户界面状态发生变化的事件；（3）描述每个状态的表示形式；（4）说明用户如何利用界面提供的信息来解释每个状态。

Software Testing Strategies

Objective of Software Testing

测试的目的是为了发现软件设计和实现过程中的疏忽所造成的错误

Testing Strategies 特征

为完成有效的测试，应该进行有效的、正式的技术评审。通过评审，许多错误可以在测试开始之前排除。

测试开始于构件层，然后向外“延伸”到整个计算机系统的集成中。

不同的测试技术适用于不用的软件工程方法和不同的时间点。

测试由软件开发人员和（对大型项目而言）独立的测试组执行。

测试和调试是不同的活动，但任何测试策略都必须包括调试。

Test Strategy

单元测试Unit Test

集成测试Integration Test

确认测试Validation Test

系统测试System Test

Unit Test

驱动程序Driver：驱动程序是一个主程序，它接收测试用例数据，将这些数据传递给（将要测试的构件）构件，并打印相关结果；

桩程序Stub：桩程序的作用是替换那些从属于被测构件（或被其调用）的模块。

Integration Test

自顶向下集成、自底向上集成、三明治测试、回归测试、冒烟测试

Validation Test

确认测试准则：软件确认是通过一系列表明软件功能与软件需求相符合的测试而获得。设计的特定测试用例用于确保软件满足所有的功能需求，具有所有的行为特征，所有内容都准确无误且正确显示，达到所有的性能需求，文档是正确的、可用的，且满足其他需求。

配置评审：评审的目的是确保所有的软件配置元素已正确开发、编目，且具有改善支持活动的必要细节。

验收测试：α测试和β测试。

System Test

恢复测试、安全测试、压力测试、性能测试、部署测试、配置测试

Debugging

测试发现错误，调试诊断错误出现的原因和位置，以便于消除错误

Debugging Techniques

蛮干法

回溯法

原因排除法

Testing Conventional Applications

White-box Test

白盒测试，也叫玻璃盒测试或结构化测试，是基于过程细节的封闭测试，检查构件内部处理逻辑、数据结构和构件间的协作（接口）的正确性。（内部测试）

基本路径测试

控制结构测试

Black-box Test

黑盒测试，也称行为测试或功能测试，从外部（软件接口处）执行测试用例，用以验证待测功能的正确性，而不考虑软件内部处理逻辑。（外部测试）

等价类划分

边界值分析

Testing Object-Oriented Application

OO Test

OO Test Strategy

OO Unit Testing

OO Integration Testing