【软件工程】北邮国际学院大三下期末复习

每周大纲（Live、Rec）

W1

软件工程分层

软件过程（Requirement specification, Development, Validation，Evolution）

软件模型（瀑布，增量式开发，RUP）

Agile敏捷开发

W2

总结W1+case study

Requirement（功能非功能，需求捕获）

W3

epic

Backlog，MoSCoW，prototyping

Analysis, class, association

W4

总结W3

Design（基本概念：abstraction, encapsulation, modularity, coupling, cohesion, refactoring）

Software architecture软件架构

W5

总结W4+case study

Implementation（build, association）

Testing（黑盒，白盒）

W6

总结W5+case study

TDD

W7

Project Management 1 (planning, scheduling, managing people, agile pro management)

Software Development Life Cycle (SDLC)（一堆模型），Software Prototyping

W8

Project Management 2 (Risk management, quality management)

Software quality, CI/CD

W9

Design principle 1 (SRP, OCP, DRY)

继承，关联，健壮，泛型编程

W10

Design principle 2 (DIP, ISP, LSP)

Design program, networking, defensive programming

W11

Design Pattern （一堆模式）

Linux

W12

开源

软件实践

Past exam

基础知识

W1

软件工程分层

– Commitment to quality

– Process: foundation layer

– Methods: technical layer

– Tools: support layer

软件过程：一组引发软件产品生产的活动

Requirement specification软件描述

a complete description of the problem and of the constraints imposed by/on the environment问题和约束的完整描述被这个环境约束的情况下

Result: Requirements specification

Development软件设计和实现  

        -  必须生产符合描述的软件

• Analysis

        analyse requirements to create a conceptual model of the software system

        分析需求以创建软件系统的概念模型

        Result: a set of Analysis Models

• Design

       an implementable model of the software system软件系统的可实现模型

        Result: Detailed Design Documentation

• Implementation

       implementation of all design elements实现所有设计元素

        Result: working software

Validation (Testing/Deployment)软件有效性验证

• Testing测试

Checking that it does what the customer wants确保软件是客户所想要的

Result: Fully tested software

• Deployment部署

Package software ready to install on a computer system/device or deploy to servers

Result: Working software in real environment

Evolution (Maintenance)软件进化

keeping the system operational after delivery to the customer; changing the system in response to changing customer needs.

在交付给客户后，保持系统正常运行;更改系统以响应不断变化的客户需求。

– Corrective: identification and removal of faults. 纠正:识别和排除故障

– Adaptive: modifications needed to achieve interoperability with other systems and platforms. 适应性:为实现与其他系统和平台的互操作性而进行的修改

– Perfective: incorporation of new features, improved performance and other modifications. 完善:加入新功能，改进性能和其他修改

– Preventive: modifications to mitigate possible degradation of usability, maintainability, etc. 预防性:为减少可用性、可维护性等可能退化而进行的修改

软件过程模型：软件过程的简化表示（经典模型）

1. The waterfall model瀑布模型

– Separate and distinct phases独立的和截然不同的阶段

一个阶段一个阶段的完成

优点：

• Easy to monitor the progress易于监控进度

• Documentation is well produced at each stage每个阶段都有良好的文件编制

• Structured approach高度结构化的方法

• Specialised teams can be used at each stage of the lifecycle各阶段有专门的团队

缺点：

• Inflexible不灵活

• Time consuming费时间（出现问题要一路回去）

• Minimises impact of global understanding over the lifecycle of a project.

在项目生命周期中最大限度地减少全球理解的影响（不能全局地理解这个项目）

• Not realistic不现实的

适用条件：

This model is only appropriate when the requirements are well-understood and changes will be fairly limited during the design process.较稳定

这个模型只适用于当需求被很好地理解并且在设计过程中更改将相当有限时

例：aircraft systems, space systems, nuclear power systems

2. Evolutionary development增量式开发

增量式开发的思想是先开发出一个初始的实现，给用户使用并听取用户的使用意见和建议，通过对多个版本的不断修改直到产生一个充分的系统。

• Activities are interleaved活动是交错的

• Rapid feedback快速反馈

• Refining through many versions通过许多版本进行改进

优点：

• Effective有效

• Can meet the immediate needs能满足即时需求

• Specification can be developed incrementally规格可以逐步发展

缺点：

• Lack of process visibility缺乏过程可见性

• Systems are often poorly structured系统的结构通常很差

• Special skills may be required可能需要特殊技能

适用条件：对于商务个人来说更适合

– small or medium-size interactive systems中小型交互系统

– parts of large systems, e.g. the user interface大型系统的部分，例如用户界面

For short-lifetime systems短生命周期系统

Project with multiple features and therefore releases

Examples: Social networking, communication, phone apps

3. RUP (The Rational Unified Process) 统一软件开发过程

• Inception – ends with commitment to go ahead, business case for the project and its feasibility and feature scope identified.

开始-以继续进行的承诺结束，项目的业务案例及其可行性和特征范围的确定。

• Elaboration ends with协作

– Basic architecture of the system in place. 已具备系统的基本架构

– A plan for construction agreed. 商定了施工计划

– All significant risks identified. 已确定的所有重大风险

– Major risks understood enough not to be too worried. 对重大风险有足够的了解，不必过于担心

• Construction (iterative) – ends with beta-release of the system.

构建(迭代)——以系统的beta版本结束。

• Transition – the process of introducing the system to its users.

过渡-将系统介绍给用户的过程。

优点：

– Generic process通用过程

– Separation of phases and workflows阶段和工作流程分离

缺点：

– Overhead营运费用

Agile Software Development敏捷软件开发

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。

传统的问题：

– Usability and User experience is bad可用性和用户体验很差

– Can not meet the schedule不能按时完成

– Too many documents文件太多

Rapid software development快速软件开发

– Rapidly changing business environments. 快速变化的商业环境

– Rapid development and delivery is Critical. 快速开发和交付至关重要

Agile is a set of best practices in software development based on Scrum, Extreme Programming, Crystal Clear, DSDM, Lean and others. 敏捷是一组基于Scrum、极限编程、Crystal Clear、DSDM、Lean等软件开发的最佳实践。

The focus of Agile:

– Focus on the code rather than the analysis/design.代码

– Are based on an iterative approach to software development.迭代

– Are intended to deliver working software quickly and evolve this quickly to meet changing requirements.快速交付

The Agile Manifesto敏捷宣言

Individuals and interactions over processes and tools个体和交互高于过程和工具

Working software over comprehensive documentation工作软件胜过全面的文档

Customer collaboration over contract negotiation客户合作胜过合同谈判

Responding to change over following a plan响应变化而不是遵循计划

敏捷开发团队要求

• Small, co-located, multi-disciplinary team, members are usually working around a table – Easy communication规模小、地点相同、多学科的团队，成员通常围坐在一张桌子旁工作——便于沟通

• Collective code ownership集体代码所有权

• Common vision of system (‘metaphor’) 系统的共同愿景(“隐喻”)

• Sustainable pace and common coding standard可持续的速度和通用的编码标准

敏捷的准则

• Customer involvement

– Closely involved throughout the development

• Incremental delivery

– Customer specifies each increment

• People, not process

– Skills, the own way

• Embrace change

– Expect change

• Maintain simplicity

– Both the system and the process

•客户参与

-全程参与开发

•增量交付

-每个增量由“客户”指定

•人，而不是过程

-技巧性，自有办法

•拥抱变化

-期待改变

•保持简单

-系统和进程

敏捷流程（2周一迭代）

1.Planning规划

• Emphasis on steer, rather than precise prediction.

强调转向，而不是精确的预测

• Release planning发布计划

• Iteration planning迭代计划

• Goal: visible progress. 目标:明显的进步

2.Requirements (user stories) 需求(用户故事)

• User requirements are expressed as user stories. 用户需求表示为用户故事

• These are written on cards and the development team break them down into implementation tasks. 这些都写在卡片上，开发团队将它们分解成执行任务

• The customer chooses the stories for inclusion in the next release, based on their priorities and the schedule estimates.

客户根据他们的优先级和进度估计，选择包含在下一个版本中的故事

3.Design Improvement设计改进

• Emphasis on simple design and refactoring, i.e. improving existing code. 强调简单的设计和重构，即改进现有代码

• Removing duplication删除重复

• Increasing cohesion. 增加凝聚力

• Reducing coupling. 降低耦合

4.Extreme programming、Pair programming极限编程、结对编程

• Perhaps the best-known and most widely used agile method.

• Extreme Programming (XP) takes an ‘extreme’ approach to iterative development:

5.Test Driven Development (TDD)

敏捷的问题：

– It can be difficult to keep the interest of customers who are involved in the process.

很难保持参与过程的客户的兴趣。

– Team members may be unsuited to the intense involvement that characterises agile methods.

团队成员可能不适合敏捷方法所特有的高度参与。

– Prioritising changes can be difficult where there are multiple stakeholders.

在有多个利益相关者的情况下，很难确定变化的优先级。

– Maintaining simplicity requires extra work.

保持简单需要额外的工作。

– Contracts may be a problem as with other approaches to iterative development.

合同可能是一个问题，就像其他迭代开发方法一样。

敏捷要求：

• Experience经验

• Working environment工作环境

• Value thinking价值思考

• Effective and Efficient communication有效的沟通

• Information sharing信息共享

• Tools and Automation工具和自动化

适用条件：

• Small or medium-sized product. 中小型产品。

• Requirement is not clear and/or keep changing. 要求不明确或不断变化

• Rapid delivery. 快速交付

• A clear commitment from the customer to become involved in the development process客户明确承诺参与开发过程

• Not a lot of external rules and regulations that affect the software没有太多影响软件的外部规则和规定

 

W2

定义

Requirement: A requirement is a feature that your system must have in order to satisfy the customer.

需求是您的系统为了满足客户而必须具备的功能。

Stakeholder: Any person or organization who is affected by the system in some way and so who has a legitimate interest

利益相关者:在某种程度上受系统影响的任何个人或组织，因此拥有合法利益

需求的重要性：

The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, & to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.

构建软件系统最困难的部分是精确地决定要构建什么。概念性工作的其他部分没有建立详细的技术需求那么困难，包括所有与人、与机器和与其他软件系统的接口。如果工作的其他部分做错了，就不会对最终的系统造成如此严重的损害。再没有比这更困难的了。

需求分类

• Functional requirements功能需求

Describe what the system should do – Functionality. 描述系统应该做什么——功能。

• Services

• Non-functional requirements非功能性需求

• Constraints: timing constraints, constraints on the development process, standards, etc. 约束:时间约束、开发过程约束、标准约束等。

The requirements document需求文件

• Software Requirements Specification (SRS) 软件需求规范(SRS)

• The official statement of what is required of the system developers.

•系统开发者需求的官方声明。

• It is NOT a design document. As far as possible, it should set out WHAT the system should do, rather than HOW it should do it.

•这不是一份设计文件。它应该尽可能地规定系统应该做什么，而不是系统应该如何做。

Requirements Capture需求捕获

Fact-finding Techniques调查技术

1. Background Reading背景阅读

Learn more about the company and department the system更多地了解公司和部门的系统

2. Interviewing采访面试

3. Observation观察

Developer observes the user using the current system. Provides the developer with a better understanding of the system.

开发人员观察使用当前系统的用户。使开发人员更好地理解系统。

4. Document or Record Sampling文件或记录抽样

5. Questionnaires调查问卷

“The aim of questionnaire design is to pose questions where misinterpretation is not possible and there is no bias”.

“问卷设计的目的是提出不可能产生误解和不存在偏见的问题”。

Requirements in Agile Development敏捷开发中的需求

User Stories: 用户故事（小卡片）

In Agile process, user requirements are expressed as user stories.

在敏捷过程中，用户需求被表示为用户故事。

• The customer chooses the stories for inclusion in the next release based on their priorities and the schedule estimates.客户选择下一步

•客户根据他们的优先级和进度估计选择包含在下一个版本中的故事。

• The development team break them down into implementation tasks. These tasks are the basis of schedule and cost estimates.开发者进行分解

•开发团队将其分解为执行任务。这些任务是进度和成本估算的基础。

Project glossary专案用语

• The aim of the glossary is to define key terms and to resolve synonyms and homonyms.

• You are building a vocabulary that you can use to discuss the system with the stakeholders.

•词汇表的目的是定义关键术语，并解决同义词和同音异义词。

•您正在构建一个词汇表，可以用来和利益相关者讨论系统。

Epics

Large user stories are generally known as epics.大型用户故事通常被称为史诗。

（需要将epic分解成多个stories）

Acceptance Criteria验收标准

Acceptance Criteria is simply a high-level acceptance test that will be true after the agile user story is complete.

验收标准只是一个高层的验收测试，它将在敏捷用户故事完成后生效。

• It is a great way to ensure that a story is understood and to invite negotiation with the team about the business value that we are trying to create.

•这是确保故事被理解并邀请团队就我们试图创造的业务价值进行谈判的好方法。

（根据story做出产品后，制定一系列标准来检验这个产品符不符合预期）

 

W3

Product backlog, which is a prioritised list of the functionality to be developed in a product or service.

产品待办事项：一个将在产品或服务中开发的功能的优先列表。

MoSCoW

A method of prioritisation favoured by the DSDM (dynamic systems development method). DSDM(动态系统开发方法)青睐的一种排序方法。

Good user story

• INVEST

– Independent——独立

– Negotiable——商量的余地

– Valuable——有价值的

– Estimatable——可以估测

– Small——小

– Testable——可测试的

Prototyping原型

Low-fidelity Prototyping：Paper and sketch低保真原型:纸张和草图

Medium-fidelity Prototyping：Limited functionality but clickable areas which presents the interactions and navigation of an application.

中等保真度的原型设计:功能有限，但可点击的区域，用于展示应用程序的交互和导航。

High-fidelity Prototyping：Computer-based interactive representation of the product in its closest resemblance to the final design in terms of details and functionality.

高保真原型设计:在细节和功能方面与最终设计最接近的产品基于计算机的交互表示。

Analysis

Analysis：A method of studying the nature of something or of determining its essential features and their relations.

分析:研究事物本质或确定其基本特征及其关系的方法。

为什么要分析：Focus shifts to developer and system internals and precise understanding of requirements. 重点转移到开发人员和系统内部以及对需求的精确理解。

Conceptual modelling：A conceptual model aims to identify the individual concepts (classes) which exist within a problem domain.

概念模型:概念模型的目的是确定存在于问题领域中的单个概念(类)。

Class

（考试一般都会给你个UML让你去识别这是什么class）

Objects are entities that model some concrete or conceptual entity inside the system.

对象是为系统中的某些具体或概念性实体建模的实体。

– A class is an abstraction of an object.

—类是对象的抽象。

Analysis Class：Analysis classes are conceptual分析类:分析类是概念性的

Entity classes：Used to model information that is long-lived and persistent实体类:用于建模长期存在和持久的信息

Boundary classes：Used to model the interaction.边界类:用于建模交互。（窗口，表格，终端）

Control classes Used to encapsulate control and coordination of the main actions and control flows. 控件类用于封装主要操作和控制流的控制和协调。（getting、setting）

对于上图：Entity classes: Customer, Account, Transaction

                Boundary classes: BankUI

                Control classes: BankControl

一些定义

Attributes are descriptions of a particular data item maintained by each instance of a class.

属性是由类的每个实例维护的特定数据项的描述。

Operations are abstract specifications of a class's behaviour.

操作是类行为的抽象规范。

Relationship关系

-An association is a bidirectional semantic connection between classes.

关联是类之间的双向语义连接。

-Inheritance defines a relationship among classes where one class shares the attribute(s) and/or operation(s) of one or more classes.

继承定义了类之间的关系，其中一个类共享一个或多个类的属性和/或操作。

Analysis steps分析步骤

1. Identify Entity, Boundary and Control classes识别实体、边界和控制类

2. Identify class relationships识别类关系

3. A conceptual class diagram概念性类图

4. Identify attributes for each entity class为每个实体类标识属性

5. Add constraints添加约束

W4

Design

定义：Software design is the process of planning how to solve a problem through software.

软件设计是计划如何通过软件来解决问题的过程。（软件解决方案的蓝图）

A software design contains enough information for a development team to implement the solution. It is the embodiment of the plan

软件设计包含足够的信息供开发团队实现解决方案。它是计划的具体体现

Design transforms the analysis model into a design model that serves as a blueprint for software construction（总结）设计将分析模型转换为作为软件构建蓝图的设计模型

··Role of Design设计的作用

• Design transforms the analysis model into a design model that serves as a blueprint for software construction. 设计将分析模型转换为作为软件构建蓝图的设计模型。

• At this point, consideration needs to be taken for the non-functional requirements e.g– The programming language chosen在这一点上，需要考虑非功能需求，例如:所选择的编程语言

– Operating systems操作系统

– Databases数据库

– User-interfaces用户界面

• During the design phase: break down the overall task. 在设计阶段:分解总体任务。

• Create a ‘skeleton’ of the system that the implementation can easily fit into. 创建系统的“框架”，便于实现。

关于设计一些概念

• Abstraction: data, procedure, control

• Architecture: overall structure of the software

• Patterns: a proven design solution

• Modularity: compartmentalization

• Information hiding: encapsulation

• Functional independence: coupling and cohesion

• Refinement: elaboration of detail for all abstractions

• Refactoring: a reorganization technique that simplifies the design

•抽象:数据、过程、控制

•架构:软件的总体结构

•模式:经过验证的设计解决方案

•模块化:划分

•信息隐藏:封装

•功能独立性:耦合和内聚

•细化:细化所有抽象的细节

•重构:一种简化设计的重组技术

Abstraction抽象类

什么时候用

If (almost) all classes implementing the behavior would have the same code, then you can use an abstract class to implement it.

如果(几乎)所有实现该行为的类都有相同的代码，那么您可以使用一个抽象类来实现它。

Encapsulation封装

Restricting of direct access to some of an object's components

限制对某些对象组件的直接访问

Modularity模块化

• Separate the functionality of a program into independent, interchangeable modules

• Each module contains everything necessary to execute only one aspect of the desired functionality.

•将程序的功能分割成独立的、可互换的模块

•每个模块包含执行所需功能的一个方面所需的一切。

Coupling耦合（不同类之间的元素要减小耦合）

• The number of dependencies between subsystems. 子系统之间依赖关系的数量

• Indicates strengths of interconnections表明互连的强度（一般来说越松越好）

– Tight: relatively dependent. Modifications to one is likely to have impact on others.

– Loose: relatively independent. Modifications to one will have little impact on others.

-紧密:相对依赖。对其中一个的修改可能会对其他的产生影响。

-松散:相对独立。对其中一个的修改对其他的影响不大。

Cohesion凝聚力（在一个类之间要有很高凝聚力）

• The number of dependencies within a subsystem. 一个子系统中依赖的数量。

• A measure of the level of functional integration within a module.

一个模块内功能集成水平的度量。（一般来说越高越好）

– High: objects are related to each other and perform similar tasks.

– Low: unrelated objects.

—高:对象之间相互关联，执行的任务相似。

—低:不相关对象。

Refactoring重构（精简代码）

• First: get the code to work. 首先:让代码工作。

• Second: ensure that the code stays clean. 第二:确保代码保持干净。

– Frequently review/change code, without changing its external behaviour

– Refactoring is intended to improve nonfunctional attributes of the software

-经常检查/更改代码，而不改变其外部行为

-重构的目的是改善软件的非功能性属性

Advantages of Object Oriented Design面向对象设计的优点

• Easier maintenance: 容易维护

• Objects are potentially reusable components: 对象是潜在的可重用组件

• For some systems, there may be an obvious mapping from real world entities to system objects.对于某些系统，可能存在从现实世界实体到系统对象的明显映射。

Design steps设计步骤

1. Based on the conceptual class diagram produced from the Analysis stage. 基于分析阶段产生的概念性类图。

2. Identifying Class Relationships: Associations /Generalisations确定类关系:关联/概括

3. Identify operations确定操作

4. Describing methods描述的方法

5. Captures implementation requirements. 捕获的实现要求。

6. Produce detailed design class diagram. 制作详细的设计类图。

Software architecture软件架构

·定义：Software architecture refers to the set of principal design decisions, the blueprint of a software system软件驾构指的是一组主要的设计决策，即软件系统的蓝图

Architectural models：The architecture is often represented using a simple box and arrow model, or a UML diagram

体系结构模型:体系结构通常使用简单的框和箭头模型或UML图表示

·优点

System analysis更好的找到系统哪里有问题

Large-scale reuse大规模复用，最小化开发成本

Stakeholder communication

·Architectural patterns架构模式

Patterns are a means of representing, sharing and reusing knowledge

模式是一种表示、共享和重用知识的方法

An architectural pattern is a stylized description of good design practice, which has been tried and tested in different environments

架构模式是对良好设计实践的风格化描述，它已经在不同的环境中进行了尝试和测试

·Web-based architectures基于网络的体系结构

Web-based applications are usually structured according to the client-server architecture, potentially organised into multiple tiers

基于web的应用程序通常根据客户端-服务器架构进行结构化，可能组织成多层

·Distributed systems architecture分布式系统体系结构

Distributed systems are designed to overcome this by relying on a variety of techniques

分布式系统通过依赖各种技术来克服这一问题

·Cloud computing 云计算

Cloud computing refers to the delivery of on-demand computing services (software and hardware) typically over the Internet

云计算指的是通常通过互联网提供按需计算服务(软件和硬件)

·RESTful architecture RESTful架构

Representational state transfer (REST) is a software architectural style that defines how to structure Web services, so that textual representations of Web resources can be accessed and manipulated using a uniform and predefined set of stateless operations

具象状态传输(Representational state transfer, REST)是一种软件体系结构样式，它定义了如何构造Web服务，以便能够使用统一的、预定义的无状态操作集访问和操作Web资源的文本表示

(1) Client-server (2) Cacheability 可缓存(3) Uniform interface 统一接口

(4) Statelessness无状态(5) Layered system分层(6) Code-On-Demand按需编码

·Mobile applications architecture移动应用程序架构

Applications developed for mobiles are usually structured using a layered architecture为移动设备开发的应用程序通常使用分层架构来构建

Presentation layer表示层

Business layer业务层

Data layer数据层

W5

Implementation

定义：Mapping Design to code

·实现的目的

- Implement the system in terms of components (source code, scripts, binaries, executables, etc.). 按组件(源代码、脚本、二进制文件、可执行文件等)实现系统。

- The system is implemented as a succession of small, manageable steps.

系统是作为一系列小的、可管理的步骤来实现的。

The components are tested, and then integrated into one or more executables. 组件经过测试，然后集成到一个或多个可执行文件中。

- The system is distributed by mapping executable components onto nodes in the deployment model: 系统是通过将可执行组件映射到部署模型中的节点来分布的:

primarily based on active classes found during design. 主要基于设计过程中发现的活动类。

·Component组件

Physical packaging of model elements, such as design classes. 模型元素的物理打包，比如设计类。

A component traces the design element it implements. 组件跟踪它实现的设计元素。

·Implementation subsystem实现子系统

Implementation subsystems may consist of components, interfaces, and other subsystems. 实现子系统可能由组件、接口和其他子系统组成。

It provides interfaces (exportation of operations). 它提供接口(操作的导出)。

It depends on the “packaging mechanism” of the implementation environment（package、dictionary）它依赖于实现环境的“打包机制”(包、字典)。

·Build构建

The software must be built incrementally in manageable steps so that each step yields small integration or test problems. 软件必须在可管理的步骤中递增地构建，以便每个步骤产生小的集成或测试问题。

The result of each step is called a “build”, which is an executable version of the system, normally a part of the system.每个步骤的结果被称为“构建”，它是系统的可执行版本，通常是系统的一部分。

·Integration Build Plan集成构建计划

An integration build plan describes the sequence of builds required in an iteration.

集成构建计划描述迭代中所需的构建序列。

·

Class definitions类定义

Class diagrams provide the class name, attributes, operations.

类图提供了类名、属性和操作。

Association关联

An association is a bidirectional semantic connection between classes. 关联是类之间的双向语义连接

An association means there is a link between objects. 关联意味着对象之间存在链接。

OO programming languages do NOT provide the concept of association. 面向对象编程语言不提供关联的概念。

References are unidirectional引用是单向

·Unidirectional one-to-one单向一对一（最简单的，一个A只有一个B）

·Unidirectional one-to-many单向一对多（一个A包含多个B）

A associates with many B, B associates with one A.

A和许多B结合，B和一个A结合。

Testing

·什么是测试

To break the system:（找错误）

Systems are often deployed without being completely tested:（不可确定的）

Testing perhaps is the longest process in software development cycle（40%）

打破这个系统:

系统经常在没有经过完全测试的情况下部署:

测试可能是软件开发周期中最长的过程

·目的

Verify the results from the implementation stage by testing each software build.
通过测试每个软件构建来验证实现阶段的结果。

·测试目标

Goal 1: Validation testing验证测试

-To demonstrate that the software meets its requirements: to both developer and customer

-向开发人员和客户证明软件满足其需求

-A successful validation test shows that the system operates as intended.

-成功的验证测试表明，系统运行正常。

Goal 2: Defect testing缺陷测试

-To discover defects发现的缺陷

– Failure: any deviation of the observed behaviour from the specified behaviour

失败:观察到的行为与指定行为的任何偏差

– Error: system is in a state such that further processing will lead to a failure

错误:系统处于进一步处理可能导致失败的状态

– Defect: mechanical cause of an error

缺陷:机械原因造成的错误

-A successful defect test makes the system perform incorrectly and so exposes a defect in the system.

一个成功的缺陷测试会使系统执行不正确，从而暴露系统中的缺陷。

·Testing policies测试策略

Test should be based on a subset of possible test cases.

测试应该基于可能的测试用例的子集。

Testing policies define the approach to be used in selecting system tests.

测试策略定义了选择系统测试时使用的方法。

·Good test 好的测试

– Has a high probability of finding an error发现错误的概率很高

– Is not redundant不是多余的

– Should be “best of breed” 应该是“最好的品种”

– Should be neither too simple nor too complex不要太简单也不要太复杂

·测试过程

- Unit testing (aka Component testing) -> System components单元测试

- System testing -> The whole system.系统测试

- Acceptance testing (aka Alpha testing) ->Customer’s data. 验收测试

·软件测试模型

Test case: specifications of the inputs and the expected outputs, plus statements.

测试用例:输入和预期输出的规范，加上语句。

Test data: inputs. 测试数据:输入。

Outputs can only be predicted by people who understand the system.

输出只能由了解系统的人来预测。

·Test Case Design测试用例设计

Design the test cases设计测试用例

Tests must be conducted systematically. 测试必须系统地进行。

Test cases must be designed using disciplined techniques.

测试用例必须使用训练有素的技术来设计。

·一些测试技术

Black-box testing测试软件需求

只看输入和输出，不管软件内部

Partition testing分区测试

就是把输入数据按各种类进行分类，然后测试

Scenario-based testing基于场景的测试

想象一个实际场景，进行运用测试

Regression testing回归测试

在迭代的时候要为之前的测试进行测试，防止因为更新导致早期的实验有问题

White-box testing测试内部程序逻辑

Goal: to ensure that all statements and conditions have been executed at least once.

目标:确保所有语句和条件至少执行一次。

白盒"法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。"白盒"法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。所以每个独立路径都至少运行过一次。

Basis path testing基础路径测试（用于关键模块）

·一个总的测试步骤（耦合、白盒、黑盒）

-Classes need to be implemented from least coupled to most coupled类需要实现从最小耦合到最大耦合

-At each step, each class should be fully unit tested using WHITE BOX testing. This involves: 在每个步骤中，每个类都应该使用白盒测试进行完整的单元测试

– Building a test harness. 构建测试工具

– Checking that the methods of the class behave as expected (as defined by their operation descriptions). 检查类的方法的行为是否符合预期(根据它们的操作描述定义)

– Checking that the methods are ‘robust’. 检查方法是“稳健的”

-Integration Testing using BLACK BOX Testing.

-使用黑盒测试进行集成测试。

W6

这周看看就好，大作业用

Test Driven Development (TDD) 测试驱动开发

-TDD: write tests prior to write the production code在编写产品代码之前编写测试

-TDD is a simple, short-cycled mechanism. TDD是一种简单、短周期的机制。

-Run all tests against the entire system at all time. 始终运行针对整个系统的所有测试。

JUnit: JUnit is a simple unit-testing framework for supporting TDD

JUnit: JUnit是一个支持TDD的简单单元测试框架

简单来说TDD就是用assert检测

W7

Project Management

Software Projects’ Distinctions软件项目的区别

Software products are intangible and flexible. 软件产品是无形的和灵活的

Software engineering is not recognised as a sane engineering discipline软件工程并不被认为是一门健全的工程学科

Many software projects are 'one-off' projects许多软件项目都是“一次性的”项目

Project planning项目计划

-To make effective management有效管理

-Iterative process迭代过程

-Various different types of plan may be developed可以制定各种不同类型的计划

Activity organisation活动组织

-Activities in a project should be organised to项目中的活动应组织成

– Produce tangible outputs产生有形的产出

– Judge progress判断进展

- Milestones are the recognisable end-points of a process activity

里程碑是流程活动的可识别的终点

- Deliverables are project results delivered to customers

交付物是指交付给客户的项目结果

*Deliverables are usually milestones, but milestones need not be deliverables!

可交付成果通常是里程碑，但里程碑不一定是可交付成果

·Project scheduling项目计划表

定义：Estimate time and resources required to complete activities and organise them into a coherent sequence. 估计完成活动所需的时间和资源，并将其组织成一个连贯的序列。

特点：Complicated他一般是复杂的

过程：

- Split project into separate tasks → estimate time and resources required to complete each task.

-将项目分解成独立的任务→估计完成每个任务所需的时间和资源。

- Organise tasks concurrently → to make optimal use of workforce.

-同时组织任务→充分利用人力资源。

- Minimise task dependencies → to avoid delays caused by one task waiting for another to complete.

-最小化任务依赖→避免因一个任务等待另一个任务完成而造成的延迟。

* Dependent on project managers’ intuition and experience!

-依靠项目经理的直觉和经验!

一般用chart实现scheduling

Monitoring/Reporting监测/报告

Project scheduling and project budgeting is often based on prior project experiences and on various product and process measurements (metrics) collected in the past.

项目进度安排和项目预算通常基于先前的项目经验以及过去收集的各种产品和过程度量(度量)。

·People management factors人员管理因素

- Consistency → Team members should all be treated in a comparable way without favourites or discrimination.

- Respect → Different team members have different skills and these differences should be respected.

- Inclusion → Involve all team members and make sure that people’s views are considered.

- Honesty → You should always be honest about what is going well and what is going badly in a project.

一致性→团队成员应一视同仁，不受偏袒或歧视。

尊重→不同的团队成员有不同的技能，这些差异应该得到尊重。

包容性→让所有团队成员都参与进来，确保大家的意见都得到了考虑。

诚实→你应该始终诚实地面对项目中进展顺利的部分和进展不顺利的部分。

·Agile project management敏捷项目管理

定义

-The standard approach to project management is plan-driven.

项目管理的标准方法是计划驱动的。

-Agile project management requires a different approach, which is adapted to incremental development and the particular strengths of agile methods. (Scrum approcah)

敏捷项目管理需要一种不同的方法，这种方法适合于增量开发和敏捷方法的特殊优势。(Scrum approcah)

Scrum approach benefits敏捷开发优点

-The product is broken down into a set of manageable and understandable chunks. 产品被分解成一组可管理和可理解的块。

-Unstable requirements do not hold up progress.不稳定的需求不会阻碍进度。

-The whole team have visibility of everything and consequently team communication is improved.

整个团队对所有事情都有了可见性，从而提高了团队沟通。

-Customers see on-time delivery of increments and gain feedback on how the product works.

客户看到及时交付的增量，并获得产品如何工作的反馈。

-Trust between customers and developers is established and a positive culture is created in which everyone expects the project to succeed.

建立客户和开发人员之间的信任，建立积极的文化，每个人都希望项目成功。

Software Development Life Cycle (SDLC) 软件开发生命周期(SDLC)

Software Process: A software process is a set of structured activities that leads to the production of the software.

软件过程:软件过程是导致软件生产的一组结构化活动。

SDLC = Start Activities + Development Activities + End Activities

 

What is Software Development Life Cycle (SDLC)?

Software Development Life Cycle is a process软件开发生命周期是一个过程

The process has a start and an end period流程有一个开始阶段和一个结束阶段

The process is aimed to solve business problems该流程旨在解决业务问题

优点

-Software Development Life Cycle (SDLC) is a process used by the software industry to design, develop and test high quality software products.

-The SDLC aims to produce a high-quality software that meets or exceeds customer expectations, reaches completion within times and cost estimates.

-SDLC is a process followed for a software project, within a software organization.

-It consists of a detailed plan describing how to develop, maintain, replace and alter or enhance specific software.

-The life cycle defines a methodology for improving the quality of software and the overall development process.

软件开发生命周期(SDLC)是软件行业用于设计、开发和测试高质量软件产品的过程。

- SDLC的目标是生产高质量的软件，满足或超过客户的期望，在预计的时间和成本内完成。

-SDLC是软件组织内软件项目所遵循的过程。

-它包括一份详细的计划，描述如何开发、维护、替换、修改或增强特定的软件。

-生命周期定义了提高软件质量和整个开发过程的方法。

SDLC Models

Waterfall Model瀑布模型

• Waterfall approach was the first SDLC Model to be used widely in Software Engineering to ensure success of the project.

瀑布方法是在软件工程中被广泛使用以确保项目成功的第一个SDLC模型。

• In "The Waterfall" approach: 在“瀑布”方法中

– The whole process of software development is divided into separate phases.

– In this Waterfall model, typically, the outcome of one phase acts as the input for the next phase sequentially.

– So, you must finish the whole phase/stage before you can move to the next step/s

-软件开发的整个过程分为不同的阶段。

-在瀑布模型中，通常情况下，一个阶段的结果作为下一个阶段的输入。

-所以，你必须完成整个阶段/阶段才能进入下一个步骤/阶段

• This was before agile processes were introduced这是在引入敏捷流程之前

Iterative Model迭代模型

• Iterative process starts with a simple implementation of a subset of the software requirements and iteratively enhances the evolving versions until the full system is implemented.

迭代过程从软件需求的一个子集的简单实现开始，并迭代地增强不断发展的版本，直到实现完整的系统。

• At each iteration, design modifications are made and new functional capabilities are added.

在每次迭代中，进行设计修改，添加新的功能。

• The basic idea behind this method is to develop a system through repeated cycles (iterative) and in smaller portions at a time (incremental).

•该方法背后的基本思想是通过重复周期(迭代)和每次较小的部分(增量)开发一个系统。

Spiral Model螺旋模型

• The spiral model combines螺旋模型结合了

– The idea of iterative development with the systematic, controlled aspects of the waterfall model.

迭代开发的思想与瀑布模型的系统、受控方面相结合。

– This Spiral model is a combination of iterative development process model and sequential linear development model

螺旋模型是迭代开发过程模型和顺序线性开发模型的结合

• The waterfall model with a very high emphasis on risk analysis. 瀑布模型非常强调风险分析。

– It allows incremental releases of the product or incremental refinement through each iteration around the spiral.

它允许产品的增量发布或围绕着螺旋的每次迭代的增量改进。

– This is a hybrid model of iterative and waterfall models

这是迭代模型和瀑布模型的混合模型

• The spiral model has 4 stages: 螺旋模型有4个阶段:

– Identification识别

– Design设计

– Build/Construct构建构造

– Evaluation and Risk Analysis评估和风险分析

V-Model V模型（强调每个阶段进行大量测试）

• The V-model is an SDLC model where execution of processes happens in a sequential manner in a V-shape.

• It is also known as Verification and Validation model.

• The V-Model is an extension of the waterfall model and is based on the association of a testing phase for each corresponding development stage.

• This means that for every single phase in the development cycle, there is a directly associated testing phase.

• This is a highly-disciplined model and the next phase starts only after completion of the previous phase.

V-model是一种SDLC模型，在该模型中，进程的执行以v形的顺序方式发生。

它也被称为验证和验证模型。

V-Model是瀑布模型的扩展，它基于每个相应开发阶段的测试阶段的关联。

这意味着对于开发周期中的每一个阶段，都有一个直接相关的测试阶段。

这是一个高度自律的模型，下一阶段只有在前一阶段完成后才开始。

Big Bang Model大爆炸模型（没有计划，随便干）

• The Big Bang model is an SDLC model where we do not follow any specific process.

• The development just starts with the required money and efforts as the input, and the output is the software developed which may or may not be as per customer requirement.

• The Big Bang Model does not follow a process/procedure and there is a very little planning required.

• Even the customer is not sure about what exactly he wants and the requirements are implemented on the fly without much analysis.

• The Big Bang Model comprises of focusing all the possible resources in the software development and coding, with very little or no planning.

• The requirements are understood and implemented as they come.

• Any changes required may or may not need to revamp the complete software.

• This model is ideal for small projects with one or two developers working together and is also useful for academic or practice projects.

• It is an ideal model for the product where requirements are not well understood and the final release date is not given.

•大爆炸模型是一个SDLC模型，我们不遵循任何特定的过程。

•开发只是以所需的资金和努力作为输入，而输出则是开发的软件，可能会也可能不会按照客户的要求。

•大爆炸模型不遵循一个过程/程序，需要的规划很少。

•甚至客户也不确定他到底想要什么，需求在没有太多分析的情况下被执行。

•大爆炸模型包括集中所有可能的资源在软件开发和编码，很少或没有计划。

•在需求出现时理解并实现它们。

•所需的任何更改可能需要或可能不需要修改完整的软件。

•这个模型非常适合一个或两个开发者一起工作的小型项目，也适用于学术或实践项目。

•对于没有很好理解需求和没有给出最终发布日期的产品，这是一个理想的模型。

优缺点

• Advantages:

– This is a very simple model这是一个非常简单的模型

– Little or no planning required很少或不需要规划

– Easy to manage易于管理

– Very few resources required所需资源极少

– Gives flexibility to developers给开发人员灵活性

– It is a good learning aid for new comers or students.

这是一个很好的学习辅助新来者或学生

• Disadvantages:

– Very High risk and uncertainty. 风险和不确定性非常高。

– Not a good model for complex and object-oriented projects.

对于复杂和面向对象的项目来说不是一个好的模型。

– Poor model for long and ongoing projects.

对于长期和正在进行的项目来说，模型不好。

– Can turn out to be very expensive if requirements are misunderstood.

如果需求被误解，可能会变得非常昂贵。

Agile Model敏捷开发模型

• Agile model is a combination of iterative and incremental process models with focus on process adaptability and customer satisfaction by rapid delivery of working software product.

敏捷模型是迭代和增量过程模型的组合，通过快速交付可工作的软件产品来关注过程适应性和客户满意度。

• Agile Methods break the product into small incremental builds.

敏捷方法将产品分解成小的增量构建。

• These builds are provided in iterations.

这些构建在迭代中提供。

– Each iteration typically lasts from about one to three weeks. 每次持续一到三周。

• Every iteration involves cross functional teams working simultaneously on various areas like −每个迭代都涉及到跨职能团队同时在不同领域工作

– Planning, Requirements Analysis, Design, Coding, Unit Testing and Acceptance Testing. -规划，需求分析，设计，编码，单元测试和验收测试

RAD Model快速应用开发模型

• The RAD (Rapid Application Development) model is based on prototyping and iterative development with no specific planning involved.

快速应用开发(RAD)模型是基于原型和迭代开发，不涉及具体的计划。

• The process of writing the software itself involves the planning required for developing the product.

编写软件本身的过程包括开发产品所需的计划。

• Rapid Application Development focuses on: 快速应用开发关注

– Gathering customer requirements through workshops or focus groups

– Early testing of the prototypes by the customer using iterative concept

– Reuse of the existing prototypes (components)

– Continuous integration and rapid delivery.

-通过研讨会或焦点小组收集客户需求

-客户使用迭代概念对原型进行早期测试

-重用现有的原型(组件)

-持续集成和快速交付。

Software Prototyping

• The Software Prototyping refers to building software application prototypes which displays the functionality of the product under development, but may not actually hold the exact logic of the original software.

软件原型是指构建软件应用程序原型，它显示正在开发的产品的功能，但可能实际上不包含原始软件的确切逻辑。

• Software prototyping is becoming very popular as a software development model:

作为一种软件开发模型，软件原型正在变得非常流行:

• Prototype is a working model of software with some limited functionality.

原型是一种功能有限的软件模型。

• The prototype does not always hold the exact logic used in the actual software application.

原型并不总是持有实际软件应用程序中使用的精确逻辑。

• Prototyping is used to allow the users evaluate developer proposals and try them out before implementation.

原型用于让用户评估开发人员的建议，并在实施前进行试验。

• It also helps understand the requirements which are user specific and may not have been considered by the developer during product design.

它还有助于理解用户特定的需求，可能没有被开发人员考虑在产品设计。

管理风险的过程

第一 -识别风险:识别并分类项目风险、产品风险和业务风险

第二 -风险分析:它发生的可能性有多大，会造成多大的损害?

第三 -规划:为其他选择做好准备，避免造成太大的伤害

第四 -时刻监控风险:监视应该发生在项目的整个生命周期中

W8

Risk Management风险管理

·项目的问题

·风险管理

Risks can be divided into: 风险可分为:

– Project risks : where the schedule or resources available for the project are affected

– Product risks : where the quality or performance of the software produced is affected

– Business risks : where the organisation which is developing or procuring the software is affected

-项目风险:项目的进度或可用资源受到影响

-产品风险:影响所生产软件的质量或性能

-业务风险:开发或采购软件的机构受到影响

·遇见风险的例子

·风险管理过程

Risk Identification 风险识别

Risk Analysis风险分析

Risk Planning风险计划

Risk Monitoring风险监控

·Avoidance Strategies避免风险的策略

·Agile Risk Management敏捷的风险管理

Quality Management质量管理

Quality Management

Agile Quality Management敏捷质量管理

高质量软件定义

Quality Attributes and Trade-offs质量属性和权衡

Visible and Invisible Quality有形和无形的品质

Analysis of Performance分析性能

Software Reliability软件可靠性

Security and Resilience安全性和弹性

Investing in Software Resiliency投资于软件弹性

Software Standard软件标准

Problems with Standards标准的问题

总结

• Software engineering is about human issues as well as coding issues, we have covered some of the human issues here

• Human issues include both management of people writing the code and interaction with people who are customers who require the software system being developed

• An important aspect of management is that software development requires highly skilled workers

• An important aspect of software engineering is that many aspects of quality are not visible to customers, but could have serious consequences if they are not taken into account

• Agile development involves continuous interaction between programmers and customers

• Programmers need to balance meeting customer requirements with specialist knowledge of how easy it is to meet those requirements, and use this to give advice in agreeing on the priority of requirements

•软件工程是关于人的问题以及编码问题，我们已经在这里讨论了一些人的问题

•人的问题包括代码编写人员的管理和与需要开发软件系统的客户的交互

管理的一个重要方面是软件开发需要高技能的工人

•软件工程的一个重要方面是，质量的许多方面对客户来说是不可见的，但如果不考虑这些方面，可能会产生严重的后果

•敏捷开发涉及到程序员和客户之间的持续交互

•程序员需要在满足客户需求和满足这些需求的容易程度方面的专业知识之间取得平衡，并利用这些知识来就需求的优先级达成一致意见

Software Quality

What is High Quality Software? 什么是高质量软件?

Easy to Use e.g. user friendly interface, drag and drop feature

Easy to modify and understand the codes by other developers

It performs the most important functions

易于使用，例如，用户友好的界面，拖放功能

易于修改和理解其他开发人员的代码

它发挥着最重要的功能

Continuous Integration/Continuous Delivery/Deployment (CI/CD)

持续集成/持续交付/部署(CI/CD)

• CI/CD stands for Continuous Integration/Continuous Delivery/Deployment.

CI/CD代表持续集成/持续交付/部署。

• In software engineering, CI/CD or CICD is the combined practices of continuous integration (CI) and (more often) continuous delivery or (less often) continuous deployment (CD).

在软件工程中，CI/CD或CICD是持续集成(CI)和(通常)持续交付或(不经常)持续部署(CD)的组合实践。

• CI/CD bridges the gaps between development and operation activities (systems admin tasks) and teams by enforcing automation in building, testing and deployment of applications.

CI/CD通过在应用程序的构建、测试和部署中实施自动化，在开发和运营活动(系统管理任务)和团队之间架起桥梁。

• CI/CD services compile the incremental code changes made by developers, then link and package them into software deliverables.

CI/CD服务编译开发人员所做的增量代码更改，然后将其链接并打包成可交付的软件。

• Automated tests verify the software functionality, and automated deployment services deliver them to end users.

自动化测试验证软件功能，自动化部署服务将它们交付给最终用户。

• The aim is to increase early error/defect discovery, increase productivity, and provide faster release cycles.

目标是增加早期错误/缺陷发现，提高生产力，并提供更快的发布周期。

• The process contrasts with traditional methods where a collection of software updates were integrated into one large batch before deploying the newer version.

该流程与传统方法形成鲜明对比，传统方法是在部署新版本之前将软件更新的集合集成到一个大批量中。

• Modern-day DevOps practices involve continuous development, continuous testing, continuous integration, continuous deployment and continuous monitoring of software applications throughout its development life cycle.

现代的DevOps实践包括在软件应用的开发生命周期中持续开发、持续测试、持续集成、持续部署和持续监控。

• The CI/CD practice, or CI/CD pipeline, forms the backbone of modern-day DevOps operations.

CI/CD实践，或CI/CD管道，构成了现代DevOps运营的支柱。

• DevOps is a new term which combines Development(Dev) and Operations (Ops) to mean professionals who perform software development and operations (systems administration in the cloud) tasks.

DevOps是一个由开发(Dev)和运营(Ops)组成的新术语，指执行软件开发和运营(云系统管理)任务的专业人员。

• CI/CD can be pictured as a pipeline, where new code is submitted on one end, tested over a series of stages (source, build, test, staging, and production), and then published as production-ready code.

CI/CD可以被描绘成一个管道，新代码在一端提交，在一系列阶段(源代码、构建、测试、登台和生产)进行测试，然后作为产品准备代码发布。

W9

Live

什么是软件工程

Trade Offs 权衡

Apparent and Actual Types 表观类型和实际类型

Inheritance and Hierarchy in Object-Oriented Programming继承和层次

例如，一个物体可以同时是“猫”、“哺乳动物”、“动物”、“食肉动物”、“宠物”—注意最后两个类（食肉动物”和“宠物”）表明它比“宠物”更复杂类的树。

Association, Aggregation and Composition in Object-Oriented Programming关联聚合组合

关联分为聚合和组合

聚合的子类可以独立存在。例如班级为父类，学生为子类

组合的子类不能独立存在。例如房子为父类，房间为子类

Correctness, Robustness and Efficiency in Object-Oriented Programming正确健壮效率

正确性：如果一个程序完成了它被设计为要执行的任务，那么它就是正确的。

健壮性：如果它能够处理非法输入和其他意外输入，那么它是健壮的以一种合理的方式处理的情况。

Generic Programming and Collection Classes in Object-Oriented Programming泛型编程和集合类

泛型编程是指编写可以适用于许多类型的数据的代码。

Rec

·Trade offs（P4）权衡

·Software lifespan, Software scale（P5）软件寿命，软件规模

·Design principles（P7）设计原则

Attention to high quality design and implementation is essential if we are to manage the complexity of modern real world software systems如果我们要管理现代真实世界软件系统的复杂性，就必须注意高质量的设计和实现

We cannot approach software development in the casual way we may have used when we first learnt to program我们不能像刚开始学习编程时那样随意地进行软件开发

We have to think of software systems at a higher level than just code我们必须从比代码更高的层次来考虑软件系统

When we write code, it is not enough that it works correctly, it must also be written in a way that makes it easy to develop further当我们编写代码时，仅仅正确地工作是不够的，还必须以一种便于进一步开发的方式编写代码

·The dangers of poor quality code代码质量差的危险（P8）

·Decomposition: To manage large scale software we have to divide a system into separate parts (“modules”), in a way that means as far as possible each part can be considered on its own. 分解:为了管理大型软件，我们必须将一个系统划分为多个独立的部分(“模块”)，以一种尽可能使每个部分独立考虑的方式。

Reuse: Instead of writing new code for a module to provide some required service, we may make use of existing code.(P16) 重用:我们可以使用现有的代码，而不是为模块编写新代码来提供所需的服务。

·The most basic design principles最基本的设计原则

Classes should be written so the objects they define are things we can have an image of in our minds类的编写应该使它们定义的对象在我们的脑海中有一个映像

The methods in objects should be defined so they represent clear operations on these things应该定义对象中的方法，以便它们表示对这些东西的明确操作

Remember the terms “locality” and “modifiability” 记住术语“局部性”和“可修改性”

Code should be written so that objects can only interact through defined method calls编写的代码应该使对象只能通过定义的方法调用进行交互

·The Client-Contractor model of software（P41）软件的客户-承包商模型

·Obligations and Benefits（P42）义务和利益

·Design by Contract（P44）契约式设计

W10

Six(SOLID) Design Principles六个设计原则（前三个在W9，后三个在W10录播）必考！！

·Single Responsibility Principle (SRP) 单一责任原则W9P46

- Every object in a system should have a single responsibility, and all the object’s services should be focused on carrying out that single responsibility

系统中的每个对象都应该有一个单一的职责，所有对象的服务都应该专注于履行这个单一的职责

- Leads to highly cohesive software这样会引导出现高凝聚力的软件

-“A class should have only one reason to change”

“一个类应该只有一个改变的理由”

·Open-Closed Principle (OCP) 开放闭合原则W9P56

- Software modules (classes, methods, etc) should be“open for extension”  and “closed for modification” 软件模块(类、方法等)应该“对扩展开放”，对修改关闭”。

- We can make a module behave in new and different ways as requirements change or to meet new needs

我们可以让一个模块以新的和不同的方式表现，因为需求改变或满足新的需求

- But we should be able to do this in a way that does not require changing the code of the module但我们应该能够以不需要更改模块代码的方式做到这一点

- Abstraction is the key抽象是关键

·Do not Repeat Yourself principle (DRY) 不要重复自己原则W9P60

The “Don’t Repeat Yourself” (DRY) principle is the “Open-Closed Principle” (OCP) looked at the other way round

“不要重复自己”(DRY)原则是“开闭原则”(OCP)的另一种说法

Designing and writing abstract code is hard, so we often start off writing more specific code

设计和编写抽象代码是很困难的，所以我们通常从编写更具体的代码开始

When we find we are repeating ourselves in code, we should see if we could replace the repeated code by writing and using more abstract code

当我们发现我们在代码中重复自己时，我们应该看看是否可以通过编写和使用更抽象的代码来替换重复的代码

So, generalisation is identifying repeated aspects and from this moving to write more abstract code

因此，概括就是识别重复的方面，并从这一过程中编写更抽象的代码

·Liskov Substitution Principle (LSP) Liskov替代原理W10P37

The Liskov Substitution Principle says that methods should not be overridden in a way that changes assumptions about their behaviour

Liskov替代原则认为，不应该以改变对方法行为的假设的方式重写方法

Subclasses must always be substitutable for the class they extend

子类必须总是可以替换它们所扩展的类

Inheritance should only weaken preconditions and strengthen postconditions

继承只会削弱前提条件，加强后置条件

·Interface-Segregation Principle (ISP) 接口隔离原则W10P14

Clients should not be forced to depend on methods they do not use

不应该强迫客户端依赖于他们不使用的方法

·Dependency Inversion Principle (DIP) 相关性反演原理W10P12

The Dependency Inversion Principle can be stated as:

➢ High-level modules should not depend on low-level modules; instead, both should depend on abstractions高层模块不应依赖低层模块;相反，两者都应该依赖于抽象

➢ Abstractions should not depend on details; instead, details should depend on abstractions抽象不应依赖于细节;相反，细节应该依赖于抽象

Live: Designing Programs

·Designing Programs设计项目

As a general rule, the fewer unrelated things any class has to care about, the more limited any change will need to be, and thus the more resilient your design will be in the face of future changes.一般来说，任何类需要关心的不相关的东西越少，任何更改所需的限制就越少，因此，在面对未来的更改时，您的设计就越有弹性。

·Networking

One of Java's many strengths is the ability to work over a network easily Java的众多优点之一是能够轻松地在网络上工作

Networking involves network programming which consists of a request from the client to the server and a response to the client by the server.网络包括网络编程，包括客户端向服务器发出的请求和服务器对客户端的响应。

·如何启动客户端请求

Step 1: Establish a Connection建立连接

Step 2: Communication沟通

Step 3: Closing the Connection关闭连接

·Defensive Programming

Defensive programming is a form of programming that uses “defensive design” intended to ensure the continuing function of a piece of software under unforeseen circumstances.

防御性编程是一种使用“防御性设计”的编程形式，旨在确保软件在不可预见的情况下继续发挥功能。

Secure programming is the subset of defensive programming that tries to protect against security threats and security vulnerabilities.

安全编程是防御性编程的子集，防御性编程试图防范安全威胁和安全漏洞。

W11

Design Patterns[1] 必考！！

https://blog.csdn.net/A1342772/article/details/91349142?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522165370408016781685386824%2522%252C%2522scm%2522%253A%252220140713.130102334..%2522%257D&request_id=165370408016781685386824&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~all~top_positive~default-2-91349142-null-null.142^v11^pc_search_result_control_group,157^v12^new_style2&utm_term=%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F&spm=1018.2226.3001.4187

·The Decorator Design pattern装饰器设计模式

The Decorator design pattern involves（例如在方法中额外加1）

– A class which implements an interface 实现接口的类

– Inside it a variable of the same interface type whose value is set in the constructor在它内部有一个相同接口类型的变量，其值在构造函数中设置

– Each method from the interface has code which calls the same method with the same arguments on that variable, plus some extra work

接口中的每个方法都有调用相同方法的代码，该方法对该变量使用相同的参数，外加一些额外的工作

·Wrapper design patterns包装设计模式

The Decorator design pattern is an example of a general sort of pattern called a wrapper pattern Decorator设计模式是一种称为包装器模式的通用模式的示例

A wrapper pattern is any pattern where an object (called the inner object) is referred to by a variable inside another object (the outer object), and each method call on the outer object results in a method call on the inner object

包装器模式是由另一个对象(外部对象)内部的变量引用一个对象(称为内部对象)的任何模式，对外部对象的每个方法调用都会导致对内部对象的方法调用

·The Adapter design pattern适配器设计模式

The Adapter design pattern “adapts” an object of one class to fit into an interface when the object is not of a type which implements the interface

当对象不是实现该接口的类型时，适配器设计模式“调整”类的对象以适应接口

It works by “wrapping” the object as an inner object in an outer object which is of a class that does implement the interface

它的工作方式是将对象“包装”为外部对象中的内部对象，外部对象是实现该接口的类的一个对象

·The Observer Pattern观察者模式

The example given earlier of counting the number of calls of the method quack could also be covered by the Observer design pattern

However, to cover it properly, we will start with a different example

The Observer design pattern is intended to cover cases where there is a link between two classes such that an action on an object of one of the classes is “observed” by objects of the other class

Its most common use is to connect objects which store data or perform actions to other objects which deal with “input/output”

Here “input/output” could mean writing data to a file or database, or displaying on a graphical user interface

前面给出的计算方法quack调用次数的示例也可以用Observer设计模式来实现

然而，为了恰当地介绍它，我们将从一个不同的示例开始

观察者设计模式旨在覆盖这样的情况:两个类之间存在链接，其中一个类的对象上的操作被另一个类的对象“观察”

它最常见的用途是将存储数据或执行操作的对象与处理“输入/输出”的其他对象连接起来。

这里的“输入/输出”可能意味着将数据写入文件或数据库，或显示在图形用户界面上

·The Singleton Design Pattern单例设计模式

Another reason for using factory methods is that a constructor must always return a new object, but factory methods can return an existing object instead of a new object.  

使用工厂方法的另一个原因是，构造函数必须总是返回一个新对象，但工厂方法可以返回一个现有对象而不是新对象。

·The Object Pool Design Pattern对象池设计模式

Object Pool (also called Intern), like Singleton, can return an object that was created before

However, instead of one object it keeps a set of objects

It can be used when the objects returned are immutable

与Singleton一样，Object Pool(也称为Intern)可以返回之前创建的对象

但是，它不是保存一个对象，而是保存一组对象

当返回的对象是不可变的时候可以使用

·The Strategy Design Pattern战略设计模式

Suppose we want to call the various operations possible on a List of DogBots. Instead of writing a separate method for each we can generalise by using the idea of a function object, which is an object whose only job is to carry out an action.

假设我们想要调用DogBots列表中可能的各种操作。我们可以使用函数对象的思想进行概括，而不是为每个对象编写单独的方法，函数对象是唯一的工作是执行一个操作的对象。

·The State Design Pattern状态设计模式

The State design pattern is used when we want to change the way we represent a type of object dynamically

当我们想要动态地改变表示对象类型的方式时，就会使用State设计模式

Consider the idea of a set, it is a collection in which each possible element is either in the collection or it is not, there is no concept of elements occurring multiple numbers of times or having a position in the collection.

考虑集合的概念，它是一个集合，其中每个可能的元素要么在集合中，要么不在集合中，不存在元素出现多次或在集合中有位置的概念。

A mutable set is one where elements can be added or removed. Here is an interface type for a mutable set of integers

可变集合是可以添加或删除元素的集合。这是一个可变整数集合的接口类型

·The Bridge Design Pattern桥梁设计模式

This is an example of the Bridge design pattern

这是Bridge设计模式的一个示例

This is where there are two separate “crosscutting” class hierarchies

这里有两个独立的“横切”类层次结构

If there was just one hierarchy, there would need to be two separate classes for ExtendedIntSet, one for where it is implemented using an array of booleans, the other for the other set implementation

如果只有一个层次结构，则需要有两个单独的类用于extendeddintset，一个用于使用布尔值数组实现的类，另一个用于另一个集实现

·The Flyweight Pattern享元模式

The Flyweight design pattern is where objects have an immutable part which can be shared.

在Flyweight设计模式中，对象有一个可以共享的不可变部分。

不直接改代码的原因

• Other code may already make use of class Duck, class Goose, or method process, we cannot change the code for them without having to check whether the change causes that code to stop working properly (OCP)

• If we added code to count the number of calls to the method quack made in the call to the method process, we are making that method do two separate tasks. The QuackCounterwrapper separates out those two separate tasks (SRP)

• If we wanted to count the number of calls to the method quackmade in a call to another method which takes an argument of type Quackable, we can just use the wrapper we already have

(DRY)

• We may not want to pass full access to Goose objects to other code, passing the GooseAdapter object passes only the ability to call the method honk on a Goose object (DIP)

•其他代码可能已经使用了类Duck，类Goose，或者方法进程，我们不能为他们更改代码而不去检查是否会导致代码停止正常工作(OCP)

•如果我们添加代码来计算在调用方法过程中调用quack方法的次数，我们会让该方法执行两个独立的任务。QuackCounterwrapper将这两个独立的任务分离出来(SRP)

•如果我们想计算在调用另一个接受Quackable类型参数的方法时调用Quackable方法的次数，我们可以使用已有的包装器

(DRY)

•我们可能不想把对Goose对象的完全访问权传递给其他代码，传递GooseAdapter对象只传递了在Goose对象上调用方法honk的能力(DIP)

为什么设计模式重要

Design Patterns Represent Experience设计模式代表经验

Design Patterns Structure Code设计模式结构代码

Design Patterns Reduce Dependency设计模式减少依赖

Design Patterns as a Vocabulary作为词汇表的设计模式

Be Cautious with Design Patterns小心设计模式

W12

看看就行，理解，东西太杂

Open Source Software（OSS）开源软件（录播第一个）

免费开源的原因（P3）

OSS Business Strategies 开源软件商业策略（P4）

OSS Development Methodology开源软件开发方法（P5）

Many Eyeballs Tame Complexity 有很多客户也是帮助你们测试的（P7）

Business Risk商业风险（P8）

Software Freedom软件自由（P9）

Copyright版权（P10）Copyleft非盈利版权（P11）

Free Software and Open Source Software自由和开源区别（P12）

Hacker Culture黑客文化（P13）

Core and Community Core and Community（P14）

Open Source Governance开源治理（P15）

The Android Open Source Project (AOSP)People and Roles 安卓开源项目人员和角色（P16）

• Open Source Software (OSS), has developed a long way from the time when it was seen as a few eccentrics putting together code as a hobby • Most standard software development tools are now OSS, and OSS is moving into other areas • The key to its success is that the community of users of the code also provides a community of testers and debuggers • OSS develops rapidly in requirement to need because anyone who wants to improve it can do so • OSS products avoid the risk of control of code that is vital for a business being in another business’s hands • OSS products maintain a single identity because it is in the interests of their users and developers to contribute to one standard product rather than “fork” • OSS products maintain their OSS nature through a use of copyright legislation to enforce free distribution rather than prevent it • Control of the development of OSS products (“governance”) may now be with companies operating on a commercial basis rather than individuals whose motivation is enjoyment of software and/or personal freedom

•开源软件(Open Source Software，简称OSS)，从一开始被看作是几个怪人的业余爱好，到现在已经发展了很长一段时间 •现在大多数标准的软件开发工具都是OSS，而且OSS正在转向其他领域 •它成功的关键在于，代码用户社区也提供了一个测试人员和调试人员社区 •OSS根据需求快速发展，因为任何想要改进它的人都可以这样做 •OSS产品避免了代码控制的风险，而代码控制对于企业在另一个企业手中是至关重要的 •OSS产品保持单一的身份，因为这符合用户和开发者的利益，为一个标准产品做出贡献，而不是“分叉” •OSS产品通过使用版权立法来强制自由分发而不是阻止它来维持其OSS性质 •对OSS产品开发的控制(“治理”)现在可能是在商业基础上运营的公司，而不是动机是享受软件和/或个人自由的个人

Software Best Practice 实践 & Software Development Tools开发工具

Software Craftsmanship and Clean Code

Learning from Mistakes从错误中学习（P4）

Microsoft’s Best Practices微软的最佳实践（P5）

Revision Control System修订控制系统（P6）

Daily Build每日构建（P7）Continuous Integration持续集成（P8）

Version Control and Build tools版本控制和构建工具（P9）

Assert statements断言语句（P10）

Unit testing单元测试（P11）

Bug Database Bug数据库（P12）

War Team and Bug Triage战争小组和Bug分类（P13）

Code reviews and coding guidelines代码审查和编码指南（P14）

Static and dynamic analysis tools静态和动态分析工具（P15）

Debuggers调试器（P16）

9 essential debugging rules 9个必要的调试规则（P17）

Globalisation and Localisation全球化和本地化（P18）

Documentation Generators文档生成器（P19）

“Eat your own dog food”你要用你自己的东西别人才会觉得你的东西好（P20）

Interactive Development Environments交互式的开发环境（P21）

Command line operation v IDE命令行操作v IDE（P22）

• In this section we have given some examples of the vast range of tools that are available to assist in software development • We have also given some examples of best practices in software development • Use of good software tools helps the organisation of software development, it means that tasks that would otherwise be time-consuming are done quickly and in a consistent manner • It is important to understand that the informal approach to tasks such as testing, debugging, documentation, building an executable system, which we use when we first learn to program, leads to complexity which is difficult to manage when we move to the development of large scale software • So moving to a more disciplined use of tools and standards for operation is similar to moving to a more disciplined approach to code structure, as we considered with the design principles and design patterns – it takes effort to adopt the practice, and we have to learn more to do it properly, but it is essential to manage large scale systems • Experts make good use of tools, but can also “hand craft” when necessary • Experts often build their own tools

•在这一节中，我们给出了一些可以帮助软件开发的大量工具的例子 •我们也给出了一些软件开发中最佳实践的例子 •使用好的软件工具可以帮助组织软件开发，这意味着那些本来会耗时的任务可以快速且一致地完成 •重要的是要理解，我们在第一次学习编程时使用的非正式方法，如测试、调试、文档编制、构建可执行系统，导致当我们转向大规模软件开发时难以管理的复杂性 •所以搬到一个更为严格的使用的工具和标准操作类似于搬到一个更严格的方法代码结构,当我们考虑的设计原则和设计模式,这需要努力采用练习,我们必须学习更多的正确,但它对管理大规模系统至关重要 •专家善于利用工具，但必要时也可以“手工制作” •专家通常会制作自己的工具