软件工程-软件工程导论-复习提纲

四川大学-软件工程专业-软件工程导论-whn老师
参考课本：《软件工程 实践者的研究方法 原书第8版 本科教学版》和第9版部分内容
参考ppt：whn老师的课堂ppt
参考提纲：2024年出题老师给的复习提纲
笔者的话：

• 从近几年开始，软件工程导论考试的题目简化为简答题、非标题、应用设计题。简答题基本出自老师的课下作业，基本都是作业原题。应用设计题目，基本类型也有限：1.给出一段材料，根据材料进行设计，画出ER图、类图、活动图、用例图、顺序图等等；2.给出一段代码或者图示，分析其是否出错，违反了什么设计原则并且改正。3.给出一段代码，画出其对应的流图flow graph/流程图flow chart（这两个不一样，注意区分），回答基本路径并给出测试集。
• 公开这份笔者自己制作的复习提纲，是因为回想起整个学期没怎么听过课，复习时找资料时手足无措的迷茫感，以及像文科一样纷繁的知识点让人复习不知从何开始。希望学弟学妹人人如龙，考出自己心仪的成绩。

1: The Nature of Software

1.Software

1. Definition of software

• 计算机软件 = 程序 + 数据结构 + 文档
  • 程序：指令的集合,通过执行这些指令可以满足预期的特征、功能和性能需求
  • 数据结构：使得程序可以合理利用信息
  • 文档：软件描述信息，用来描述程序操作和使用
• 计算机软件的双重作用
  • 产品–作为一个产品，软件扮演着信息交换的角色
  • 产品交付载体–软件提供了我们这个时代最重要的产品：信息

2. Characteristics of Software&3.The difference of software and hardware

• 软件是设计开发出来的一种逻辑的产品，与硬件产品有本质区别
• 软件产品质量的体现方式与硬件不同，软件不会“磨损”
• 软件产品的成本构成与硬件产品的成本构成不同。
• 软件产品的成本构成
  • 人力成本
  • 时间成本
• 硬件产品的成本构成
  • 原材料成本
• 软件产品的失败曲线与硬件产品不同
• 大多数软件是根据顾客需求定制产生，硬件的可复用性比软件强很多

2.The changing nature of software

1. 四类软件不断演变

• webapp
• 移动app
• 云计算
• 产品线软件
  • 将软件产品线定义为“一系列软件密集型系统，可以共享一组公共的可管理的特性，这些特性可以满足特定市场或任务的特定需求，并以预定的方法从一组公共的核心资源开发出来。

2: Software Engineering

1.Software engineering – a layered technology:

1. The definition of Software engineering

• 软件工程即运用系统的、科学的、可量化的方法开发、运行和维护软件，将工程化的方法运用到软件开发中。
• 软件工程 = 计算机科学 + 管理 + 工程

2. The goal of Software engineering

• 各种形式、各个应用领域的软件都需要工程化
• 同1.

3. Layer: tools, methods, process and a quality focus

• 软件工程的根基：质量关注点
  • 任何工程方法(包括软件工程)必须构建在质量承诺的基础
• 软件工程的基础：软件开发过程
  • 软件过程将各个技术层次结合在一起，使得合理、及时地开发计算机软件成为可能。
• 软件工程的核心：软件开发方法
  • 为构建软件提供技术上的解决方法(如何做)。
• 软件工程的关键：软件开发工具
  • 为过程和方法提供自动化或半自动化的支持。
• 软件工程 = 过程 + 方法 + 工具
• 

2.A process framework

过程框架

1. The generic five process activities: communication, planning, modeling, construction and deployment

• 沟通Communication–与客户（及其他利益相关者）的沟通协调。
• 策划Planning–制定软件项目计划书。
• 建模Modeling–绘制项目体系架构，利用模型理解软件需求。
• 构建Construction–编码和测试。
• 部署Deployment–软件交付，用户测评。

3.Software development myths

软件神话

• 一本软件开发标准和规程宝典，可以提供需要了解的所有信息。只要照此宝典，就一定能开发出成功的软件产品吗？
  • 不可以
  • 尽信书不如无书，实践才是检验真理的唯一标准
• 如果我们未能按时完成计划，可以通过增加程序员人数而赶上进度吗？
  • 不可以
  • 只有有计划、有序地增加开发人员，才能对我们地项目开展有意义
• 当我们完成程序并将其交付使用后，我们的任务就完成了吗？
  • 并没有
  • 软件有生命周期，当软件交付给用户之后，将进入软件维护阶段，这是软件任务并没有完成。
• 对于一个成功的软件项目，可执行程序时唯一可交付的工作成果
  • 错误
  • 除了交付可执行程序，还有知道用户正确使用软件的操作手册、维护手册等等这些帮助文档都是工作成果

4.Umbrella activities

普适性活动

1. Software project tracking and control; Risk management; Software quality assurance; Technical reviews; Measurement; SCM; Reusability management; Work product preparation and production;

• 项目跟踪控制Software project tracking and control
  • 项目组根据计划评估项目进度，并且采取必要的措施保证项目按进度计划进行。
• 风险管理Risk management
  • 对可能影响项目成果或者产品质量地风险进行评估。
• 质量保证Software quality assurance
  • 确定和执行软件质量保证的活动。
• 配置管理
  • 管理变更所带来的影响。
• 技术评审Technical reviews
  • 评估软件工程产品，尽量在错误传播到下一个活动之前发现并清除错误。

3: Software Process Structure

1. Prescriptive models

1. The function of process models

• 概念:过程模型为软件工程工作提供了特定的路线图,该路线图规定了所有活动的流程、动作、任务、迭代的程度、工作产品及要完成的工作应如何组织。
• 过程模型的作用是减少开发新软件产品时出现的混乱。

2. Understand the signification and characteristics of the process models

• 重要性:软件过程提高了软件工程活动的稳定性、可控性和有组织性，如果不进行控制，软件活动将变得混乱。但是，现代软件工程方法必须是“灵活”的，也就是要求软件工程活动、控制以及工作产品适合于项目团队和将要开发的产品。

3. Process model, Pattern, Framework

• 过程模型process model
  • 过程模型为软件工程工作提供了特定的路线图,该路线图规定了所有活动的流程、动作、任务、迭代的程度、工作产品及要完成的工作应如何组织。
  • 通用过程模型–软件过程模型的种类：
    • 线性–按顺序执行 5 个活动框架
    • 迭代–每一个或多个活动可以反复迭代执行多次，但每一次迭代的具体任务有所不同
    • 演化–采用循环方式执行 5 个框架活动，但每一次循环都有增量，形成更完善的软件
    • 并行–将一个或多个活动与其他活动并行执行
  • 这些模型的区别在于执行沟通、计划、建模、构建、部署这 5 个框架活动的顺序不同
• 过程模式( process pattern)描述了软件工程工作中遇到的过程相关的问题，明确了问题环境并给出了针对该问题的一种或几种可证明的解决方案，建立层次化的过程描述。通俗地讲，过程模式提供了一个模板——一种在软件过程的背景下统一描述问题解决方案的方法。通过模式组合，软件团队可以解决问题并定义最符合项目需求的开发过程。
• 过程框架（process framework)定义了若干个框架活动(frameworkactivity)，为实现完整的软件工程过程建立了基础。这些活动可广泛应用于所有软件开发项目,无论项目的规模和复杂性如何。此外，过程框架还包含一些适用于整个软件过程的普适性活动(umbrella activity)。一个通用的软件工程过程框架通常包含以下5个活动。communication, planning, modeling, construction and deployment

2. The waterfall model

1. V cycle model

• V 模型是由瀑布模型改进得来的一个变体，它建立了质量保证活动与瀑布模型之间的关系，将早期的软件开发活动与后期的验证和确认活动关联起来。
• 特点：
  • 阶段间具有顺序性和依赖性
    • 任务间的依赖性容易导致”阻塞状态“
  • 推迟实现的观点
  • 质量保证的观点
  • 适用于所有的系统功能需要一次性交付或必须同时淘汰全部老系统的场景
• V 模型有很大的局限性，如下所示：
• 错误假设：需求是固定的
• 错误假设：我们可以在进行构建之前作出正确的设计
• 没有考虑到人为的一些因素
• 直到项目接近尾声时才能得到可执行的程序

2. 适合需求清楚、熟悉的系统

• 对于瀑布模型,描述该模型可以使用和不能使用的情况以及原因。

瀑布模型适用于具有以下特征的项目：

1. 问题已经完全理解（需求明确）。
2. 交付日期现实可行。
3. 项目进行过程中不太可能出现重大需求变更。

由于瀑布模型按照阶段进行分类，只有完成当前阶段才能开始下一个阶段。这会导致修改后期阶段非常复杂，并且各个阶段之间反馈很少。

如果用户明确所有需求，瀑布模型将是一个不错的选择。但如果用户对需求不明确，后期可能需要进行大量修改，瀑布模型可能就不太合适了。

3. Incremental process models（阶段式提交）

1. 适合需求清楚、周期比较短的项目
2. OO-based
3. Why use incremental model?

• 增量模型结合瀑布模型和迭代开发思想，将一个大型复杂软件分解成若干的”增量
• 在增量模型中，软件开发采用迭代的方法，每一次迭代开发过程采用瀑布模型，完成一个增量的开发，生成部分的软件。通过多次的迭代开发，最终生成完整的软件。
• 特点：
  • 每一次迭代开发得到的增量都是一个可运行的软件版本，这提高了软件开发过程的可见性，有利于收集用户反馈意见，改进软件的下一个版本
  • 如果每个增量相对独立，那么整个增量开发过程中就可以适当并行，从而提高开发效率
  • 可以规避风险，用小批量的增量进行尝试，成功以后再在以后的迭代中更大范围地推广经验
  • 采用增量模型的前提是：软件可以分解，因此增量模型被广泛应用于面向对象软件开发方法中

增量模型交付了一系列称为增量的版本，随着每个版本的交付，逐步为用户提供更多的功能。

用户对应用程序没有明确的需求。然后，它要求软件必须被修改(.(增加新功能)很容易。第一个增量是核心产品的基本需求。经过评估形成下一个增量开发计划，它包括核心产品的修改和一些新功能的工艺…
增量模型:以小而可用的部分交付软件，每个部分都建立在已经交付的部分之上

4. Evolutionary process

1. Prototyping

• 特点：
  • 原型开发即，简化软件的实现，只实现软件的部分功能，借用软件工具快速生成一个软件样品，这个样品就是软件原型，然后基于原型与用户进行沟通，确定修改意见，再对原型进行修改和增加功能。通过多次演化开发，最终生成满足用户需求的完整软件。
  • 在每次进化过程中，采用瀑布模型进行开发。

2. 适合需求不清楚的系统
3. Process pattern
4. Spiral Model （风险分析）

• 特点：
  • 螺旋模型是一个风险驱动的过程模型，它结合了原型模型和增量模型的特点，具有快速开发逐渐完善的软件版本的潜力。
  • 螺旋模型在增量模型的每一次迭代过程中增加了风险控制机制，强调风险分析，在保证风险可控的前提下进行迭代开发
  • 在每一次迭代过程中使用瀑布模型，将开发划分为制定计划、风险分析、工程实现、用户评审 4 个阶段
  • 是开发大型软件系统的理想过程，常用来指导大型软件项目的开发

5. Specialized process models

专用过程模型

1. Component based development（需要面向对象技术支持）

• 面向对象技术为基于构件的开发模型提供了技术保证
  • 构件 = 类或类库
• 优点：
  • 有助于软件复用，提高开发效率
  • 采用面向对象技术，使程序具有更好的可维护性
• 缺点：
  • 过分依赖构件，构件库的质量影响着产品质量
    Object-oriented process models

6. Unified process model(5个阶段)

Inception（起始）, Elaboration（细化）, Construction（构建）, Transition（转换），Production（生产）

• 统一过程模型的5个阶段分别是：起始、细化、构建、转换和生产。

• UP的起始阶段（ inception phase)包括客户沟通和策划活动。通过与利益相关者协作定义软件的业务需求,提出系统大致的架构，并制定开发计划以保证项目开发具有迭代和增量的特性。

• 细化阶段（Elaboration Phase)包括沟通和通用过程模型的建榄活动。细化阶段扩展了初始阶段定义的用例，并扩展了体系结构以包括软件的五种视图——用例模型、需求模型、设计模型、实现模型和部署模型。在某些情况下，细化阶段建立

• UP的构建阶段（ construction phase)与通用软件过程中的构建活动相同。构建阶段采用体系结构模型作为输入，开发或是获取软件构件，使得最终用户能够操作用例。

• UP的转换阶段( transition phase)包括通用构建活动的后期阶段以及通用部署(交付和反馈）活动的第一部分。软件被提交给最终用户进行 Beta测试，用户反馈报告缺陷及必要的变更。在转换阶段结束时,软件增量成为可用的发布版本。

• UP的生产阶段（ production phase)与通用过程的部署活动一致。在该阶段，对持续使用的软件进行监控，提供运行环境（基础设施)的支持，提交并评估缺陷报告和变更请求。

• 五个UP阶段并不是顺序进行，而是阶段性地并发进行。

Agile Development

1. What is Agility?

• 敏捷的基本动力：普遍存在的变化
• 它强调可运行软件的快速交付而不那么看重中间产品
• 敏捷开发最具强制性的特点之一就是：能够通过软件过程来降低由变更所引起的代价
• 敏捷开发推崇：
  • 让客户满意
  • 软件尽早增量发布
  • 小而高度自治的开发团队
  • 非正式的方法
  • 最小化的软件工作产品
  • 整体精简开发的原则
• 敏捷开发强调：
  • 超越分析和设计的发布
  • 开发人员和客户之间的主动、持续沟通

2. Agile Process

1. XP 极限编程 (pair programming结对编程)

• 特点：
  • 是敏捷开发中应用最广泛、最富有成效的一种开发过程
  • 是一个轻量级的、可适应的、严谨周密的开发过程
  • 适用于小团队
• 基本思想：
  • 将软件开发任务分解为可以在较短周期内完成的若干子任务，通过一个短的迭代周期获得阶段性进展
  • 强调测试、代码质量和及早发现问题
  • 及时形成一个可用版本，供用户参考，并对用户需求变更作出及时响应
• 极限编程过程：
  • 策划
    • 获取需求，理解软件的应用背景、输入、主要功能
  • 设计
    • 保持简洁原则，使用简单而不是复杂的表示
  • 编码
    • 采用测试驱动的编程方法，即在编码前设计单元测试，编码的目标是：通过单元测试
    • 编码活动中的关键概念是结对编程。XP建议两个人面对同一台计算机共同为一个故事开发代码。这一方案提供了实时解决问题(两个人总比一个人强)和实时质量保证的机制(在代码写出后及时得到复审)，同时也使得开发者能集中精力于手头的问题。
  • 测试
    • 采用可以自动测试的框架，实现编码完成后的即时回归测试，客户的验收测试基于用户故事进行测试

2. Scrum

• Scrum 中的软件开发过程由若干的冲刺sprint组成，每个冲刺将解决一个实际问题。
• 

4: Understanding Requirements

1. A bridge to design and construction

1. The definition of requirements engineering

• 需求工程(Requirement Engineering，RE)是指致力于不断理解需求的大量任务和技术。从软件过程的角度来看，需求工程是一个软件工程动作，开始于沟通并持续到建模活动。它必须适用于过程、项目、产品和人员的需要。
• 需求工程为设计和构造奠定了坚实的基础。如果没有需求工程,那么实现的软件很有可能无法满足客户的需求。

2. seven Requirements engineering tasks

• 软件需求工程的七个阶段：

1. 初启 (Inception)： 建立对问题的基本理解以及解决方案的性质。
2. 导出 (Elicitation)： 从利益相关者那里获取需求。
3. 精化 (Elaboration)： 创建一个分析模型，表示需求的信息、功能和行为方面。
4. 谈判 (Negotiation)： 达成一个对开发人员和客户都现实可行的可交付系统。
5. 规格说明 (Specification)： 正式或非正式地描述需求。
6. 确认 (Validation)： 检查需求规格说明是否存在错误、模糊之处、遗漏和冲突。
7. 需求管理 (Requirements Management)： 管理不断变化的需求。

3. Initialing the requirements engineering process

• 确认利益相关者stakeholder
  • “利益相关者"是间接或直接地从正在开发的系统中获益的人。
• 识别多重观点
  • 因为存在很多不同的利益相关者，所以系统需求调研也将从很多不同的视角开展。
  • 需求工程师的工作就是把所有利益相关者提供的信息（包括不一致或是矛盾的需求)分类
• 协同合作
  • 客户（和其他利益相关者)之间应该团结协作（避免内讧)，并和软件工程人员团结协作，这样才能成功实现预定的系统。
  • 需求工程师的工作是标识公共区域(即所有利益相关者都同意的需求)和矛盾区域(或不一致区域，即某个利益相关者提出的需求和其他利益相关者的需求相矛盾)。
• 首次提问
  • • 问上下文无关context-free的问题
  • ![[Pasted image 20240609163050.png]]

4. Eliciting requirements

• 质量功能部署
  • QFD:质量功能部署（QFD)是一种将客户要求转换为软件技术需求的质量管理技术。QFD的目的是:最大限度地让让客户从软件过程中感到满意。
  • QFD强调理解:什么是对客户有价值的(将需求分为三类:正常需求、期望需求、令人兴奋的需求)，然后，在整个工程活动中部署这些价值。
• 通过开发系统原型获取用户需求
  • 开发原型，使用户能够理解人机交互将如何发生。

5. Developing user-case

• 用例是一个关于软件外部的人或事物（称为参与者）如何与系统交互的故事。
• 用例是从参与者的角度定义的。
• 参与者是人或设备在与软件交互时所扮演的角色。
• 

5: Requirements Modeling

1. Requirements analysis

1. The three goals of analysis modeling（Information/Data, Function, Behavioral )

• 分析模型的作用是为基于计算机的系统提供必要的信息、功能和行为域的说明。
• model data
  • 定义数据对象
  • 描述数据属性
  • 建立数据关系
• model function
  • 识别转换数据对象的函数
  • 说明数据如何在系统中流动
  • 代表数据的生产者和消费者
• model behavioral
  • 指定系统的不同状态
  • 指定导致系统改变状态的事件

2. The concepts of analysis modeling

• 分析模型的作用是为基于计算机的系统提供必要的信息、功能和行为域的说明。随着软件工程师更多地了解将要实现的系统以及其他相关利益者更多地了解他们到底需要什么，模型应能够动态变更。因此，分析模型是任意给定时刻的需求快照，我们对这种变更应有思想准备。

3. Specification and Requirements

• Specification规范
  • 它的主要目标是为客户和制造商之间要签署的协议奠定基础。
  • 它包含系统/软件必须满足的技术要求清单，
  • 并尽可能确保系统/软件的可行性。
• Requirements需求
  • 用户需求描述系统/软件项目必须做什么，而不是如何做。
• 需求指明产品或者系统需要做什么，而规格描述如何搭建系统或者系统如何工作。
• GPT：
• 1. 需求 (Requirement)
  • 定义: 用户对系统功能、性能、约束和限制的描述，反映了用户对系统的期望和目标。
  • 来源: 来自用户的直接表达、市场调研、竞品分析等。
  • 形式: 可以是自然语言描述、用户故事、用例图等。
  • 目标: 理解用户需求，确保系统满足用户期望。
• 2. 规格说明 (Specification)
  • 定义: 对系统功能、行为、数据结构、接口等方面的详细描述，是系统设计的依据。
  • 来源: 基于需求分析，对需求进行细化和量化。
  • 形式: 通常采用正式的语言描述，例如 UML 图、数据模型、代码等。
  • 目标: 明确系统实现细节，指导开发团队进行设计和编码。

4. Customer and End-User

• 1.客户:
  • 最初要求构建软件的人
  • 为软件定义全部业务目标的人
  • 提供基本的产品需求的人
  • 为项目调整资金的人
  • 在产品或者业务系统中，客户通常负责市场;
  • 在IT环境下，客户或许是一个商业单位或部门
• 2.最终用户(End-User):
  • 将一直使用为了达成某种商业目的而编写的软件
  • 定义软件可操作细节以便可以达成其商业目的
  • 实际使用软件的人。
• 客户表达对计算机软件的要求，最终用户应用软件来解决特定的问题或者满足特定的要求。

2. Analysis modeling approaches

• 面向对象分析OOA（用例图、活动图、时序图、状态图、分析类图）
• 结构化分析SA（不考）
  The principles of modeling分析建模的经验准则

1. 关注可见需求： 模型应主要关注在问题或业务领域中可见的需求，避免过早引入技术细节。
2. 增进理解： 模型中的每个元素都应有助于全面理解软件需求，并提供对系统信息领域、功能和行为的洞察。
3. 延迟非功能性设计： 将基础设施和其他非功能性模型的考虑推迟到设计阶段。
4. 最小化耦合： 在整个系统中尽量减少耦合，提高系统模块之间的独立性。
5. 价值导向： 确保分析模型能为所有利益相关者提供价值。
6. 保持简洁： 尽可能保持模型的简单性，避免不必要的复杂性。

3. Data modeling concepts

E-R diagram, relationship of objects
ER图、对象的关系

4. Scenario-based modeling

1. UML

• UML和统一过程是面向对象的分析方法

2. Use-Cases in UML：use-case diagram/ activity diagram/ sequence diagram/state diagram/class diagram

• 用例图、活动图、时序图、状态图、类图

3. OOA: Behavioral, Class, Use-Case

• 

5. Creating a behavioral model

行为模型显示了软件如何对外部事件或激励做出响应。步骤:

1. 评估所有的用例，以保证完全理解系统内的交互顺序;
2. 识别驱动交互顺序的事件，并理解这些事件如何与特定的对象相互关联;
3. 为每个用例生成序列
4. 创建系统状态图;
5. 评审行为模型以验证准确性和一致性。

6.Class-based modeling

• 1.识别分析类

• 

• 简答：在分析模型中，分析师考虑每个潜在类是否应该使用如下这些特征。

  1. 保留信息。只有记录潜在类的信息才能保证系统正常工作，这样潜在类才能在分析过程中发挥作用。
  2. 所需服务。潜在类必须具有一组可确认的操作，这组操作能用某种方式改变类的属性值。
  3. 多个属性。在需求分析过程中，焦点应在于“主”信息;事实上，只有一个属性的类可能在设计中有用，但是在分析活动阶段，最好把它作为另一个类的某个属性。
  4. 公共属性。可以为潜在类定义一组属性，这些属性适用于类的所有实例。
  5. 公共操作。可以为潜在类定义一组操作，这些操作适用于类的所有实例。
  6. 必要需求。在问题空间中出现的外部实体，以及任何系统解决方案运行时所必需的生产或消费信息，几乎都被定义为需求模型中的类。

• 2. 描述属性

• 3. 定义操作

• 4. CRC，类-职责-协作者建模

• 简答：描述CRC(类-责任-合作者)卡的三个部分的角色?

  • 类–系统开发的用例中的名词（外部实体、事务、偶发事件、角色、组织单元、场地、结构）
  • 职责–是和类相关的属性和操作
  • 协作者–是提供完成某个职责所需要信息或动作的类
    协作。类用一种或两种方法来实现其职责:(1)类可以使用其自身的操作控制各自的属性，从而实现特定的职责;(2）类可以和其他类协作。
    

6: Design Concepts

1. Design within the context of software engineering

1. Map the analysis model into design model

• 

由基于场景的元素、基于类的元素和行为元素所表示的需求模型是设计任务的输人。使用设计表示法和设计方法，将得到数据或类的设计、体系结构设计、接口设计和构件设计。

2. Design concepts

abstraction, Refinement ，architecture, patterns, modularity, information hiding, functional independence, refactoring, design class

• 抽象

  • 

  • 许多抽象级

  • 过程抽象是指对软件要执行的动作进行抽象，具有明确和有限功能的指令序列。

  • 数据抽象是描述数据对象的冠名数据集合。

• 求精
  • 逐步求精是一种自顶向下的设计策略
  • 求精实际上是一个细化的过程。
  • 细化和抽象是互补的概念
    • 抽象让设计人员忽略底层细节，重点描述结构、过程和数据
    • 精化有助于设计人员在设计过程中揭示底层的细节
• 体系结构
  • 软件体系结构指“软件的整体结构和这种结构为系统提供概念完整性的方式
  • 软件设计的目标之一是导出系统体系结构示意图，
• 模式
  • 设计模式描述了解决某个特定设计问题的设计结构,
• 模块化
  • 模块化指将待开发的软件分解成简单模块，模块独立开发、测试，最后把模块组装成软件。
  • 模块化使应注意将模块的数量保持在最小成本区域M附近，应避免不足的模块化或过度的模块化问题
• 信息隐蔽
  • 每个模块的实现细节对其他模块来说是隐藏的、不可见的。
  • 在一个模块内的信息不允许其它不需要这些信息的模块使用。
• 功能独立
  • 功能独立是抽象、模块化和信息隐藏等概念的直接产物。
    • 每个模块有单一功能，与其他功能没有太多联系
    • 模块的功能独立程度是评价设计好坏的重要度量标准
  • 模块独立性的两个标准： 内聚和耦合

    • 

    • 优秀的软件设计：高内聚、低耦合，这也是评判设计好坏的一个标准

• 重构
  • 重构是一种重新组织的技术，可以简化构件的设计(或代码)而无需改变其功能或行为。
  • 重构检查设计的冗余、低效的算法、不足的设计结构等等设计的不足
• 设计类
  • 当设计模型发生演化时,必须定义一组设计类
  • 设计类的五种类型
    • (1)用户接口类，定义人机交互(Human-ComputerInteraction，HCI)
    • (2)业务域类，识别实现某些业务域元素所必需的属性和服务(方法)
    • (3)过程类，实现完整的管理业务域类所必需的低层业务抽象;
    • (4)持久类，用于表示将在软件执行之外持续存在的数据存储〈例如，数据库);
    • (5)系统类，实现软件管理和控制功能，使系统能够运行，并在其计算环境内与外界通信。
  • 设计类良好的四个特征，见下面

3. The design model

1. the concepts of the design process

• 软件设计是一个迭代的过程，通过这个过程，需求被变换为用于构建软件的“蓝图”。刚开始，蓝图描述了软件的整体视图，也就是说，设计是在高抽象层次上的表达——在该层次上可以直接跟踪到特定的系统目标以及更详细的数据、功能和行为需求。随着设计迭代的开始，后续的细化导致更低抽象层次的设计表示。这些表示仍然能够跟踪到需求，但是连接更加错综复杂了。

2. five design models ： Data Design elements, Architectural Design elements, Interface Design elements, Component-Level Design elements ，Deployment-Level Design elements.

• 数据设计元素
  • 数据设计(有时也称为数据体系结构)创建了在高抽象级上(以客户或用户的数据观点)表示的数据模型和信息模型。之后，数据模型被逐步求精为特定实现的表示，亦即计算机系统能够处理的表示。
• 体系结构设计元素
  • 体系结构设计元素为我们提供了软件的整体视图。
• 接口设计元素
  • 软件接口设计元素描述了信息如何流入和流出系统，以及被定义为体系结构一部分的构件之间是如何通信的。
• 构件级设计元素
  • 软件的构件级设计完整地描述了每个软件构件的内部细节。为此，构件级设计为所有局部数据对象定义数据结构，为所有在构件内发生的处理定义算法细节，并定义允许访问所有构件操作(行为)的接口。
• 部署级设计元素
  • 部署级设计元素指明软件功能和子系统将如何在支持软件的物理计算环境内进行分布。

3. 4 characteristics of a well-formed design class：Complete and sufficient, Primitiveness（原始性）, High cohesion, Low coupling（高类聚低耦合）

• 设计类良好的四个特征
  • 完整性与充分性，设计类应该完整地封装所有可以合理预见的存在于类中的属性和方法。
  • 原始性，和一个设计类相关的方法应该关注于实现类的某一个服务。
  • 高内聚性，一个内聚的设计类具有小的、集中的职责集合，并且专注于使用属性和方法来实现那些职责。
  • 低耦合性，设计类之间的协作应该保持在一个可以接受的最小范围内

4. Analysis Model and Design Model（二者关系：过程维度、抽象维度）

• 过程维度表示设计模型的演化，设计任务作为软件过程的一部分被执行。
• 抽象维度表示详细级别，分析模型的每个元素转化为一个等价的设计，然后迁代求精。
• 

7: Architectural Design

1. Software Architecture

1. The definition of architectural

• 体系结构：系统的一个或多个结构，包括软件构件（各个不同的软件模块）、外部属性及相互关系。
• 体系结构并非可运行的软件，而是对软件系统的一种宏观表达方式

2. Data design

1. The goal of Data Design in the Architectural Design

3. Architectural styles and patterns

1. components, connectors, constraints, semantic （语义）models;

• 体系结构风格：每种风格描述一种系统类别，包括:
  • (1)完成系统需要的某种功能的一组构件(例如，数据库、计算模块);
  • (2)能使构件间实现“通信、合作和协调”的一组连接件;
  • (3)定义构件如何集成为系统的约束;
  • (4)语义模型，能使设计者通过分析系统组成成分的已知属性来理解系统的整体性质

2. Data-centered, Data-flow, Call and return, Object-oriented, Layered architectures

• 以数据为中心的体系结构（Data-centered architecture，黑板模式）

  • 容易添加新的客户端软件
  • 修改数据结构容易导致各个客户端都受影响
  • 

• 数据流的体系结构（Data-flow,管道-过滤器模式）

  • 每一个处理步骤都封装在一个过滤器内，要处理的数据通过管道传递，各过滤器无需了解其他过滤器的工作
  • 

• 调用和返回体系结构,Call and return

  • 该体系结构风格能够设计出一个相对易于修改和扩展的程序结构。
  • 在此类体系结构中，存在几种子风格

    • 主程序-子程序体系结构是调用-返回模式的典型代表

    • 

    • 远程过程调用体系结构。主程序/子程序体系结构的构件分布在网络中的多台计算机上。

• 面向对条体系结构Object-oriented。

  • 系统的构件封装了数据和必须用于控制该数据的操作，构件间通过信息传递进行通信与合作。

• 层次体系结构Layered（多层次体系架构模式

  • 

3. Architectural complexity: dependencies（三种依赖关系）

8: Component-level Design

1. What is a component

• 什么是构件？
  • 系统中模块化的、可部署的和可替换的部件，该部件封装了实现并对外提供一组接口。
  • OO view：以面向对象的观,点来看,构件是协作类的集合。构件中的每个类都得到详细阐述,包括所有属性和与其实现相关的操作。作为细节设计的一部分，必须定义所有与其他设计类相互通信协作的接口。
  • Conventional view：在传统软件工程环境中，一个构件就是程序的一个功能要素，程序由处理逻辑及实现处理逻辑所需的内部数据结构以及能够保证构件被调用和实现数据传递的接口构成。传统构件也称为模块，作为软件体系结构的一部分，它扮演如下三个重要角色之一:(1）控制构件，协调问题域中所有其他构件的调用;(2）问题域构件，完成客户需要的全部功能或部分功能;(3）基础设施构件，负责完成问题域中所需的支持处理的功能。

2. Design Class-based component

1. Basic design principles

• 4个基本设计原则
• ①开闭原则。OCP
  • 开闭原则(TheOpen-ClosedPrinciple，OCP)。模块(构件)应该对外延具有开放性，对修改具有封闭性
• ②Liskov替换原则。LSP
  • (Liskov Substitution Principle，LSP)。子类可以替换它们的基类
• ③依赖倒置原则。
  • 依赖倒置原则(Dependency InversionPrinciple，DIP)。依赖于抽象，而非具体实现
• ④接口分离原则。
  • 接口分离原则(Interface Segregation Principle，ISP)。多个客户专用人接口比一个通用接口要好

2. Two qualitative criteria for measuring module independence:Cohesion & Coupling

• 内聚性Cohesion
  • 在为面向对象系统进行构件级设计时,内聚性意味着构件或者类只封装那些相互关联密切,以及与构件或类自身有密切关系的属性和操作。不同类型的内聚性(按照内聚性的级别排序R)。
    • 功能内聚。主要通过操作来体现，当一个模块完成一组且只有一组操作并返回结果时，就称此模块是功能内聚的。
    • 分层内聚。由包、构件和类来体现。高层能够访问低层的服务，但低层不能访问高层的服务。
    • 通信内聚。访问相同数据的所有操作被定义在一个类中。一般说来，这些类只着眼于数据的查询、访问和存储。
• 耦合性Coupling
  • 耦合是类之间彼此联系程度的一种定性度量。随着类(构件)之间的相互依赖越来越多，类之间的耦合程度亦会增加。在构件级设计中，一个重要的目标就是尽可能保持低耦合。耦合分类。
    • 内容耦合。发生在当一个构件“暗中修改其他构件的内部数据”时。这违反了基本设计概念当中的信息隐蔽原则。
    • 控制耦合。发生在当操作A调用操作B，并且向B传递了一个控制标记时。接着，控制标记将会指引B中的逻辑流程。这种耦合形式的主要问题在于，B中的一个不相关变更往往能够导致A所传递控制标记的意义也必须发生变更。如果忽略这个问题，就会引起错误。
    • 外部耦合。发生在当一个构件和基础设施构件（例如，操作系统功能、数据库容量、无线通信功能等)进行通信和协作时。尽管这种类型的耦合是必要的，但是在一个系统中应该尽量将这种耦合限制在少量的构件或者类范围内。

3. Analysis Class and Design Class

3. Conducting component-level design

1. The steps of OO Component-level Design面向对象构件级设计的步骤
   步骤1:标识出所有与问题域相对应的设计类。
   步骤2:确定所有与基础设施域相对应的设计类。
   步骤3:细化所有不需要作为复用构件的设计类。
   步骤3a:在类或构件协作时说明消息的细节。
   步骤3b:为每个构件确定适当的接口
   步骤3c:细化属性，并且定义实现属性所需要的数据类型和数据结构
   步骤 3d : 详细 描述每个操作中的处理流 。
   步骤4:说明持久数据源(数据库和文件)并确定管理数据源所需要的类。
   步骤5:开发并且细化类或构件的行为表示
   步骤6:细化部署图以提供额外的实现细节。
   步骤7:考虑每个构件级设计表示，并且时刻考虑其他可选方案。

4. Design conventional components

1. flow diagram 流程图

• 结构化程序设计是一种设计技术,该技术将程序逻辑流程限制为以下三种结构:顺序型,条件型和重复型。
  

9: User Interface Design

1. The Golden Rules

• 黄金法则
  • 1.把控制权交给用户。
  • 2.减轻用户的记忆负担。
  • 3.保持界面一致。
• 1.把控制权交给用户。
  • 以一种不会强迫用户进行不必要或不希望的操作的方式定义交互模式。
  • 提供灵活的交互方式。
  • 允许用户交互被中断和撤销
  • 当技能水平高，使交互流线化，并允许定制交互。
  • 对普通用户隐藏技术内部。
  • 设计允许用户与出现在屏幕上的对象直接交互。
• 2.减轻用户的记忆负担
  • 1.减少对短期记忆的需求。
  • 2.建立有意义的默认值。
  • 3.定义直观的快捷方式。
  • 4.界面的视觉布局应该基于现实世界的隐喻。
  • 5.循序渐进地披露信息。
• 3.保持界面一致。
  • 允许用户将当前任务放入有意义的环境中
  • 在完整的产品线内保持一致性。
  • 如果过去的交互模型已经建立起了用户期望，除非有不得已的理由，否则不要改变它。

2. User Interface analysis and design

user analysis, task and work environment analysis，Interface design, Interface validation

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

• 界面分析活动的重点在于那些与系统交互的用户的轮廓。一旦定义好了一般需求，就将进行更详细的任务分析。标识、描述和细化(通过绕螺旋的多次迭代)用户为了达到系统目标而执行的任务。最后，用户环境的分析着重于物理工作环境的特征（例如地理位置、采光、位置约束)。
• 界面设计的目标是定义一组界面对象和动作(以及它们的屏幕表示)，使得用户能够以满足系统所定义的每个使用目标的方式完成所有定义的任务。
• 界面构建通常开始于创建可评估使用场景的原型。随着迭代设计过程的继续，用户界面开发工具可用来完成界面的构造。
• 界面确认着重于:
  • 1界面正确地实现每个用户任务的能力，适应所有任务变化的能力以及达到所有一般用户需求的能力;
  • 2界面容易使用和学习的程度;
  • 3作为工作中的得力工具，用户对界面的接受程度。

3. Interface analysis

1. Steps of interface analysis界面设计的步骤：
   接口分析意味着理解
   (1)将通过界面与系统交互的人(最终用户);
   (2)最终用户必须完成的工作任务;
   (3)作为界面一部分呈现的内容
   (4)执行这些任务的环境。

• 用户分析：
  • 利用各种途径(用户访谈、销售输入、市场输入、支持输人和人)获得信息。
• 任务分析与建模

  • 用例：作为任务分析的一部分，设计用例用来显示最终用户如何完成指定的相关工作任务。

  • 任务细化

  • 对象细化

  • 工作流分析：该技术使得软件工程师可以很好地理解在涉及多个成员(和角色)时，工作过程是如何完成的。

  • 

  • 层次表示

• 显示内容分析
  • 考虑内容的格式和美感
• 工作环境分析
  • 会受周围环境的影响，物理环境和文化氛围

4. Interface design Steps

界面设计步骤步骤:

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

1. Design GUI according to Use-Case Diagram

10: Testing strategies and techniques

1. A strategic approach to software testing

• 验证与确认Verification and Validation V&V
  • 验证Verification:确保软件正确实现特定功能的一组活动。
    • 问题:我们在正确地构建产品吗？
  • 确认Validation:确保开发的软件可追溯到客户需求的另外一系列活动。
    • 问题:我们在构建正确的产品吗？
• 软件测试组织
  • 软件开发人员：
    • 负责测试程序的各个单元。
    • 负责进行集成测试。
  • 独立测试组 (ITG):
    • 尽可能地发现错误。
  • 误解：
    • 开发人员不应该进行任何测试。
    • 软件应该由陌生人测试。
    • 测试人员在测试之前不需要加入项目。
• 软件测试策略–宏观

  • 

  • 单元测试unit test：起始于螺旋的旋涡中心，侧重于以源代码形式实现的每个单元

  • 集成测试integration test:这时的测试重点在于软件体系结构的设计和构建

  • 确认测试validation test：依据已经建立的软件，对需求(作为软件需求建模的一部分而建立)进行确认

  • 系统测试system test:将软件与系统的其他成分作为一个整体来测试。

2. Test strategies for conventional software（过程与文档）

1. Unit testing单元测试

2. integration testing 集成测试

• Top-Down integration & Botton-Up integration
• regression（回归） testing & smoke（冒烟） testing
• 自顶向下集成测试Top-Down integration–步骤
  • 第1步：测试顶端模块，用**存根程序(stub)**代替直接附属的下层模块
    • Stub:模拟尚未测试的组件的活动。
  • 第2步：根据深度优先或宽度优先的策略，每次用一个实际模块代换一个stub。
  • 第3步：在结合进一个模块的同时进行测试。
  • 第4步：回归测试(regression testing)—全部或部分地重复以前做过的测试。
  • 优点：在早期即对主要控制及关键的抉择进行检验。
  • 问题：Stub只是对低层模块的模拟，测试时没有重要的数据自下往上流，许多重要的测试须推迟进行，而且在早期不能充分展开人力。
• 自底向上集成测试Botton-Up integration --步骤
  • 第1步：把低层模块组合成族cluster，每族实现一个子功能。
  • 第2步：用驱动程序(Driver) 协调测试数据的I/O，测试子功能族。
    • 驱动程序:调用一个特定的组件，并向它传递一个测试用例。
  • 第3步：去掉Driver，自下而上把子功能族合成更大的子功能族。
  • 注意：两种策略的优、缺点刚好互补，但单用其中任一种都不实际，通常根据软件的特点将二者混用。
• regression test（回归测试）
  • 回归测试是重新执行一些已经执行的测试子集,以确保更改没有传播意想不到的副作用。
  • 每当软件被修正时，软件配置的某些方面(程序、它的文档或支持它的数据)就会被改变。
  • 回归测试有助于确保变更(由于测试或其他原因)不会引入意外的行为或额外的错误
• smoke testing（冒烟测试）
  • 1.将已经转换为代码的软件构件集成到构造( build)中。
  • 2.设计一系列测试以暴露影响构造正确地完成其功能的错误。其目的是发现极有可能造成项目延迟的业务阻塞(show stopper）错误。
  • 3.每天将该构造与其他构造及整个软件产品（以其当前的形式)集成起来进行冒烟测试。这种集成方法可以是自顶向下的，也可以自底向上的。

3. Acceptance testing（ Validation testing ）确认测试

• Validation Test Criteria;确认测试准则
  • 满足所有功能要求;
  • 实现所有行为特征;
  • 达到所有性能要求;
  • 所有文件正确无误;
  • 满足可用性和其他要求,
• Configuration Review;配置评审
  • 确认过程的一个重要成分是配置评审。评审的目的是确保所有的软件配置元素已正确开发、编目，且具有改善支持活动的必要细节。有时将配置评审称为审核(audit)
• Alpha and Beta Testing;α测试和β测试
  • α测试：α测试是由有代表性的最终用户在开发者的场所进行。开发者在场记录错误和使用问题。在受控的环境下进行。
  • β测试：β测试在一个或多个最终用户场所进行。开发者通常不在场。最终用户记录问题。

4.System testing

• 恢复测试（recovery testing)
  • 在系统出故障后，系统能否从故障中恢复过来，并在预定的时间间隔内从新开始处理
  • 强使软件出现故障，系统应自动恢复
  • 如需人工干预，应估算出修复的平均时间，确定出是否可接受
• 安全性测试（security testing)
  • 系统的预防机制（预防非法入侵:窃贼，报复，非法牟利……)
  • 安全性测试，验证系统的预防机制
  • 测试者扮演期望侵入系统的角色，通过一切可能的措施侵入系统
  • 测试开销可能很大
• 压力测试（stress testing)
  • 在一个非正常数量，频率或容量方式下运行系统
  • 测试者想办法破坏程序
    • 1，运行要求最大内存或其他资源的程序
    • 2，按大小递增的顺序改变输入数据的速率，看系统怎样响应
• 性能测试(performance testing)
  • 测试软件被组装进系统的环境下运行时的性能
  • 性能测试覆盖测试过程中的每一步
• 部署测试(Deployment testing)
  • 部署测试，又叫做配置测试（Configuration testing),测试不同的运行环境。

3. Validation testing

4. System testing

Use-Case Diagram
Function testing, specification

5. The art of debugging

1. The relationship of testing and debugging测试和调试的关系

• 调试( debugging）出现在成功的测试之后。也就是说，当测试用例发现错误时，调试是使错误消除的过程。
• 调试并不是测试，但总是发生在测试之后°。
• gpt：
  • 测试是发现问题，调试是解决问题。
  • 测试是一个更广义的概念，包含各种类型的测试，而调试是测试过程的一部分，是针对测试发现的特定问题进行深入分析和解决。
  • 测试侧重于找出软件中存在的缺陷，而调试侧重于修复缺陷。
  • 测试结果是调试的起点。测试中发现的缺陷是调试的直接目标。
  • 调试的结果影响着测试的进行。修复缺陷后，需要重新进行测试，以验证修复是否有效，并确保没有引入新的缺陷。

6. White-Box testing

白盒测试：

• Basis Path Testing
• Control Structure Testing
• 白盒测试
  • 依据：软件源代码
  • 是一种测试用例设计方法，盒子指的是被测试的软件，白盒指的是盒子内部是透明可见的
  • 是一种基于软件内部路径、程序结构和代码实现基础上的软件测试策略

1. Flow Graph Notation流程图表示法

• 流图形式的结构化构造：

  • 其中每个圆圈代表一个或多个非分支的PDL过程设计语言 (Procedure Design Language)或源代码语句。
  • sequence、if、while、until、case

• 

• 

• 

2. Cyclomatic Complexity（圈复杂度与独立路径）

• 三种计算方法
  • 区域数量=环路复杂度
  • V(G) = E - N + 2; E使边数、N是节点数
  • V (G) = P + 1；P谓词节点/判断节点

7. Basis path testing

• 这是一种白盒测试技术。
• 它使测试用例设计者能够推导出程序设计逻辑复杂度的度量，并利用该度量作为定义一组基本执行路径的指导。
• 为执行基本集而派生的测试用例保证在测试期间至少执行程序中的每个语句一次。

1. 流图表示Flow Graph Notation流程图表示法 同上
2. 独立程序路径
   • 独立路径是任何贯穿程序的、至少引入一组新处理语句或一个新条件的路径。
   • Cyclomatic Complexity（圈复杂度与独立路径）
3. 生成测试用例Deriving Test Cases

• 基本路径测试方法可以应用于程序设计或源代码。
• 一系列步骤:
  1.以设计或代码为基础，画出相应的流程图。2.确定生成流图的圈复杂度。
  3.确定线性无关路径的基集。
  4.准备测试用例，这些测试用例将强制执行基集中的每个路径。

8. Control structure testing（条件/循环）

Condition testing;–程序模块中包含的逻辑条件
Loop testing;–循环

9. Black-Box testing

• 黑盒测试
  • 依据：软件规格说明书
  • 把测试对象看作一个黑盒子，不考虑软件的内部逻辑和代码的具体实现，验证软件是否达到规格说明书上写的功能、性能、约束条件等

1. Equivalence Partitioning（等价类划分）

• 等价类划分是一种黑盒测试方法，它将程序的输入划分为若干个数据类，从中生成测试用例。

• 

• 

2. Boundary Value Analysis（边界值分析）

• 大量错误发生在输入域的边界处，而不是发生在输入域的“中间”。这是将边界值分析( Boundary Value Analysis，BVA)作为一种测试技术的原因。边界值分析选择一组测试用例检查边界值。

• BVA不是选择等价类的任何元素，而是在等价类“边缘”上选择测试用例。BVA不是仅仅侧重于输人条件，它也从输出域中导出测试用例。

• 

• 

10. OO Testing Methods

• 用例设计
  1.每个测试用例应该被唯一标识;
  2.每个测试用例都应该显式地与要测试的类关联起来;
  3.应说明测试的目的;
  4.应该为每个测试制定一个测试步骤列表。
• 步骤
  a.被测试对象的指定状态列表;
  B.作为测试结果将执行的消息和操作的列表;C.测试对象时可能出现的异常列表;
  D.外部条件列表(即，为了正确进行测试，必须存在的软件外部环境的变化);
  E.有助于理解或实施测试的补充信息。