CPT203软件工程个人复习笔记part2

前情提要：part2内容为software design 和 testing，以及project management。因为是由两个不同教师上的所以重点内容相较part1会少一点，不过不确定是否考点=重点。

Lecture8：Design concept

Design in the SE context

软件设计包括了 • principles • concepts • practices 原理 概念 实践

目标是：

• Firmness (no bugs) 坚固

• Commodity (useful or valuable) 商品化

• Delight (pleasurable experience) 易用

是建模活动中的最后一步，为代码构造和测试奠定基础

主要为四种设计：

Component-level design

Interface design

Architectural design

Database design

质量控制 Quality control in the design process

design的重要性可以用一个词描述：quality

一个设计质量好的三个表现

1、实现了所有显性需求explicit requirements和隐性需求implicit requirements

2、对于实现代码以及测试维护的人员来说是可读可理解的指南

3、设计应提供软件的完整画面，从实现的角度解决数据、功能和行为领域的问题

评估设计质量的八个标准

1、设计应为由良好组件组成的，可以渐进实现的，并以可识别的架构风格构造的架构

2、设计应为模块化的

3、应包含数据、架构、组件、接口的不同表示

4、设计应该产生适合要实现的类的数据结构，并从可识别的数据模式中提取。

5、设计应该导致组件表现出独立的功能特性。

6、设计应提供能够降低组件之间以及与外部环境连接的复杂性的接口

7、应使用由软件需求分析期间获得的信息驱动的可重复方法导出设计。

8、设计应该使用能够有效传达其含义的符号来表示。

五个质量属性

Functionality 功能性 通过评估程序的功能，功能的通用性和安全性来评估

Usability 可用性 通过考虑人为因素、整体美观、一致性和文档来评估

Reliability 可靠性 通过测量故障的频率和严重性、输出结果的准确性、平均故障时间(MTTF)、从故障中恢复的能力以及程序的预测能力来评估

Performance 表现性能 通过处理速度、响应时间、资源消耗、吞吐量和效率来评估

Supportability 支持性 是可扩展性、适应性和可服务性的结合，也可理解为可维护性

什么是Design concept

是软件设计背后的思想/原则，软件组件及质量定义的标准

⭐一般设计概念⭐

• Abstraction 抽象

• Modularity模块化

• Functional Independence功能独立

• Coupling耦合

• Cohesion内聚

• Object-oriented design面向对象的设计

抽象 Abstraction

意味着隐藏细节以降低复杂性并提高效率或质量。级别越高细节越少

procedural abstraction 程序抽象，指指令名字暗示功能，但具体实现过程被省略

data abstractions 数据抽象是描述数据对象的命名数据集合

模块化 Modularity

将相似功能的内容集合在一起，设置边界并提供接口。从而提高制作效率，因为在模块化下不同部件开发可以彼此独立。

但是模块化分的过细会加大组合的难度，应控制好模块数量

功能独立 Functional independence

指开发模块功能专一single-mind且厌恶aversion与其他模块过多交互

两个标准进行评估：

• Coupling耦合

• Cohesion内聚

Coupling 耦合

耦合性是指软件模块之间的相互依赖interdependence程度，分为松散loose耦合和紧tight耦合为了单独解决和修改模块，模块最好是松散耦合的。例子：此时改为author.getSkypeID就可以降低耦合性，skypeID改名不会影响Editor内容。

Cohesion 内聚

另一种方法降低耦合性——加强同一类中属性的联系，即提高内聚性。当一个类做的事越多越杂时内聚性越低。解决方案：尝试修改成一个类只实现一个概念而不是多个概念。

面向对象的设计 Object-oriented design

面向对象的系统由交互的对象组成，这些对象维护自己的本地状态并提供对该状态的操作。

要开发面向对象设计时要做到：

• 了解并定义环境以及与系统的外部交互。

• 设计系统架构。

• 确定系统中的主要对象。

• 开发设计模型

• 指定接口

设计模型中的元素 Elements in design model

五种元素：

• Data design elements

创建以高级抽象级别（客户/用户的数据视图）表示的数据和/或信息模型，然后将其细化为可以由基于计算机的系统处理的逐步更加特定于实现的表示形式。

• Architectural Design Elements

架构设计元素为我们提供了软件的整体视图。

三个来源：有关要构建的软件的应用领域的信息；特定的需求模型元素，例如用例或分析类、它们之间的关系以及针对当前问题的协作；架构风格和架构的可用性。

• Interface Design Elements

类似于一套房屋的门、窗和外部设施的详细图纸

描述了信息流入和流出系统以及信息如何在定义为体系结构一部分的组件之间进行通信

三个重要元素：用户界面（UI）；外部接口；内部接口

• Component-Level Design Elements

相当于房屋中每个房间的一组详细图纸

充分描述每个软件组件的内部细节

在面向对象的软件工程中，组件以UML 图表形式表示。

• Deployment-Level Design Elements

部署级设计元素指示如何在支持软件的物理计算环境中分配软件功能和子系统

Lecture 9 Architecture, Component-level, and  Interface

Architecture Design

架构设计涉及理解系统应该如何组织并设计该系统的整体结构，是软件设计的第一阶段，输出是软件架构的描述

架构设计分为两个抽象层级，一个是单个程序的架构，即如何分解为组件；一个是涉及复杂企业系统的总体架构，其中包含其它系统、程序和组件。

软件架构影响性能、稳健性、可分发性和可维护性，其中单个组件实现功能需求，系统架构实现非功能需求。

显式架构的优点

Stakeholder communication 可作为利益相关者的交流点

System analysis 可分析系统是否满足非功能需求

Large-scale reuse 架构可以在一系列系统中复用

架构视图

logical view 将系统中的关键抽象显示为对象或对象类

process view 显示运行时系统如何由交互进程组成

development view 显示软件如何分解以进行开发

physical view 显示系统硬件以及软件组件如何分布在系统中的处理器上

⭐架构模式 Architecture pattern⭐

架构模式是良好设计实践的程式化描述，已经在不同的环境中进行了尝试和测试。模式应包括有关何时有用以及何时无用的信息。模式可以使用表格和图形描述来表示。

Model-View-Controller (MVC pattern)

是许多web-based系统的基础

包括三个主要的互连组件：

模型：模式的核心组件，直接管理应用程序的数据、逻辑和规则

视图：可以是任何信息的输出表示形式，例如图表或图表。

控制器：接受输入并将其转换为模型或视图的命令，实现视图和模型之间的互连

优点：data可以独立更改，同一data可以不同模式表现

缺点：在数据模型和交互简单时会加大代码复杂度

Layered Pattern

系统功能被组织成单独的层，每个层只依赖紧接其下的层the layer immediately beneath it提供的设施和服务。

这种分层方法支持增量开发，但在高性能应用程序中表现不佳，因为通过多个层来满足业务请求的效率不高。 对于预算和时间都非常紧张的情况来说，这是一个不错的选择。

优点：在维护时可以完全替换一层的内容

缺点：实际工作时很难把层分的很清楚，会有高层跳过中间层直接访问底层的需求，且一层层访问效率低。

Repository pattern

这三个课件都没详细说明，有空再细化。

Client-Server pattern

Pipe and filter pattern

Component-level Design

在第一次架构设计结束后发生

组件级设计定义了分配给每个软件组件的数据结构、算法、接口特性和通信机制，可以使用一些可以转换为源代码的中间表示来表示

Software Component软件组件是计算机软件的模块化构建块。其应可与其他模块检查正确性和一致性，同时可用于访问数据结构、接口和算法是否有效。

三种不同的视图

• 面向对象的视图侧重于将系统建模为一组交互对象，每个对象都封装与在线购物相关的数据和行为。

• 传统视图将系统构建为一系列执行特定任务（例如添加产品、下订单和处理付款）的过程或功能。

• 流程视图根据系统的运行时行为来查看系统，特别是它如何处理订单和付款流以及管理并发和系统资源。

面向对象视图Object-Oriented View

以对象为中心，将其作为软件的基本构建块。 对象封装了数据和行为，表示实体或概念。

关键概念：包括封装、继承、多态性和抽象。 类定义对象的结构和行为。

优点：促进可重用性、模块化和可维护性。 它对于现实世界建模有益的复杂系统特别有效。

用途：广泛应用于现代软件开发，特别是需要大量数据操作和复杂交互的应用程序。

传统视图（结构化或程序视图）conventional view

强调自上而下的软件设计方法，重点关注功能或过程以及它们之间的数据流。

关键概念：软件被构造成执行特定任务的功能或过程。 它依赖于编程结构中的顺序、选择和迭代。

优点：简单明了，对于线性和不太复杂的应用特别有效。 对于小型项目来说更容易遵循。

用途：在软件开发历史的早期阶段更为普遍，适合具有明确操作顺序的应用程序，例如批处理。

流程视图 process view

关注软件组件的运行时行为。 它着眼于组件在执行过程中如何运行，特别是在进程和线程方面。

关键概念：包括进程管理、进程间通信、并发、同步和资源管理。

优点：对于了解系统性能、可扩展性和可靠性至关重要。 对于实时处理、并发性和资源管理是关键问题的系统至关重要。

用途：与复杂、分布式或实时系统相关，其中了解动态行为对于系统性能和可靠性至关重要。

User Interface Design

用户界面设计在人与计算机之间创建了有效的通信媒介。

The golden rules 黄金法则

1. Place the user in control 让用户掌控

定义灵活的交互模式，不强迫用户进行不必要操作并给用户选择

允许用户行为可中断interrupt并保存已做操作

允许用户操作可逆即可撤销Undo

设计界面应可以与屏幕出现物体直接交互

系统状态可见，当用户了解正在发生的事情状态时会更宽容（类似进度条）

2. Reduce the User’s Memory Load 减少用户的内存负载

界面设计应减少对过去操作的记录

设置符合大多数用户的默认值或使用智能默认设置（地理位置自动计算等）

需要用户主观操作的减少默认值（接受使用条款等）

界面的视觉效果应基于现实的隐喻

3. Make the interface consistent. 使界面一致

所有视觉信息应以特定的规则进行组织（每个页面排版相近而不是完全不同）

UI的设计是迭代的，可以用螺旋模型表示

UI设计点 UI design issue

响应时间 Response time

两个要点：长度length（47%的使用者希望页面加载在2秒之内，响应时间过长会导致负面情绪的发生）和变异性Variability（与平均响应时间的偏差）

帮助工具 Help facilities

所有功能都应有说明，以说明清单help menu或文档形式出示

错误处理 Error handling

在发生错误时用客户可理解的语言描述错误，永远不要把错误归于用户。

错误信息应包括：1. 用户可理解的问题描述 2. 如何恢复错误的建议 3.提示用户错误可能带来的影响以便于检查

应用可用性 Application accessibility

为残疾人或老人之类的难以使用应用的人进行改良，比如色盲模式

Internationalization

设计应包含所有通用核心功能

UI设计评估：effectiveness，efficiency，satisfaction

Lecture 10 Software testing

Testing Basics

测试的目的是在投入使用前表现程序应做到什么并找出缺陷。测试的内容为人工数据，

两个目标

1.向开发人员和客户证明该软件满足其要求，即验证测试validation testing。对于每个需求都进行一次测试，测试不出错时为成功的测试。

2.发现软件行为不正确、不良或不符合其规范的情况，即缺陷测试defect testing。目的是暴露系统缺陷，测试用例可以故意模糊或使用不常出现的数据，测试出错时为成功的测试——缺陷成功暴露出来了。

Verification and validation (V & V)

testing是V&V的一部分，V&V涉及检查是否符合Specification以及满足用户想要的Functionality。

Verification是检查软件是否符合功能和非功能需求，即是否正确地制作了软件。

Validation是检查软件是否符合用户期望，即是否制作了正确的软件。

Software inspections和Software testing

Software inspections是观察静态系统表现以发现问题（static V&V）在Testing环节多个错误可能互相掩盖，而在Inspection环节可以直接指出来，并且在检查不完整的系统时不用像testing一样开发专用的测试工具。

Software testing是关注产品的练习表现，即执行测试数据时的表现（dynamic V&V）可以检查是否满足客户实际需求，并检查非功能特性（性能，可用性等）

人话来说就是Inspection管从Specification到四个design以及最后实现的软件代码有没有错误，Testing只管最后的软件以及系统原型在运行上有没有问题。

两个是互补的技术，都应在V&V中使用。

测试阶段 Stages of testing

Development testing 在开发期由开发者进行测试

Release testing 在完成后由单独的测试团队进行测试

User testing 客户正式测试的验收测试

Development testing

包含由系统开发人员进行的所有测试，主要为三种defect testing

⭐Unit testing⭐

测试单个程序单元或对象类，侧重于测试对象或方法的功能。

测试的unit可以是单独的方法，包含一些属性和方法的对象类以及定义好组件接口的复合组件

一次完整的测试应该包含：测试所有操作，设置并更改所有属性，测试所有可能状态

Automated test

在允许的情况下Unit testing最好为自动测试（无需人工确定结果），可以使用例如Junit的自动测试框架

分为三部分：

setup part 初始化系统以及测试用例（输入值和期望输出值）

call part 调用测试对象或方法开始测试

assertion part 对比期望输出值和实际输出值并给出结果

选择有效的测试用例

测试是昂贵且费时的，所以要选择有效的测试用例——1.反映组件正确运行 2.揭示组件缺陷

两个测试策略：

Partition testing 把输入输出结果分类，从不同类中分别挑选测试用例，一般一个类中挑选两个边界值以及中间值（1~10就挑1，10和5）

Guideline-based testing 基于常见错误挑选测试用例，在上述分组测试的基础上加上空集，单个值的集合

Component testing

集成多个unit组成复合组件composite component，侧重于测试组件接口是否符合规范。

接口错误 Interface errors

Interface misuse 调用组件调用另一个组件并在使用其接口时发生错误，例如 参数顺序错误

Interface misunderstanding 调用组件嵌入了关于被调用组件的行为的假设，但这些假设是不正确的

Timing errors 被调用组件和调用组件以不同的速度运行并且访问过时的信息

测试的策略与unit testing差不多，选极限范围和空值并且设计能出错的测试

System testing

集成所有component组成system，侧重于测试组件交互

System testing checks that components are compatible, interact correctly and transfer the right data at the right time across their interfaces.

系统测试检查组件是否兼容、交互是否正确以及在正确的时间通过其接口传输正确的数据。

与组件测试有部分重叠，但是不同点在于：1.是所有组件的集成然后测试整个系统 2.不同团队的组件在集成后以单独团队测试，而不是开发人员测试。

可使用用例测试，以sequence diagrams的形式设计测试用例。

测试要求：应测试所有系统功能，在提供用户输入的情况下测试所有输入（正确和错误）来测试所有功能。

Release testing

是测试用于开发环境外部的可发布的系统，确保系统满足需求且使用中不会出错。

与system testing的区别是release重点在于确定满足需求，system重点在于找错。

三种测试方法：

Requirements based testing

每个需求都指定一个测试内容

Scenario testing

指定一个使用场景，并根据场景设计测试内容来进行测试

Performance testing

使用逐渐增多的测试负载来测试系统直到系统表现不能接受

An operational profile：一组测试反映实际系统需要处理的工作是如何混合的（比如一个系统90%交易是A类型5%是B类型其他是CDE类型，那么operational profile就应该设计为绝大多数是A类型）

Stress testing

通过超出系统预期值的要求来进行压力测试

例：一个事务处理系统预期每秒最多处理300个事务，压力测试就以略少于300个事务开始逐渐增加直到出错为止。

压力测试可以测试系统的故障行为，并且暴露平常不会暴露的问题

User testing

三种用户测试：

Alpha testing

用户与开发团队合作在开发人员的站点进行测试

Beta testing

软件发布并允许用户测试并与开发者直接反馈问题

Acceptance testing

客户确定系统是否满足要求并且能部署到用户环境，通常运用于定制系统

Lecture 11 JUnit

JUnit是用于自动化unit testing的一个框架，用于java代码中进行测试。

判决 verdict

三种判决结果：Pass测试结果与预期相同 Fail测试结果与预期不同 Error测试因错误没有正常完成

测试需要能知道为什么失败：

1.测试要有一个准确的名字

2.测试应该有信息说明为什么失败

3.测试应该分为多个小测试而不是一个大测试

⭐Assertion Methods⭐

assertTrue/False(message, condition) 满足条件就ture/false，在false时发出信息

assertSame/NotSame(message, expected, actual)相同就ture/false，在false时发出信息

assertEquals/NotEquals(message, expected, actual)相同就ture/false，在false时发出信息，与same不同点在于只要值相同就行，same必须是同一个来源。

assertArrayEquals(message, expected, actual)相同就ture，在false时发出信息，没提及有没有NotEquals但我觉得应该有。

assertThrows(expectedExceptionClass, executable)前一个是执行时期望发生的错误信息，后一个是执行的方法。出现指定错误就true。在具体的方法前要加上（）→，例如：assertThrows(ArithmeticException.class, () -> calculator.divide(10, 0));

生命周期

测试类前还要加@Test

@DisplayName（“name”）用于给测试结果起名字

@Disable 用于忽略一个测试

@Timeout（value=n，unit=TimeUnit.时间名如NANOSECONDS）或直接写数字，默认为秒。用于测试表现，超过设定时间就error

@RepeatedTest（n）n为几就重复几遍。如果用了这个就不需要@Test了。

Lecture 12 project management

overview

项目管理的原因：受预算和进度的限制，确保项目可以克服限制并给出优质程序

良好的管理不能保证项目成功，但糟糕的管理可能会导致：成本提高，延迟交付，不满足期望。

项目管理的标准

按时交付，保证成本不超预算，结果满足客户期望，维持有良好环境的开发团队

项目管理的挑战

软件产品是无形的 The product is intangible

大型软件项目通常只会做一次，经验带不到下一次项目中

开发流程每个组织不一样

经理责任

Project Planning 规划、评估和安排项目开发，分配人员并监督他们。

Reporting 向客户和软件开发公司的经理报告项目的进展情况。

Risk management 评估可能影响项目的风险，监控这些风险，并在出现问题时采取行动。

People management 为团队选择人员并建立工作方式

Proposal writing 撰写提案以赢得执行某项工作的合同

一个成功的经理的能力

Motivation 可以鼓励员工达到最高能力水平

Organization 塑造或创新流程使初始概念可以实现为产品

Ideas or innovation 鼓励员工发挥创造力的能力，尽管产品受限。

Problem solving 可以诊断和解决技术和组织问题

Managerial identity 对项目负责，让技术人员可以遵循自己的直觉instincts

Influence and team building 可以了解员工发出的语言和非语言信号并采取措施

⭐Risk Management⭐

经理应预测风险并采取措施避免风险

三种风险

Project risks 影响项目进度或资源的风险（如有经验丰富的设计师离职）

Product risks 影响正在开发的软件的质量和性能的风险（如购买的组件无法按预期执行）

Business risks 影响组织开发或采购软件的风险（如对家公司开发新产品）

更多例子：

风险管理的流程

Risk identification

识别可能存在的三种风险

identifying the risks could pose a major threat to the software engineeringprocess, the software being developed, andthedevelopment organization.

识别可能对软件工程过程、正在开发的软件和开发组织构成重大威胁的风险。

风险的例子：Technology，people，organization，tools，requirement，estimation

Risk analysis

评估风险可能和后果

可能性：Very low (<10%), low (10–25%), moderate (25–50%), high(50–75%), or very high (>75%)

Seriousness 严重性：catastrophic（灾难性的，威胁项目存活），serious（严重的，影响项目进度严重延误），tolerable（可忍受的，会延误但是可以接受），insignificant（基本没影响）

Risk planning

通过计划避免风险或最小化影响。

考虑风险发生该采取什么措施，为了遇见问题需要收集什么信息

三类策略：

Avoidance strategies

最小化风险发生的可能性

Minimization strategies

最小化风险产生的影响

Contingency plans

风险发生后如何做

Risk monitoring

定期评估风险和应对风险的计划

经常性重新评估每个风险的可能性和严重性

Managing People

招聘和留住人才的成本高，所以要确保公司获得最佳的投入回报return on its investment

四个关键因素

Consistency一致性，所有人员都应得到一致的对待

Respect尊重，不同人员有不同技能，管理人员应该尊重差异

Inclusion包容，当人感到自己的意见被听取时会做出更大的贡献

Honesty诚实，诚实的了解工作进度哪边快哪边慢

给予员工动力

需要组织工作和工作环境来激励员工，从而使他们贡献最佳能力

可以把员工分为三类：

Task-oriented people任务导向型，他们会被任务所激励

Self-oriented people自我导向型，他们为个人的成功和被认同所激励

Interaction-oriented people 互动导向型，他们受身边的同事的存在和行为所激励

Teamwork

对于大团队来说不可能所有人都做一件事，必然需要分割成多个小组分别完成各自任务。组建一个在技术技能、经验和个性之间取得适当平衡的团队是一项重要的管理任务。在一个有凝聚力的团队中成员认为团队比个人更重要

优点

The group can establish its own quality standards小组可以建立自己的质量标准，这比外部强加的质量标准更容易被接受。

Individuals learn from and support each other 组员互相学习，可以减少被忽略的知识导致的无知。

Knowledge is shared 知识共享，个别小组成员离开后其他人可以接管关键人物不造成太大影响。

Refactoring and continual improvement is encouraged鼓励重构和持续改进，小组成员共同努力提供高质量的结果并解决问题，无论最初创建设计或程序的人是谁。

影响因素

除了项目和组织外，还有三个一般因素

团队里的人

团队组织

技术和管理沟通

团队凝聚力Team Cohesiveness

优秀的经理应该鼓励团队加强凝聚力

方法：

组织社交活动，明确的团建活动，具有包容性，命名团队并建立团队身份和区域

团队人选

团队不能只考虑工程师的技术能力，拥有互补性格的人组成的团队可能会起到更好的作用

即把工作导向，个人导向和互动导向的人合适的放在一个团队

团队交流

团队成员之间和与利益相关者之间良好的交流是很重要的

交流的有效性和效率受以下五种属性影响

Group size 规模越大有效交流效率越低

Group structure 非正式组织informally structured groups的交流效率更高

Group composition 团队构成中相同类型的人太多会引起冲突降低交流效率

The physical work environment 工作环境对交流效率的影响很大

The available communication channels 交流渠道越多效率越高