软件工程笔记/中英文

软件
(i) Use Case
(ii) Software Development Life Cycle
(iii) Open-Closed Principle (OCP)
(iv) Interface Segregation Principle (ISP)
(v) White-Box Testing

什么是软件

• 程序 program
• 文档 document
  开发维护使用程序的图文资料
  Documentation is the graphic and textual information needed to develop, use and maintain the program;
• 数据 data
  Data are the data structures that enable programs to process information appropriately.

Software Engineering Hierarchy Diagram

通用过程框架(Framework)

五个基本框架活动

• Communicate 沟通
  在技术工作（technical work）开始前和客户沟通，理解利益相关者的项目目标（stakeholders’ project goals），并收集需求（gather requirements）以定义软件的特性和功能（software features and functionality）。
• Planning 策划
  定义和描述软件工程的工作，包括：
  需要执行的技术任务，可能的风险，资源需求，工作产品，工作进度计划。
  technical tasks to be performed, possible risks, resource requirements, work products, work schedules.
• Modeling 建模
  使用模型更好的理解软件需求
• Construction 构建
  编码和测试（以发现编码中的错误）
• Deployment 部署
  Software is delivered to users, who evaluate it and give feedback.
  用户评估并给出反馈。

Process flow

迭代过程流：在执行下一个活动前重复执行之前的一个或多个活动。
Repeat one or more previous activities before executing the next.

采用循环的方式执行各个活动，每次循环产生更为完善的软件版本

将一个或多个活动与其他活动同时进行

Process Models（过程模型）（unfinish

1. 瀑布模型（Waterfall Model）(called the classic life cycle)：
   前提：需求必须是准确定义和相对稳定的
   固定顺序连接的若干阶段工作(a systematic, sequential approach to software development)：
   即从用户需求规格说明开始，顺序地通过沟通、策划、建模、构建和部署过程，最终提供完整软件和持续技术支持(finally providing complete software and ongoing technical support.)
   

2. V-model
   编码结束后，团队沿着V模型右侧的步骤向上推进，其本质是增加了一系列测试
   After coding, the team moves up the steps to the right of the V model, essentially adding a series of tests

3. 增量过程模型 Incremental Process Models

Agile Development 敏捷开发（unfinish

Agile Values:

• Communication
• Simplicity
• Feedback
• Courage
• Respect (Humility)

What is agile development: It is a software development methodology that responds to the rapidly changing needs of customers. It emphasizes the human-centered, iterative approach to developing software step by step.
它是一种软件开发方法学，能够响应客户快速变化的需求。它强调以人为中心，循序渐进地迭代开发软件。

Extreme Programming 极限编程

XP Design

• Follows the KIS principle
• Encourage the use of CRC cards (see Chapter 8)
• For difficult design problems, suggests the creation of “spike solutions”—a design prototype
• Encourages “refactoring”—an iterative refinement of the internal program design

XP Coding

• Recommends the construction of a unit test for a store before coding commences
• Encourages “pair programming”

XP Testing

• All unit tests are executed daily
• “Acceptance tests” are defined by the customer and excuted to assess customer visible functionality

XP设计

• 遵循KIS原则
• 鼓励使用CRC卡(见第8章)
• 对于困难的设计问题，建议创建“spike解决方案”——一个设计原型
• 鼓励“重构”——迭代优化内部程序设计

XP的编码

• 建议在编码开始之前为store构建单元测试
• 鼓励“结对编程”

XP测试

• 所有单元测试每天执行
• 验收测试”由客户定义并执行，以评估客户可见的功能

分析

软件需求（unfinish

功能需求—描述系统预期提供的功能或服务：

• 系统应提供的服务
• 系统如何对输入做出反应
• 系统在特定条件下的行为
• 系统不应该做什么
• 数据

非功能需求：不直接与系统具体功能相关的需求：

• 产品需求：产品行为的需求，包括性能需求、可靠性需求和可用性需求等。
• 机构需求：客户和开发者所在机构中的政策和规定要求，如过程标准、实现要求、交付需求。
• 外部需求：所有的系统外部因素要求，如互操作需求、道德需求。

需求工程要干啥？

• 理解客户需要什么
• 分析要求
• 评估可行性
• 协商合理的方案
• 生成无歧义地详细说明方案
• 确认规格说明
• 管理需求以至将这些需求转化为可运行系统。

需求工程过程主要通过执行七个不同的活动来实现：

• 起始、获取、细化、协商，规格说明，确认和管理。

Requirements Modeling Model

需求建模动作产生以下一种或多种模型类型：

• 场景模型：出自各种系统“参与者”观点的需求。
  Scenario Model: Requirements from the viewpoints of various system “participants”.
• 数据模型：描述问题信息域的模型。
  Data Model: A model that describes the information domain of the problem.
• 面向类的模型：表示面向对象类(属性和操作)的模型，其方式为通过类的协作获得系统需求。
  Class-Based Model: A model that represents object-oriented classes (attributes and operations) in such a way that system requirements are obtained through the collaboration of classes.
• 面向流程的模型：表示系统的功能元素并且描述当功能元素在系统中运行时怎样进行数据变换的模型。
  Process-Based Model: A model that represents the functional elements of the system and describes how data transformations occur when the functional elements run in the system.
• 行为模型：显示了软件如何对外部事件或激励做出相应。
  Behavioral Model: Shows how the software responds to external events or stimuli.

Use case

Usage Scenarios

• Scenario: Often called a use case, it provides a description of how the system will be used (similar to an example).
• 情景：通常被称为用例，它提供了一个关于系统如何使用的描述（类似于一个例子）。

用例从最终用户的角度描述了软件或系统。（Use cases describe the software or system from the end user’s perspective.）撰写用例的第一步是确定故事中所包含的“参与者”（Participants）：

• 参与者是在功能和行为环境内使用系统或产品的各类人员(或设备)。参与者代表了系统运行时人(或设备)所扮演的角色。

需求导出是一个逐步演化的活动，因此在第一次迭代中并不能确认所有的参与者。在第一次迭代中有可能识别主要的参与者，而对系统了解更多之后，才能识别出次要的参与者：

• 主要参与者（The major participants)直接且经常使用软件、获取所需的系统功能并从系统得到预期收益。
• 次要参与者(secondary participants)支持系统，以便主要参与者能够完成他们的工作。

需求案例：

案例1

功能分析


Use Case Diagram

案例3 safehome系统 用例（usecase）模板

基于场景建模 Scenario-Based Modeling

• 运用需求收集会议、质量功能部署和其他需求工程机制确定利益相关者
• 定义问题的范围
• 说明整体的运行目标
• 建立优先级顺序
• 概述所有已知的功能需求
• 描述系统将处理的信息(对象)

非正规用例 （Informal use case）：

UML活动图（Activity Diagram）-Supplement the Use Case

UML活动图在特定场景内通过提供迭代流的图形化表示来补充用例。

• 两端为半圆形的矩形表示一个特定的系统功能
• 箭头表示通过系统的流
• 判定菱形表示判定分支
• 实心水平线意味着并行发生的活动。(见后面的案例)

泳道图 swimland ：

• 活动图的一种有用的变形。
• 指示了参与者或分析类负责的活动。
• 职责由纵向分割图的并列条形部分表示，就像游泳池中的泳道。
• 确定哪几个分析类 (如下图的中房主、摄像机和接口)对活动图中的情景有直接或间接的责任，并重新排列活动图。
  

面向类建模 Class-Based Modeling

类图

CRC模型

是表示类的标准索引卡片的集合，分成三部分：

1. 顶部写类名；
2. 主体左侧列出类的职责；
   -职责：和类相关的属性和操作，即“类所知道或能做的任何事”
3. 主体右侧列出类的协作者；
   -协作者：完成某个职责需要的其它类，即信息请求或动作请求
   
   unfinish）

类间三种通用关系

(1) is-part-of (是……的一部分)

（2) has-knowledge-of (有……的知识)

• 当一个类需要从另一个类中获取信息时：
• • 例如，ControlPanel必须从Sensor类中获取每个传感器的状态；

(3) depends-upon (依赖……)

• 意味着两个类之间具有is-part-of和has-knowledge-of 不能实现的依赖关系：
• • 例如，PlayerHeader通常必须连接到PlayerBody；

*分析包

将分析模型的各种元素(如用例、分析类)以一种方式分类，分组打包后称其为分析包，并取一个有代表性的名。比如：视频游戏。

“+” 公共可见，可以从其他包访问
“–” 该元素对其他包是隐藏的
“#” 只能由指定包中的类访问

面向数据流建模

数据流图 Data flow diagram（DFD)
DFD采取了系统的输入-处理-输出观点

状态转换图 State Transition Diagram(STD)

• 每个箭头表示某个对象从一个主动状态转移到另一个主动状态。
• 每个箭头上的标注都体现了触发状态转移的事件。
  

设计

软件的设计是一个将需求转变为软件陈述（表达）的过程。系统通过逐步求精（gradual refinement）使得设计陈述逐渐接近源代码：

• 初步设计Preliminary design，关注于怎么将需求转换成数据和软件框架。
• 详细设计Detail design，关注于将框架逐步求精细化为具体的数据结构（specific data structuers）和软件的算法表达（algorithm expression）。设计行为、数据、算法和程序设计都需要由现代程序所需的界面设计（interface design）这一清晰的行为来结合起来。

抽象abstract

数据抽象：描述数据对象的数据集合

• 定义数据类型和施加于该类型对象的操作。
• 门的数据抽象包含一组描述门的属性 (例如，门的类型、转动方向、开门方法、重量和尺寸)

过程抽象：具有明确和有限功能的指令序列。

• 过程抽象的命名暗示了功能，但是隐藏了具体的细节。
• 这些功能实际上是由一系列更低级的功能或代码来实现的。
• 过程抽象“开”将利用数据抽象“门”的属性中所包含的信息。
• 过程抽象例：函数、功能性的类/对象 (开门包括：走到门前，伸出手并抓住把手，转动把手并拉门，从移动门走开等)。
  

模块化（modularity）

模块化就是把程序划分成独立命名且可直接访问的模块，各个模块完成一个子功能，这些模块集成起来构成一个整体，完成指定功能。
Modularity is to divide the program into independently named and directly accessible modules. Each module completes a subfunction. These modules are integrated to form a whole and complete the specified function.

模块（module）是相对独立的程序体：

• 模块是数据说明、可执行语句等程序对象的集合。
• 模块是单独命名的，并且可以通过名字来访问。
  例如：类、过程、函数、子程序、宏等
  模块是相对独立的程序体：
  模块是数据说明、可执行语句等程序对象的集合。
  模块是单独命名的，并且可以通过名字来访问。
  例如：类、过程、函数、子程序、宏等
• 模块数量增加时，使各个子模块的工作量之和有所减小
• 开发工作量还有很大一部分来自于模块间的接口和集成，除了技术上的接口和集成，还包括人与人之间的沟通，集成和沟通的开销到了一定程度就会成为开发工作量的主要部分。
  

内聚度（cohesion）与耦合度（coupling）

内聚(cohesion)：一个模块内部各个元素彼此结合的紧密程度 ——尽量高
the tightness of each element in a module

耦合(coupling)：模块之间相互关联的程度 ——尽量低
the degree of correlation between modules

• 耦合性依赖于模块之间的接口复杂性、引用或进入模块所在的点以及什么数据通过接口进行传递。
• 模块间简单的连接性使得软件易于理解并减少“涟漪效果”(ripple effect)的倾向。
• 当在某个地方发生错误并传播到整个系统时，就会引起“涟漪效果”。

耦合类型

• 内容耦合（content coupling）：一个模块可以直接访问另一个模块的内部数据或内部功能 ——最不可取
• 公共耦合（public coupling)：多个模块共同访问某些公共数据元素.
• 控制耦合(control coupling)：模块间的交互参数包含控制信息，可影响另一个模块的执行逻辑
• 数据耦合(data coupling)：模块间仅传递简单数据. ——最可取
  

体系结构的style

数据流体系结构（Data-flow architecture）

当输入数据经过一系列的计算构件和操作构件的变换形成输出数据时，可应用该体系结构。例如管道—过滤器（pipe-and-filter pattern）模式：

• 拥有一组称为过滤器的构件，这些构件通过管道连接，管道将数据从一个构件传送到下一个构件。

• 每个过滤器独立于其上游和下游的构件（components upstream and downstream）而工作，过滤器的设计要针对某种形式的数据输入，并且产生某种特定形式的数据输出 (到下一个过滤器)。

• 然而，过滤器没有必要了解与之相邻的过滤器的工作。
  
  优点：

• 易理解；

• 容易并行运行。
  问题：

• 适用于批处理(batch processing)，不易交互(interact)；

• 流的协作（collaboration)需要考虑。

回顾案例1


体系结构

基于类的构件

A component is a modular building block for computer software.

组件是“一个模块化的、可部署的、可替换的系统部分，它封装了实现并公开了一组接口。
component is “a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces.

开闭原则 (The Open-Closed Principle, OCP)：

模块应该对外延具有开放性，对修改具有封闭性；
A module [component] should be open for extension but closed for modification

• 设计者应采用一种无需对构件自身内部(代码或内部逻辑)做修改就可以进行扩展的方式来说明构件。

• 解决方法：抽象、多态，引入抽象基类，构件的变化通过引入新的派生类来完成。

Liskov替换原则（The Liskov Substitution Principle ，LSP)

子类可以替换它们的基类；
Subclasses should be substitutable for their base classes

依赖倒置原则（Dependency Inversion Principle ，DIP)

依赖于抽象，而非具体实现 ；
Depend on abstractions. Do not depend on concretions

• 依赖倒置原则，即父类不能依赖子类，它们都要依赖抽象类：

• • 一旦类的使用者依赖某个具体的类，那么对该依赖的扩展就无从谈起；
• • 而依赖某个抽象类，则只要实现了该抽象类的子类，都可以被类的使用者使用，从而实现了系统的扩展。

• 一个系统或子系统要拥有良好的扩展性和实现运行期内绑定，有两个必要条件：第一是里氏替换原则(子类可以替换父类，例如运动员可以替换人，人的所有属性与操作运动员都具备)；第二是依赖倒置原则(父类不能依赖于子类，例如人不能依赖于运动员，运动员的某些属性与操作有些人不具备)。

接口分离原则 (Interface Segregation Principle, ISP)

多个用户专用接口比一个通用接口要好
Many client-specific interfaces are better than one general purpose interface.

• 设计者应该为每个主要的客户类型都设计一个特定的接口。只有那些与特定客户类型相关的操作才应该出现在该客户的接口说明中。
  ISP suggests that you should create a specialized interface to serve each major category of clients. Only those operations that are relevant to a particular category of clients should be specified in the interface for that client.

测试

1.单元测试 (unit testing)
What is unit testing
Refers to the inspection and verification of the smallest testable unit in the software. A unit is the smallest module that is considered to be tested
指对软件中最小可测试单元的检查和验证。单元是被测试的最小模块
2.集成测试 (integration testing)
.What is integration testing
The next stage of unit testing refers to assembling the tested unit modules into a system or subsystem, and then testing.
单元测试的下一个阶段是指将被测试的单元模块组装成一个系统或子系统，然后进行测试。
3.确认测试 (Validation Testing)begins at the end of integration testing Software validation is obtained by a series of tests demonstrating conformity to software requirements.
在集成测试结束时，通过一系列测试证明软件符合需求，得到软件的确认。
4.系统测试 (System Testing)
System Testing is to verify that system components are properly integrated and perform their assigned functions.
系统测试是为了验证系统组件是否正确地整合在一起，并执行指定的功能。

黑盒测试百盒测试

黑盒测试：

• 在软件接口处进行测试，检查系统的功能方面，不需了解软件的内部结构。

白盒测试：

• 检查软件的过程细节，测试贯穿软件的逻辑路径和构件间的协作。
• 将获得“百分之百正确的程序”？
• 百分之百的正确性的测试前提是：通过所有的逻辑路径和相应的所有用例——几乎不可能。

独立路径

独立程序路径是任何贯穿程序的，至少引入一组新的处理语句或一个新条件的执行路径。(不能由其它独立路径组合而成)

测试用例

管理

在项目策划中，规模是指可量化的软件项目的结果:
如果采取直接的方法，大小可以以代码行数(lines of code，LOC)衡量;
如果选择间接方法，规模可以用功能点(function points，FP)来表示

关键路径法（Critical Path Method，CPM）

❑关键路径是决定项目完成的最短时间。
❑是时间浮点数为0(浮点数=0)的路径。
❑网络图中最长的路径。
❑关键路径上的任何活动延迟都会延迟整个项目的完成。