西电软件工程概论复习笔记（含重点标注）

软件工程概论复习

有加粗的都是很重要的课后题中的对应题目。

Chapter1 Introduction

1.1 什么是软件工程？

1、有关软件（重点）

软件 = 程序 + 数据 + 文档（去年考题）

Software is a set of program(instruction) , data(structure) and documents

• 解决问题：

  方法 工具 过程 范例

​ method tool procedure paradigm

2、有关软件工程（重点）

• Software engineering means the application of a systematic , displined and measureable approach to the development , operation and maintenance of software. That is the application of engineering to software.

  软件工程：使用 系统的，有规律的，可测量的方法去开发，运行，维护软件。

• Any Problem-solving technique must have two parts, analyzing to problem to determine its nature, and then synthesizing a solution

  分析问题 综合解决方法

3、什么是好的软件工程（重点）

• The McCall’s quality model concerns the quality of the software product ,

• CMM concerns the quality of the process of development software product

• and ROI concerns the quality of the context of the bussiness environment

4、谁做软件工程（重点）

customer + developer + user

• The customer is the company, organization ,or a person who is paying for the software system to be developed.
• The developer the company, organization ,or a person who is building the software system.
• The user is the person or people who will actually use the system.

5、一个系统方法

（1） what is a system？

system is a collection of objects and activities, plus a description of the relationships that tie the objects and activities together.

系统是对象和活动的集合，加上对象和活动之间关系的描述。

（2）The Elements of a System

• objects and activities
• relationship and the system boundary
• examples of system

6、一个工程方法

Building a system

软件开发的活动：（在大纲中，但不一定是重点，课后题无这个题目）

• 需求分析和定义 ——Requirement analysis and definition
• 交流设计 ——System design
• 程序设计 ——Program design
• 写程序（程序实现） ——Writing the programs
• 单元测试 ——Unit testing & 整体测试 ——Integration testing
• 系统交付 ——System testing
• 维护——Maintenance

The software development usually involves requirement analysing and defination, system design, program design, program implementation, unit testing, integration tesing, system delivery and maintenance stages

7、开发组的成员

• analyst
• designer
• programmer
• tester
• trainer

Any entity to be engineered ,we must do analyst , designer, construction, verification and managment

简答：Briefly describe the roles of analyst, designer, programmer, tester, and trainer.

• the requirement analyst work with customer, break down what the customer wants into discrete requirement.

  与客户一起工作，将客户的需求分解成离散的需求。

• the designer generate the system-level description of what the system is to do

  生成关于系统要做什么的系统级描述

• the programmer write line of code that implement what requirement specify.

  编写一行行代码，实现需求指定。

• the tester catches faults that programmer overlook

  发现程序员忽略的错误

• the trainer shows users how to use the system

  培训师向用户展示如何使用该系统

Chapter 2 Modeling the Process and Life Cycle

1、The meaning of process(重点)

（1）What is a process, a life cycle, and a software life cycle?

• process

We can think a set of ordered tasks as a process, a series of steps , including activities , constrains and resources

过程： 一系列的顺序任务，过程 = 步骤 —— 活动 + 约束 + 资源

• life cycle

When the process involves building of some product , we sometime refer to the Process as a lifecycle

当过程涉及到构建某些产品时，我们有时将过程称为生命周期。

• software life cycle

The life cycle of a software product include conception , implementation, delivery, use, and maintenance

软件的生命周期：概念---->实现---->交付—>使用---->维护

（2）Understanding the concept of a process, prescription and description

2、software process models（重点）

Several typical software process models – description, advantages and disadvantages and examples

• Waterfall model
• V model
• Prototyping model
• Phased development: increments and iterations
• Spiral model
• Agile methods

（1）瀑布模型：

The waterfall mode include requirement analysis, system design, program design, coding, unit & integration testing, system testing, acceptance testing ,and operation & maintenance steps.

• 增加了两个V的瀑布模型：

The validation ensures that the system has implemented all of the requirement, But the verification ensures that each function works correctly. 有效性 + 认证

• 优点：

  模型简单，客户和开发人员容易理解

  为项目提供了按照阶段划分的检查点

  精确定义了每位开发人员的不同职能

  可强迫开发人员采用规范化的方法

  说明了每个主要阶段完成的里程碑或可交付产品

• 缺点：

  由于瀑布模型几乎完全依赖于书面的规格说明，很可能导致最终开发出的软件产品不能真正满足用户的需要

  只适用于项目开始时需求就已经确定的情况，无法应对开发过程中需求的变更

  将软件开发视为一个制造过程而不是一个创造过程

  往往需要很长时间才能得到最终产品

• 适用情况：

  开发已经有明确规定的确定项目

  需求一旦确定便不再发生变化

  组织具有明确分工的项目

  重新开发一个与之前相同的项目，即重复开发

（2）V模型：

The V model makes more explicit some of the iteration and rework that are hidden In the waterfall model

• 优点/特点：

  测试与需求相对：

  • 采用参与测试来验证程序设计
  • 采用集成测试来验证体系结构
  • 采用验收测试来确认需求。

  验证过程中发现问题即可在执行后续测试步骤前重新执行左边步骤对软件修正。

（3）螺旋式模型：

The spiral model combine the development activities with risk management to minimize and control the risk control。

瀑布模型与原型模型的组合，既可以周期性地验证客户的需求，又可以分阶段进行开发工作，能保证软件在遇到较大风险时停止，大大增强了软件的风险防控能力。但是过程很复杂，需要开发人员有丰富的风险评估能力和专业知识，适合大型项目的开发。

• 优点：

  将开发活动与风险管理相结合以最小化控制风险

  较好地满足用户的需求

• 缺点：

  开发成本高，对开发人员要求高

（4）原型设计模型：

在需求分析阶段对软件进行初步的分析和定义，快速开发出简单的软件原型并向用户展示，用户对软件原型进行测评后进一步提出进要求，开发人员的原型修改到用户满意为止。因此原型模型的开发更能符合需求，适合市场导向（market-driven）的产品。

A prototyping model is a partially developed product that enable customers and developers。 To examine some aspect of the proposed system and decide if it is suitable or appropriate for the final product.

• 优点：

  很好地满足客户的真实需求

  原型系统已经通过与用户进行交互而得到验证，据此产生的规格文档能正确描述用户的需求

  软件产品的开发基本是线行进行

  建造出原型系统后，开发人员可以加速软件开发过程，节约软件开发成本

（5）增量模型：

增量：将系统功能划分为诸多子系统，先开发具有一个小功能的子系统，之后不断在子系统上增加新的功能来逐渐满足所有需求

迭代：第一次提交的产品就是一个完整的系统，之后在该系统的基础上不断修改，不断开发出新的版本，但是每个版本都是完整可运行的版本。

• 优点：

  逐步增加产品功能使用户有充足的时间学习和适应新产品

  一部分一部分的开发，能在较短时间内就向用户提供一个有用功能的产品

  项目的风险较低，能较好满足客户需求

简答题：Briefly describe the advantage and disadvantage of the WatterFall model

优点：

• 模型简单，用户和开发者容易理解
• 为每一位开发者精细划分了不同职能
• 说明了每一个重大阶段完成的里程碑或可交付产品
• 强迫开发者开发使用规范的方法

缺点：

• 严格按照书面的规格说明，最后的产品可能和用户的要求不符合
• 把开发视作一个制造过程而不是一个创造过程
• 可能需要很长时间才能得到产品

Chapter 3 Planning and Managing the Project

1、Tracking progress

（1）What is a project schedule, an activity, and a milestone

• project schedule

A project schedule describes the software development cycle for a particular project by enumerating the phases or stages of the project and breaking each into discrete tasks or activities to be done.

项目进度表通过列举项目的阶段，并将每个阶段分解成独立的待完成的任务或活动，来描述一个特定项目的软件开发周期。

The Schedule is a timeline that shows when activities will begin and end, and When the related development products will be ready.

The Deliverables , that is the item that the customer expects to see during project development.

交付物，即客户希望在项目开发期间看到的项目。

• activities

An activity is a part of the project that takes place over a period of time, whereas a milestone is the completion of an activity- a particular point of time

• milestone

a milestone is the completion of an activity- a particular point of time

（2）Work breakdown and activity graphs工作分解和活动图表

The Gantt Graph depicts the project as a set of discrete pieces of work.

甘特图将项目描述为一组离散的工作片段。

The real time or actual time for an activity is the estimated amount of time required for the activity to be completed. The avaliable time is the amount of time available in the schedule for the activity’s completion. slack time or float time for an activity is the difference between the avaliable time and real time for that activity

The critical path is a path that the slack time at every node is zero.

GANTT CHART is used to depict the projects’ CMP.

必考大题

• Estimating completion

• CPM (Critical Path Method)

• slack time for an activities

求关键路径：

求关键路径只需要找到最早开始时间和最迟发生时间相等的事件即可。

有关事件的关键路径与松弛时间

• 最早开始时间：【从前往后算】，事件vi的最早开始时间 = 从源点 v1 到顶点 vi的最长路径长度
• 最迟发生时间：【从后向前算】，事件vi的最迟发生时间 = earliest(n) - （从定点vi到vn的最长路径）

另外还有一个概念为松弛时间slack time ，为最早开始时间和最迟开始时间二者的差，也就是说关键路径的节点就是松弛时间为0的点。
$$slacktime(i)=lasteststarttime(i)-earlieststarttime(i)$$

例题1：

事件	最早开始时间	最晚开始时间	松弛时间
1	15+1	18+1	3
2	8+1	8+1	0
3	15+1	40+1	25
4	10+1	40+1	30
5	23+1	23+1	0
6	28+1	50+1	22
7	38+1	38+1	0
8	45+1	45+1	0
Finish	65+1	65+1	0

松弛时间计算如上表，关键路径为：
$$START->2->5->7->8->Finsh$$
例题2：

事件	最早开始时间	最晚开始时间	松弛时间
B	3+1	24+1	21
C	6+1	14+1	8
D	10+1	10+1	0
E	18+1	39+1	11
F	18+1	18+1	0
G	21+1	41+1	20
H	38+1	38+1	0
I	22+1	36+1	14
Finish	48+1	48+1	0

松弛时间计算如上表，关键路径为：
$$START->D->F->H->Finsh$$

有关活动的关键路径和松弛时间

对于活动：$a_k=<v_i,v_j>$

• 活动$a_k$的最早开始时间 = 事件$v_i$的最早开始时间

• 活动$a_k$的最晚发生时间 = 事件 $v_j$的最迟发生时间 - 完成该活动的计划时间。

特别注意：最早开始时间和最晚开始时间都要+1处理！！！！！！！！

例3：

活动	最早开始时间	最晚开始时间	松弛时间
A->B	0+1	21+1	21
A->C	0+1	8+1	8
A->D	0+1	0+1	0
B->E	3+1	24+1	21
C->F	6+1	14+1	8
D->F	10+1	10+1	0
E->G	18+1	39+1	21
F->H	18+1	18+1	0
F->G	18+1	38+1	20
F->I	18+1	32+1	14
I->H	22+1	37+1	15
I->FINISH	22+1	36+1	14
H->FINISH	38+1	38+1	0
G->FINISH	21+1	41+1	20

例：

活动	最早开始时间	最晚开始时间	松弛时间
1->2	1	1	0
2->3	4	9	5
2->4	4	6	2
2->5	4	4	0
2->6	4	5	1
3->7	6	11	5
4->7	9	11	2
5->7	7	7	0
6->7	5	6	1
7->8	13	13	0

所以，关键路径为：
$$1->2->5->7->8$$

2、Project personnel 项目人员

（1）Staff roles and characteristics

• lines of communication

如果一个工作中有n个人，那么一共有n（n-1）/ 2条交流线

• characteristics

  Extrovert（外向）: tell their thoughts

  Introvert（内向）: ask for suggestions

  Intuitive（直觉）: base decisions on feelings

  Rational（理智）: base decisions on facts, options

（2）Work styles

（3）Project organization

组织形式取决于下面三个因素：

• 小组成员的背景和工作风格 backgrounds and work styles of team members
  • 内向/外向
  • 理智/直觉
• 小组成员数 number of people on team
• 客户和开发者的管理风格 management styles of customers and developers

组织形式：

• chief programmer team：高效的组织方式

  Each team member must communicate often with chief, but not necessarily with other team members

  试用：

  • 重复性
  • 高确定性
  • 大项目

• egoless approach

  适用：

  • 不确定性
  • 新技术
  • 小项目

3、 Effort estimation

（1）Can not produce accurate estimates

（2）Effort estimation techniques

• expert judgment
• algorithmic methods
• machine-learning methods

4、Risk management activities

（1）What is a risk?

Risk management is concerned with identifying risks and drawing up plans to minimize their effect on a project。

（2）Steps in risk management

$$风险管理：\{\begin{array}{l}风险评估\{\begin{array}{l}风险识别\\ 风险分析\\ 风险分级\end{array}\\ 风险控制\{\begin{array}{l}减少风险\\ 风险管理计划\\ 风险解决\end{array}\end{array}$$

（3）How to reduce risk?

大题

1、Give some diliverables：列出一些可交付物

• documents
• demonstrations of function
• demonstrations of accuracy
• demonstrations of subsystems
• demonstrations of reliability, performance or security

2、Briefly describe the characteristic of software development team’s individual：描述软件开发团队个体的特征

• ability to perform the work 能力
• interest in the work 兴趣
• experience with similar **applications **
• experience with similar tools or languges
• experience with similar techniques
• experience with similar development environment
• trainning 训练
• ability to communicate with others

Chapter 4 Capture the Requirements

1、What is a requirement?

A requirement is an expression of desired behavior。

Requirements focus on the customer needs, not on the solution or implementation

2、Requirements elicitation

The process for capturing the requirement has four steps, there are elicitation，analysis , specification,and validation。

• 需求抽取 requirement elictation

• 需求分析 analysis

• 需求规范 Requirements Specification

  需求规范

  将需求整理为规范性的文档。what the designers need to know

  用户、设计者、测试人员是需求文档的直接使用者，而程序员不是。

• 需求验证

3、Types of requirement（重点）

There four type of requirement, they are the fundmental requirement , Quality requirements/nonfunctional requirements, design contraist and process constraist.

• 功能性需求

  • input or required activities

  • 举例：

  • System shall communicate with external system X.

  • What conditions must be met for a message to be sent.

• 非功能性需求/质量需求

  • Paychecks distributed no more than 4 hours after initial date are read.
  • System limits access to senior managers.

• 设计限制

  • 接口与组件限制设计

• 过程限制

  • 技术和资源限制

4、resolving conflicts——priority

• correct ：we and customer read it , and they comfirm our understanding
• consistant：no conflicting requirement
• unambigious：muliple readers of the requirements can walk away with different but valid interuptions
• complete：specifies required behavior and output for all possible inputs in all possible states under all possible constraints.
• feasible： there is a solution
• relevent：restricts the developers unnecessarily, or includes functions that are not directly related to the customer’s needs.
• testable：acceptance tests that would clearly demonstrate whether the eventual product meets the requirements.
• traceable：the requirements organized and uniquely labeled for easy reference.

5、types of requirements documents需求说明书的类型

• Requirements definition

  • a complete listing of everything the customer wants to achieve
  • 一份关于软件功能的完整清单，是给用户看到，用户希望实现的功能。what the customer wants

• Requirements specification

  • restates the requirements as a specification of how the proposed system shall behave

  • 将需求整理为规范性的文档。what the designers need to know

    用户、设计者、测试人员是需求文档的直接使用者，而程序员不是。

6、Modeling notations建模符号（重点）

（1）Entity-relationship diagrams（ERD）（重点）

• Definition

  a popular graphical notational paradigm for representing conceptual models

  表示概念模型的流行图形符号

  表示概念模型的一种方法，包含实体，联系，属性三个要素。对应UML中的类图。

• Three elements

  • Entity 实体—矩形
  • relationship 联系— 菱形
  • attribute 属性—标注

• Properties/application

  ER图之所以流行是因为：

  • 提供了解决问题的概述
  • 当修改问题的要求时，视图相对稳定

  ER表示法的简单性具有欺骗性。实际上，在实践中很好使用ER建模是非常困难的

  建模标准：

  • 选择是否会导致更清晰的描述
  • 一个选择是否不必要地限制了涉及决策

• UML class diagrams

  与ER图相似

（2）Event traces

• Definition

  对现实世界实体之间交换的一系列事件的图形描述。

• Properties/application

  垂直线：不同实体的时间轴，其名称出现在线的底部

  水平线：分界线上的两个实体的交互作用

• UML sequence diagrams

（3）State machines

• Definition

  系统与环境之间所有对话的图形化描述

• Two elements

  • node：状态，表示事件之间的稳定关系
  • edge：表示事件的发生而导致的行为或条件

• Properties/application

• UML statechart diagrams

（4）Data-flow diagrams (DFD)(重点)

• Definition

  ER图，Events trace ，state machine只是描述比较低级的行为

  数据流图DFD对从一个功能到另一个功能的数据进行描述

• Four elements

  • Process 气泡表示过程
  • data flow 箭头表示数据流
  • data store 信息的正式存储或者数据库
  • actors 矩形代表参与者

• Properties/application

优点：

Provides an intuitive model of a proposed system’s high-level functionality and of the data dependencies among various processes

缺点：

对不熟悉建模的人来说可能有点模糊

• UML use case diagrams

  DFD与用例图相似

（5）Functions and relations

​ Decision table

7、Prototyping requirements

• Rapid prototyping
• Throwaway prototyping
• Evolutionary prototyping

Prototyping vs. modeling

There are two approaches to prototype, they are the throwaway prototype and evolution prototype.

In UCD, a large box represents the system boundary.

大题

1、Briefly describe the roles of the seven groups of stakeholders.简要描述七组利益相关者的角色

• client：who are the ones paying for the software to be developed
• Customers: buy the software after it is developed
• Users: use the system
• Domain experts: familiar with the problem that the software must automate
• Market Researchers: conduct surveys to determine future trends and potential customers
• Lawyers or auditors: familiar with government, safety, or legal requirements
• Software engineers or other technology experts

2、 Briefly describe the function of the four types of the requirement.

• functional requirement：describes required behavior in terms of required activities

  根据需要的活动描述需要的行为

• qualtity requirement：describes some quality characteristic that the software solution must possess

  描述软件解决方案必须具备的一些质量特征

• process constraint：a restriction on the techniques or resources that can be used to build the system

  对可用于构建系统的技术或资源的限制

• design constraint：a design decision, such as choice of platform or interface components, that has already been made and that restricts the set of solutions to our problem

  一个已经做出的设计决策，例如平台或接口组件的选择，它限制了我们的问题的解决方案集

3、Briefly describe the functions of three core construct of ERD.

• entity：represents a collection (sometimes called a class) of real-world objects that have common properties and behaviors.

  表示具有公共属性和行为的现实世界对象的集合(有时称为类)。

• relationship：an edge between two entities, with a diamond in the middle of the edge specifying the type of relationship

  两个实体之间的边缘，边缘中间的菱形指定关系类型。

• atrribute：an annotation on an entity that describes data or properties associated with the entity.

  实体上的一种注释，用于描述与该实体相关联的数据或属性。

4、Briefly describe the functions of the two approaches of prototyping.

• throwaway prototyping：A throwaway prototype is software that is developed to learn more about a problem or about a proposed solution, and that is never intended to be part of the delivered software.

  一次性原型是为了更多地了解问题或建议的解决方案而开发的软件，它绝不是交付软件的一部分。

• evolution prototyping：an evolutionary prototype is software that is developed not only to help us answer questions but also to be incorporated into the final product.

  进化原型是一种软件，开发它不仅是为了帮助我们回答问题，而且是为了整合到最终产品中。

Chapter 5 Designing System

1、What is a design？

Design is the creative process of figuring out how to implement all the customer’s requirements; the resulting plan is called the design.

• Two stage of design

  ● Conceptual design or System design 概念设计/系统设计

  ● Technical design 技术设计

好的设计具备的特点：

• 构建独立性
• 异常标识和处理
• 放错和容错技术

2、Decomposition and modularity分解和模块化

• High level – lower level

  Modular decomposition 模块化分解 函数分配给模块 assign functions to modules

  Data-oriented decomposition 面向数据分解 based on external data structure

  Event-oriented decomposition 面向事件 based on event system must handle

  Outside-in design 从内到外设计 based on user input

  Object-oriented design 面向对象设计 identifying classes of objects and internal relationship

Starting with a high-level depiction of the system’s key elements and creating lower-level looks at how the system’s features and functions will fit together

从对系统关键元素的高级描述开始，然后创建较低级别的视图，了解系统的特性和功能将如何组合在一起

3、Architectural styles and strategies架构风格和策略

（1）Three design levels: architecture, code design, and executable design

体系结构，代码设计和可执行设计

The software architecture is consisted by three parts, they are components, connectors and constraits.

架构体系：

• 组件
• 连接器
• 限制

（2）Architectural styles

• pipes and filers(重点)

​ 每个模块都有一组输入与输出，每个模块从输入端接收数据流，内部处理后按照标准顺序将数据送至输出端，这种模式成为过滤器，而各个过滤器之间连接的导管，起数据传递的作用，称为管道。

​ 过滤器就是对数据进行处理的模块，而管道就是传递数据的通道，注意管道是支持并行的（concurrent execution），此模式可以描述并行的系统。

In pipe-and-filter style, the filter functions is to pass input data through a sequence of data-transforming components, and the pipe simply transmit data from one filter to the next without modifying the data.

过滤器函数是通过一系列数据转换组件传递输入数据，而管道只是将数据从一个过滤器传输到下一个过滤器，而不修改数据。

• 优点：

  • 设计者可以理解整个系统对输入和输出的影响，作为过滤器的组成

    The designer can understand the entire system’s effect on input and output as the composition of the filters

  • 过滤器可以很容易地在其他系统上重复使用

    the filters can be reused easily on other system

  • 系统进化很简单

    system evolution is simple

  • 允许并发执行过滤器

    allow concurrent execution of filters

• 缺点

  • 鼓励批处理

    encourage batch processing

  • 不适合交互式应用

    not good for handling interactive application

  • 过滤功能重复

    duplication in filters function

• Publish-subscribe（重点）

In publish-subscribe architecture, A substribe component express interest in an event by to it. When another component that the event has take place, the subscribing component are notified。

在发布-订阅体系结构中，订阅组件通过它表达对事件的兴趣。当另一个组件发生该事件时，订阅组件将得到通知。

隐式调用(implicit invocation) is a common form of publish-substribe architecture

• 优点

  • 对进化和定制的强大支持

    Strong support for evolution and customeization

  • 易于在其他事件驱动系统中重用组件组件

    easy to reuse components in other event-driven systems

• 缺点

  • 需要共享存储库来共享持久数据

    need shared repository for components to share persistent data

  • 难以测试

    difficult to test

• Client/Server

  • Two types of components:

  – Server components offer services

  – Clients access them using a request/reply protocol

In client-server architecture, the server component offer services, and client access them using a request/reply protocol.

在客户机-服务器架构中，服务器组件提供服务，而客户机使用请求/应答协议访问它们。

• Repositories 存储库架构

A repository style consists of two types of component, one is called central data store, another is called data accessing component.

Major advantage: openness

– Data representation is made available to various programmers (vendors) so they can build tools to access the repository

– But also a disadvantage: the data format must be acceptable to all components

• peer-to-peer

In peer-to-peer architecture, each peer executes as its own process and acts as both a client and a server to other peer component.

在对等体系结构中，每个对等点作为它自己的进程执行，并且作为其他对等组件的客户端和服务器。

Any component can initiate a request to any other peer component.

• layering

Layers are hierarchical

• High levels of abstraction

• Relatively easy to add and modify a layer

4、Issues in design creation

➢ Modularity and levels of abstraction

➢ Collaborative design

➢ Concurrency

Chapter 6 Design the Modules

1、Design Principles 设计原则

This chapter can help you see why certain design principles and conventions are applicable, and then assist you in deciding when should apply them.

In practice, there is no sharp bundary between the end of the architectural design phase and the start of the module design phase.

在实践中，在架构设计阶段的结束和模块设计阶段的开始之间没有明显的边界。

Design principles are guidelines for decomposing our system’s required functionality and behavior into modules.

设计原则是将系统所需的功能和行为分解为模块的指导方针。

• 软件架构的4+1视图模型

  • 逻辑视图

    将系统中的关键抽象为对象或者对象类

  • 进程视图

    显示系统在运行时是如何由相互作用的进程组成的

  • 开发视图

    显示如何对软件进行分解

  • 物理视图

    显示系统硬件和软件组件如何分布在系统的处理器

（1） Modularity

Design modules means decide how the individual component will be designed at a modular level so that developers can write code that implement the design.

Modularity, also called separation of concern, is the principle of keeping separating The various unrelated aspects of the system.

模块化，又称为分离关注

本章可以帮助你了解为什么某些设计原则和约定是适用的，然后帮助你决定什么时候应该应用它们。

（2）What ?（重点）

• Modularity
• Interfaces
• Information hiding
• Incremental development 增量开发
• Abstraction
• Generality 普遍性

（3）Component independence （重点）【模块独立性】

Why component independence?

⚫耦合类型（重点）

• Content coupling 内容耦合

一个模块直接使用或者修改另一个模块内部的数据，或者通过非正常的入口，直接进入另一个模块的内部。比如在某个组件的分支操作，直接进入到了另一个组件之中（one component branches into the middle of another component）。

• Common coupling 公共耦合

几个模块对一个公共的数据区域进行数据上的操作

• Control coupling 控制耦合

一个模块通过传递参数，或者函数的返回值来控制另一个模块的行为

• Stamp coupling 特征/标记耦合

complex data structures are passed between modules

When complex data structures are passed between modules, we say that There is stamp coupling between the modules,

• Data coupling 数据耦合

几个模块共享几个数据的值

if only data value, and not structured data, are passed, then the modules are connected by data coupling .

⚫ 内聚类型（重点）

cohesion：内部元素之间的依赖关系

• Coincidental cohesion

coincidental, is found in a module whose parts are unrelated to one another. In this case, unrelated functions, processes, or data are combined in the same module for reasons of convenience or serendipity.

模块之间毫无关系，相互之间是松散的

• Logical cohesion

logical cohesion if its parts are related only by the logic structure of its code.

举例：if - else

• Temporal cohesion

一个模块完成的许多功能必须在相近的时间点完成，比如系统的初始化，这些功能通过时间因素关联在一起。

in that a module’s data and functions are related only because they are used at the same time in an execution.

• Procedural cohesion

允许在调用前面的构件或操作之后，马上调用后面的构件或操作，即使两者之间没有数据进行传递

When functions are grouped together in a module to encapsulate the order of their execution, we say that the module is procedurally cohesive.

• Communication cohesion

一个模块的所有成分都操作同一数据集或者生成同一数据集

同一个data set

• sequencial cohesion

指一个模块中各个处理元素都密切相关于同一功能且必须顺序执行,前一功能元素的输出就是下一功能元素的输入

• Functional cohesion

where two conditions hold: all elements essential to a single function are contained in one module, and all of that module’s elements are essential to the performance of that function.

这里有两个条件:一个模块中包含对单个函数至关重要的所有元素，而该模块的所有元素对该函数的性能都至关重要。

• informational cohesion

  功能内聚对数据抽象和基于对象的设计的适应性称为信息内聚。

  The adaptation of functional cohesion to data abstraction and object-based design is called informational cohesion.

大题

1、Do the exercise 7 of this chapter ( Fourth Edition P370) For each type of coupling, give an example of two components coupled in that way.

• content coupling

  • 一个模块直接使用或者修改另一个模块内部的数据：组件1读取字符流并且更新组件2内部的数据，该变量跟踪已经读取的行数

    组件2使用此变量计算需要启动新页面的时间。

  • 或者通过非正常的入口，直接进入另一个模块的内部。比如在某个组件的分支操作，直接进入到了另一个组件之中

• common coupling

  • 几个模块对一个公共的数据区域进行数据上的操作

    组件1和2与上面一样，但是行计数器变量位于共享数据空间中。

• control coupling

  • 组件1读取字符流，跟踪读取的行数，每当读取足够的行开始一个新页时，就调用组件2。

• stamp coupling

  • complex data structures are passed between modules

  • 组件1对一个复杂的数据结构执行有效性检查，然后将该结构传递给组件2，组件2根据该结构中的数据执行计算。

• data coupling

  • 几个模块共享几个数据的值

  • 组件1对复杂的数据结构执行有效性检查，然后传递组件2完成计算所需的数据结构的各个元素

Chapter 7 Writing the programs

1、Programming Standards and Procedures

Standard format for comments

Even when writing the code itself, many people are sually involved, and a great deal of coorperation and coordination is required.

2、Programming Guidelines

May companies insist that their code conform to style ,format , content standard and read standards, so that the code and associated standard are clear to everyone who read them.

• 程序的主要层次

  • 控制结构

    控制结构主要指程序的分支结构，展现程序的控制流结构。控制单元可以让代码更易阅读，同时将诸多独立的模块组织成有逻辑联系的程序，还可以在控制结构中加入传递参数的名字或者一定的注释，从而展现各组件之间的耦合性。

  • 算法

    算法有着共同的目标：性能（速度）。同时更高效的算法也能让编写、理解、测试、修改代码的成本降低

  • 数据结构

    使用数据结构来将程序中的数据组织起来，从而让程序尽可能保持简单。

No matter how what language is used, each program component involves At least three major aspects, control structure , algorithm, and data structure.

3、Documentation （重点）

➢ Internal documentation

内部文档经常以注释的方式包含在程序之中，是可以直接写在程序里面的，写法一般有固定的格式。

internal documentation is descriptive material written within the code,
$$
内部文档包含内容：\begin{cases}
标题注释块 Head block comment\begin{cases}

组件的名称\
组件的编写者\
组件在一般系统设计中的位置\
编写和修订组件的时间\
组件的功能和作用\
组件是如何使用其数据结构、算法和控制流程的\
\end{cases}\

有意义的变量名和语句标签\

其他程序注释\

\end{cases}
$$
➢ External documentation

The program documentation to be the set of written descriptions that explain to a reader what the programs to and how they do it. internal documentation is descriptive material written within the code, all other documentation is external documentation.

The external documentation is the full blown report, it answers the same questions who, what , why , when , where , how , and using a system rather than a component perspective。

大题

1、Briefly describe the content of Head Block Comment.

• what your component is called
• who wrote the component
• where is the conponent fits in general system design
• when the conponent is written or revised
• why the conponet exsits
• how the conponent uses its data structures, algorithms, and control structure

Chapter 8 Testing the Program

1、Software faults and failures

（1）Types of faults

A fault occurs when a human makes mistakes , called an error, in performing some software behavior. Thus a fault is an inside view of system, as seen by the eyes of the developer .

A failure is a departure for the system’s required behavior. Thus a failure is an outside view: a problem that the user sees.

• Algorithmic fault

  An algorithm fault occurs when a component’s algorithm or logic does not produce the proper output for a given input.

  语法错误也属于算法错误

• Computation and precision fault 计算和精度错误

  a formula’s implementation is wrong

  Computation and precision faults occur when a formula’s implementation Wrong or dose not compute the result to the required number of decimal places.

  当一个公式的实现是错误的或没有计算到小数点后所需的位数。

• Documentation fault

  Documentation doesn’t match what program does

  When the documentation does not match what the program actually Dose, we say that the program has documentation .

• Capacity or boundary faults

  System’s performance not acceptable when certain limits are reached。

  Stress or overload fault occur when the data structures are filled past their Specified capacity .

  当数据达到一定大小超出容量限制时，系统无法接受而报错。

• Timing or coordination faults

• Performance faults

  System does not perform at the speed prescribed

• Standard and procedure faults

并不是所有错误都能够复现的。

Fault identification is the process of determining what the fault or faults Caused the failure, and fault correction or removal is the process of making changing to the system so that the faults are removed.

2、Testing issues

（1）Test opinions

（2）Test organization ——testing steps

• Module testing,component testing, or unit testing

  each program component is tested on its own, isolated from the other components in the system.

• Integration testing 集成测试

  将所有组件组装成一个整体进行测试

  Integration testing is the process of verifying that the system components work together as described in the system and program design specifications.

  集成测试是验证系统组件按照系统和程序设计规范中所描述的协同工作的过程。

A installation test is run to make sure that the system still functions as it should.

• System testing

  包括：function test, performance test, acceptance test, and installation test

  function test

  A function test evaluates the system to determine if the functions described by the requirements specification are actually performed by the integrated system.

  按照系统的功能需求进行测试

  performance test

  A performance test compares the system with the remainder of these software and hardware requirements.

  测试除功能外其他的项目，如速度、精度等

  acceptance test

  A acceptance test checks against the customer’s requirement description, and This test complete jointly with the customer.

  让顾客针对具体软件确认自己的需求

  installation test

  在用户的计算机环境下进行安装测试

（3） Testing techniques

• Black box

定义：已知产品应该具有的功能，通过测试检验 其每个功能是否都能够正常使用。又称功能测试

用途：把程序看成一个黑盒子，仅仅考虑输入和输出的对应关系和程序接口，完全不考虑它的内部结构和处理过程。一般用于综合测试、系统测试等

We view the test object form the outside as a closed or black box whose contents are unknown, our test feed inputs to the closed box and notes what output is produced.

• White box

已知产品内部的工作过程，通过测试检验产品内部动作 是否都能按照需求定义的规定正常使用。用途必须完全了解程序的内部结构和处理过程，才能按照程序内部的逻辑测试，以检验程序中每条路径是否正确， 因此 一般用于规模较小的程序和单元测试

We view the test object as an open box and or white box, we can see the structure of the test object to test in different way.
$$测试技术\{\begin{array}{l}黑盒测试：只考虑输入和输出对应关系和程序接口，不考虑内容\{\begin{array}{l}划分等价类equivalenceclasspartitioning\\ 边界测试boundarytest\end{array}\\ 白盒测试\{\begin{array}{l}语句覆盖statementcoverage：每个语句至少执行一次\\ 条件覆盖conditioncoverage：每个判断的真假至少执行一次\\ 边界覆盖boundarycoverage：每个组件的边界条件进行测试\end{array}\\ 穷举测试\end{array}$$

• 穷举测试 exhaustive test

列举出程序的所有情况，对于黑盒来说对所有输入的可能值进行测试，对于白盒来说，使测试的覆盖率达到百分之百，即每条路径的每条可能都执行一次。

需要指出的是穷举测试是不可能的，这只是一个理性情况而已。

3、Unit testing （重点）

A test point or test case is a particular choice of input data to be used in Test a program.

（1）Examining the code （代码审查）

⚫ Code walkthroughs

程序员向评审小组提交代码及其相关文档，然后评议小组评论其正确性。

⚫ Code inspections

与走查类似但是更正式。按照一个事先准备好的问题清单来检查代码和文档。

（2）Success of the code reviews

（3）Test thoroughness

大题必考考点********

Logic flow (*)

这个的解法很简单，就是找到所有可能走完的路径就行了。

statement

4、Integration testing（重点）

（1）Bottom-up integration

自底向上增加新模块

先测试软件最底部的各个独立组件再向上测试集成的组件。测试每一个集成的组件都要连带其下所属的底层组件一并测试一遍，即将他们看作一个整体进行测试。

需要注意的是这种测试需要为编写驱动（driver components）

In bottom-up integration test, we should develop a component driver to passes a test case to the component to be tested

（2）Top-down integration

测试主控模块，由桩模块代替所有直属模块

利用广度优先遍历或深度优先遍历，从根节点开始向下遍历，遍历结点的顺序就是测试的顺序。

In Top-down integration test, we write a component to simulate the activity of the missing component.

根据所设计的组合策略增加一个模块，设计新的桩模块

• 深度优先 - 先组装在软件结构的一条主控通路上的所有模块。
• 宽度优先 - 沿软件结构水平地移动，把处于同一个控制层次上的所有模块组装起来。

（3） Big-bang integration

类似于黑盒测试，直接将所有组件组装成一个整体，对整个系统进行测试。

（4）Sandwich integration

目标层（中间层）的选择问题

混合使用自底向上和自顶向下的测试方式，先采用自顶向下测试单个组件，再利用自底向上将已测试的单个组件组装成一个整体测试。

（5）Comparison of the strategies

大题

1、If we wanted to test a positive input value, given the properly test case.

• 一个很大的正整数
• 一个正整数
• 一个正浮点数
• 一个大于0小于1的数
• 0
• 负数
• 非负的字符

3、逻辑流

• statement testing：所给的test case要覆盖所有的语句，判断语句或者执行语句
• branche testing：若干次的branch的并集是整个集合
• test path：所有的路

Chapter 9 Testing the system

1、Principles of system testing（重点）

（1）Sources of software faults

（2）System testing process

（3）Configuration management

A system configuration is a collection of system components delivered to a particular customer.

系统配置是交付给特定用户的系统组件的集合

⚫ Versions and releases

​ 版本和发行

⚫ Regression testing

​ 回归测试

⚫ Deltas, separate files, and conditional compilation

​ 细节，分离的文档，条件编译

⚫ Change control

​ 变化控制

（4） Test team

• Professional testers
• Analysts
• System designer
• Configuration management specialists
• user

2、Function Test

​ Cause-and-effect graphs

3、Performance testing

（1）Purpose and roles

（2）Types of performance testing

• 压力测试 stress test

  不在常规条件下运行软件，而是在计算机数量较少或系统资源匮乏下测试软件的性能，通常测试的资源包括内部内存、CPU可用性、磁盘空间、网络带宽

• 容量测试 Volumne test

  产生大量测试数据来测试软件某项指标的极限值，在给定时间内能够处理的最大负载量，从而让开发商和用户了解该软件系统的承受能力或提供服务能力。

• 配置测试 configuration tes

  对电脑硬件的测试，通过对被测系统的软硬件环境进行调整，了解各种不同环境对系统性能的影响程度，进而找到系统各项资源的最优分配原则。

• 兼容性测试 compatibility test

  检查软件之间能否相互正确地交流共享信息。测试内容主要为不同软件版本的兼容性；不同操作系统下软件的兼容性；新旧数据之间的兼容性等。

• 回归测试 regression test

  回归测试是用于软件新版本的一种测试，在修改了旧代码后，重新对相同的功能进行测试，以确认修改没有引入新的错误或导致其他代码产生错误。

  由于在正常情况下，对旧代码的修改往往会引入新的错误，因此回归测试的很必要的

4、Reliability, availability, and maintainability （重点）

（1）Definition

• reliability

The software reliability is a possibility of the system will operate without the failure under a given conditions and time a given interval.

软件可靠性是指系统在给定条件和时间间隔内不发生故障运行的可能性。

Mean Time To Failure衡量：

R = MTTF/(1+MTTF)

• availability

The software availability is the probability that a system is operating successfully according to specification at a given point of time.

软件可用性是指系统在给定的时间点按照规范成功运行的概率。

Mean Time between Faulure:MTBF

A = MTBF(1+MTBF)

• maintainability

The software maintainability is the probability that , for a given condition of use, a maintenance activity can be carried out within stated time and using stated procedure and resources .

软件可维护性是指在给定的使用条件下，维护活动能够在规定的时间内使用规定的程序和资源进行的概率。

Mean Time to Repair：MTTR

M = 1/(1+MTTR)

（2）Measurement

• reliability

MTTF

• avalibility

MTBF

• maintainbility

MTTR

The test in develop environment is called alpha test, and in customer’s environment is called beta test.

5、Acceptance testing

（1）Purpose and roles

（2）Types of acceptance tests

• 基准测试 benchmark test

  由实际的用户或测试系统功能的专门小组进行测试

• 试点测试 pilot test

  在特定的实验环境下安装测试

• α测试 Alpha test

  在小范围的用户内部测试，相当于内测（in-house）

• β测试 Beta test

  开发组发布软件，要求用户运行并提交反馈意见，即公测（out-house）

• 并行测试 parallel test

  新旧版本系统并行运行测试

6、Installation testing

一般而言如果进行了验收测试就不需要进行安装测试了。如果在验收测试时测试环境和用户环境有较大差距，那么安装测试是有必要的。

7、Test documentation

➢ Test plan – test specification and evaluation

– test description

— test analysis report

Chapter 11 Maintaining the System

1、What is maintaining

➢ Any work done to change the system after it is in operation is considered to be maintenance.

1. The S-systems are formally defined by and derivable from a specification.

   s系统由规范正式定义并可从规范派生。

2. The P-system are very abstract, and implementation is almost impractical and Impossible.

2、Four types of maintenance activities （重点）

• Corrective maintenance 改正性维护

  To control the day-to-day system functions, we on the maintenance team respond to problems from faults. This kind of maintenance is called corrective maintenance .

• Adaptive maintenance 适应性维护

  maintaining control over system modifications

  Suppose the existing database management system is upgrade to a new version, this maintenance is called adptive maintenance.

• Perfective maintenance 完善性维护

  perfecting existing functions

  If the customer wanted to add a new function, this kind of maintenance Is called perfective maintenance.

• Preventive maintenance 预防性维护

  preventing system performance from degrading to unacceptable levels

  防止系统性能下降到不可接受的水平

大题

1、List the factors affecting the maintenance cost.

• application type
• system novelty
• turn over and maintenance staff availability
• system life span
• dependence on a changing environment