↓跳过正文
Blog
  1. 文档/

2024 软件工程复习

·15359 字·31 分钟· loading · ·
软件工程 复习
目录

2024 软件工程复习
#

Tongji University. 2024/12/21
Hyoung Yan

本文框架
#

本文框架

Chapter 1: 软件工程概述
#

背景知识
#

  1. 软件是计算机系统中与硬件相互依存的另一部分，它是包括程序、数据及其相关文档组成的完整集合。 软件是一种逻辑实体，具有抽象性。软件具有 复杂度、一致性、可变性和无不可见性 等固有的内在特性，这是造成软件开发困难的根本原因。

    • 软件 = 程序+数据+文档
    • 程序：程序是按照事先设计好的功能和性能要求执行的指令序列
    • 数据：数据是指程序等正常处理信息的数据和数据结构
    • 文档：文档是与软件开发、设计、运行、维护有关的图文资料

  2. 软件分类 可按照用途分类，也可根据软件的规模、软件的工作方式、使用频度、失效后的影响等进行分类。

    • 系统软件：系统软件是为其他软件服务的软件
    • 实时软件：管理、分析、控制现实世界所发生的事件的软件
    • 商业管理软件：商业信息处理是最大的软件应用领域，各类管理信息系统(MIS)、企业资源计划(ERP)、客户关系管理(CRM)等都是典型的商业管理软件
    • 工程与科学计算软件：此类软件的特征是要实现特定的“数值分析”算法
    • 嵌入式软件：嵌入式软件是指嵌入在各种电子设备中的软件，完成很有限、很专业的功能的软件
    • 人工智能软件：利用非数值算法去解决复杂问题的软件。各类专家系统、模式识别软件、人工神经网络软件都属于人工智能软件。
    • 个人计算机软件：文字处理系统、电子表格、游戏娱乐软件等
      1734694012974

  3. 软件危机：是指在计算机软件的开发和维护过程中所遇到的一系列严重问题

    • 其一，如何开发软件，以满足不断增长、日趋复杂的需求
    • 其二，如何维护数量不断膨胀的软件产品

  4. 软件开发问题的解决途径 1968 年北大西洋公约组织（NATO）召开国际会议，提出“软件工程”概念和术语。

    1734694799701

软件工程概述
#

  1. 系统的特征

    • 系统是相互联系的一组元素的集合
    • 系统是具有特点功能的有机整体
    • 系统是有边界的
    • 系统需要和其他系统交互
    • 一个系统可能包含另一个系统
    • 系统是逐渐演变形成的

  2. 工程的概念 工程的方法： 工程是将理论与所学的知识应用于实践的科学，以便经济有效地解决实际问题。

    工程的特征：

    • 注重系统的构建过程
    • 平衡与决策
    • 度量与验证
    • 训练有素的过程
    • 团队协作与角色分工
    • 系统地运用工具
    • 工程原则、标准和实践
    • 重用设计和设计制品

  3. 什么是软件工程？ 软件工程是：

    1. 将系统性的、规范化的、可定量的方法应用于软件的开发、运行和维护，即工程化应用到软件上
    2. 对 1 中所述方法的研究

  4. 软件工程的基本目标

    • 较低的开发成本
    • 按时完成开发任务并及时交付
    • 实现客户要求的功能
    • 所开发软件具有良好的性能
    • 较高的可靠性、可扩展性、可移植性
    • 软件维护费用低

  5. 软件质量属性

    什么是好的软件？ 功能质量、结构质量、过程质量

    1734695492056

    • McCall 质量模型
      1734695585402
    • ISO9126 质量模型
      1734695627386

软件过程模型
#

  1. 软件开发活动

    • 问题定义：人们通过开展技术探索和市场调查等活动，研究系统的可行性和可能解决方案，确定待开发系统的总体目标和范围
      1734695951212
    • 需求开发：在可行性研究之后，分析、整理和提炼所收集到的客户需求，建立完整的需求分析模型，编写软件需求规格说明
      1734696012433
    • 软件设计：根据需求规格说明，确定软件体系结构，进一步设计每个系统部件的实现算法、数据结构及其接口等
      1734696073229
    • 软件实现：概括说是将软件设计转换为程序代码，是一个复杂且迭代的过程，要求根据设计模型进行程序设计以及正确高效地编写和测试代码
      1734696151611
    • 软件测试：检查和验证所开发的系统是否符合用户期望，包括单元测试、子系统测试、集成测试和验收测试等
      1734696218565
    • 软件演化：系统投入使用后对其进行改进，以适应不断变化的需求，将系统的开发和维护看作一个连续的过程更有意义。
      1734696351172

  2. 瀑布模型：瀑布模型的开发阶段严格按照线性方式进行，每一个阶段具有相关的里程碑和交付产品，且需要确认和验收。

    • 需求定义与分析
    • 软件设计
    • 软件实现
    • 软件测试
    • 软件运行与维护
      1734696425834

    讨论： 瀑布模型是否反映了实际的软件开发过程？软件开发作为一个问题求解过程，应当具备什么特点？

    瀑布模型源于硬件领域，它从制造业的角度来审视软件开发。制造业是通过批量生产某一特定产品来实现的，而软件开发则不同。随着人们对问题的深入理解以及对可选方案的不断评估，软件在开发过程中不断演化。因此，软件开发更像是一个创造性的过程，而非单纯的生产过程。

  3. 软件开发具有 迭代性，需要不断地反复尝试，通过比较和选择不同的设计，最终确定令人满意的问题解决方案

  4. 原型化模型：原型化模型需要 迅速建造 一个可运行的软件原型，它使用户和开发人员对系统的相关方面进行检查，以决定是否合适和恰当

    1734696848799

  5. 需求原型化

    • 纸上原型
    • 产品原型设计软件

  6. 阶段化开发：今天的商业环境需要快速地推出新产品，阶段化开发使得软件系统能够一部分一部分地交付，从而缩短软件开发周期。

    1734696940623

    • 增量模型：在每一个新的发布中逐步增加功能直到构造全部功能
    • 迭代模型：一开始提交一个完整系统，在后续发布中补充完善各子系统功能
      1734697029850

  7. 可转换模型：可转换模型师采用 形式化的数学方法 描述系统，并利用一系列转换将形式化的需求规格说明变为可交付使用的系统 数学方法具有严密性和准确性，形式化方法所交付的系统具有较少的缺陷和较高的安全性

    1734697101253
    网络公开课程：适用于增量模型或迭代模型 汽车防抱死系统：适用于可转换模型（形式化方法）

Chapter 2: 需求获取技术
#

软件需求
#

  1. 软件需求：是指利益相关方队目标软件系统的要求和期望，细分为：

    • 功能需求：描述系统应该具有的功能（控制 ⽉ 球 ⻋ 移动并到达指定地点）
    • 性能需求：描述系统应该具有的性能（MCS 必须在 1 秒内完成最优路径规划）
    • 可靠性需求：描述系统应该具有的可靠性（MCS 平均 ⽆ 故障 ⼯ 作时间必须 ⼤ 于 24 ⼩ 时）
    • 约束性需求：描述系统应该满足的约束条件（MCS 必须在 10 个 ⽉ 内通过验收测试）

    软件需求是整个软件项目的终极目标，也是后续软件开发活动的主要基础

  2. 需求工程活动

    • 需求抽取（Elitication）：通过与用户交流，了解用户需求
    • 需求分析（Analysis）：对需求进行分析，确定需求的优先级
    • 需求规约（Specification）：将需求规约为文档
    • 需求管理（Management）：管理需求变更
    • 需求验证（Validation）：验证需求是否满足用户需求
      1734697792979

需求抽取
#

  1. 需求抽取的目标、实质和关键

    • 需求抽取的目标 是主动与干系人协同工作，找出他们的需求，设别潜在的冲突，磋商解决矛盾，定义系统范围与边界
    • 需求抽取的实质 是了解待解决问题及其所属领域；
    • 需求抽取的关键 是确保问题的解决是有 商业价值 的

  2. 需求抽取技术

    • 抽取技术：协同工作、面谈、问卷调查、观察法、原型法、文档分析、建模、角色扮演、非功能性需求列表
    • 冲突是被与磋商

  3. 需求抽取的出发点

    • 确定干系人：需要强调与客户的联络关系，系统的设计与谁的利益息息相关
    • 定义边界：界定问题的范围，确定系统的边界
    • 定义目标和情景实例：目标和情景实例是组织原始需求信息的有效手段
    • 分析可行性：如何进行可行性研究，如何选择好的项目
    • 分析风险：风险管理应长期、持续进行，而非阶段性、一次性的任务；进行灾难和事故分析以确定风险
      1734698914500

  4. Stakeholders：干系人是指与软件系统有关的所有人员，包括用户、开发人员、管理人员、维护人员、软件工程师等。让利益相关者参与个人或团体需求会议以定义系统详细信息

    1734699316060

  5. 访谈技巧，启发式问题：

    • 访谈：同一时间，同一地点。Few People, Analyst-Driven
      1734699764251
    • 调查文卷：不同时间，不同地点。Many People, Analyst-Observer
      1734699872379
    • 小组讨论：相同时间，相同或不同地点，< 20 人，Analyst-Facilitated
      1734699919470
    • 观察：同一时间，同一地点，Analyst-Observer
      1734700042812
    • 原型、模型、大纲：澄清模糊或不确定的需求；简化需求文档和接受需求，向客户和最终用户提供早期反馈（A picture says a thousand words.）
      1734700324738

  6. Prepare for Change

    • This is an “attitude”
    • The more stakeholders are involved, the more features they will want • Don’t solve this “problem” by eliminating stakeholders
    • Stakeholders have the right to change their minds • Don’t Ever Ask: “Ok, Is that Your Final Requirement?”
    • See suggested changes as opportunities, not threats

需求分析
#

需求分析的目标、实质和关键

  • 目标：对产品及其环境的交互进行更深入的了解，识别系统需求，设计软件体系结构，建立需求与体系结构部件之间的关联，在体系结构设计实现过程中进一步识别矛盾冲突，并通过干系人之间的协调磋商解决问题
  • 实质：概念建模，选择常用的建模语言，进行功能建模和信息建模
  • 关键：体系结构设计与需求分配 通过评估需求的满足度来评价体系结构设计的质量

需求规约
#

需求规约是系统和软件需求的文档化，以便于后续的需求及系统正式评审而准备的规范化文档

  • 单个需求项的质量：准确、正确、明确、可行、可证
  • 整个需求集合的质量：现实、精确、全面、一致

需求管理
#

需求管理是贯穿从需求获取到软件系统下线的全过程。需求管理设计软件配置管理、需求跟踪、影响分析和版本控制。

  • 需求跟踪：描述和追踪一条需求的来龙去脉的能力，包括向前追踪到软件制品，向后追踪到需求来源。
  • 变更请求管理：系统化的变更管理
  • 需求属性管理

需求验证
#

对其他需求工程活动的质量的保证。通过数学的形式化工具或工程化的测试过程来确保系统满足干系人的要求。 验证方法：评审、原型化、模型验证、确认测试

需求种类

  • 用户需求，客户需求，业务需求

  • 软件需求，系统需求

    • 功能需求：As an actor(object), do what, so that (goal)
    • 非功能需求
      • 质量需求：安全性、可靠性、稳定性、可用性、可维护性、可移植性、可扩展性、兼容性
      • 约束需求：预算、时间、技术等

需求获取的内容
#

  • 功能需求：系统做什么，系统何时做什么，系统何时及如何修改或升级
  • 性能需求：软件开发的技术性指标，规模大小、存储容量、可靠性、安全性
  • 环境需求：硬件设备、软件设备
  • 界面需求：来自其他系统的输入、输出到其他系统、数据格式、数据存储介质
  • 接口需求：软件与其他软件或硬件的接口
  • 用户或人的因素：用户需求、用户熟练程度、需何种培训
  • 文档需求：用户手册、技术手册、培训手册
  • 数据需求：数据的输入、输出、存储、数据流量
  • 资源需求：人员、时间、预算、硬件、软件
  • 安全需求
  • 软件成本消耗与开发进度
  • 质量保证

数据流图 DFD
#

1734702378451
软件需求分析建模方法：

  • 结构化分析（传统建模方法）：数据流图、数据字典、实体关系图
  • 面向对象分析：对象模型、功能模型、动态模型

数据流图（DFD，Data Flow Diagram）是一种描述系统功能的图形化工具，图中没有任何具体的物理元素，只是描绘信息在系统中的流动和处理情况。就图本身而言，并不是只有程序员，或计算机专业技术人员能够读懂，特别是需求方（客户，用户）也能读懂。

1734702523157

  1. DFD 的基本元素

    1734702643122

    • External Entity：外部实体，系统的输入输出来源，Source/Sink
    • Processing：处理，对数据进行处理的过程，至少有一个输入和一个输出
    • Data Flow：数据流，数据在处理过程中的流动
    • Data Stores：数据存储，数据的存储位置
    • Describing letter：描述符号，用于描述数据流的内容

  2. DFD 的基本规则

    • 流程的输入始终和输出不同
    • 对象始终有唯一的命名
    • 处理至少有一个输入和一个输出
    • 数据无法直接从一个存储移至另一个存储
    • 数据无法直接从外部源移动到数据存储
    • 数据无法直接从数据存储移动到数据接收器
    • 数据存储具有名词短语标签
    • 数据无法直接从源移动到接收点
    • 数据流在符号之间只有一个流动方向
    • 数据流到数据存储意味着更新
    • 来自数据存储的数据流意味着检索或使用
    • 分叉意味着完全相同的数据从公共位置传输到两个或多个进程、数据存储或源/接收器
    • 连接意味着完全相同的数据来自任何两个或更多不同的流程、数据存储或源/接收器到公共位置

  3. DFD 分层 DFD 可以分为多个层次，每个层次都有不同的细节级别。最高层次的 DFD 称为 0 级 DFD，它是系统的总体概述。0 级 DFD 描述了系统的整体功能，而 1 级 DFD 描述了 0 级 DFD 中的每个功能的详细信息。1 级 DFD 可以进一步分解为 2 级、3 级 DFD 等。

  4. DFD 缺点：无法给出精确详细的定义，不能使用 DFDs 模拟系统

数据字典 DD
#

数据字典 DD 是对所有与系统相关的数据元素的一个有组织的列表, 以及精确的、严格的定义，使得用户和系统分析员对于输入、输出、存储成分和中间计算结果等有共同的理解。

定义式中使用的符号

操作符含义描述举例
=被定义为x = “a”
+与（顺序结构）x = a + b
{…}重复（循环结构）x = {a}，x = 3{a}8
[…|…]或（选择结构）x = [a, b]，x = [a|b]
[…,…]或（选择结构）x = [a, b]
(…)可选x = (a)
“…”基本数据元素x = “a”
..连结符x = 1..9
*…*注释符这是注释内容
m..n界域x = 3..8

x = {a}: a 重复 0 次或多次

x = 3{a}8: a 重复 3 次到 8 次

实体关系图 E-R
#

实体关系图 E-R 是一种用于描述系统中数据的结构化方法，它描述了系统中的实体、实体之间的关系和实体的属性。可用于描述数据流图中“数据存贮”及其之间的关系，它是数据库概念设计的最常用的工具。

ERD 的符号：

  • 实体用长方形表示

  • 实体的属性用椭圆形表示

  • 联系用菱形框表示

  • 用无向边把实体与其属性连接起来

    1734704273274

Chapter 3: UML 与用例建模
#

面向对象分析模型：

  • 用例图 Use Case Diagram
  • 类图和对象图 Class Diagram and Object Diagram
  • 行为图 Behavior Diagram
  1. 面向对象：封装、继承、复用、对象
  2. 对象-类
  • 类是描述和抽象; 对象是具体和实例化（instance）
  • 类是对象定义，描述，设计时的称呼。
  • 对象是类使用，调用，实例化时的称呼。类对应的程序运行使用的称呼
  1. 软件开发中为什么要使用面向对象方法？
  • 自然，接近现实
  • 方便建模
  • 模块化
  • 封装与信息隐藏
  • 继承复用
  • 扩展修改维护容易
  1. 面向对象分析方法与结构化分析方法有哪些相似之处？有何区别？
  • 面向结构的方法是过程的集合，面向对象的方法是实体的集合
  • 传统方法数据与过程分离，对象方法数据和处理数据的方法封装成一个单元
  • SOA 方法面向功能，OOP 方法面向对象，并确定实体间的关系，但两种方法并不排斥

  1. 面向对象方法是对过去的一个完全突破，还是“换汤不换药”？

    面向对象方法并不是对过去的完全突破，而是对传统方法的改进和扩展。它继承了传统方法中的许多优点，同时引入了新的概念和技术，如封装、继承和多态性，使得软件开发更加自然和接近现实世界。面向对象方法强调对象和类的概念，将数据和操作封装在一起，提高了系统的模块化和可维护性。因此，面向对象方法可以看作是对传统方法的优化和发展，而不是完全的颠覆。

  2. OOA 建立分析模型的 5 个基本原则 建立分析模型 5 个基本原则：

    • 建模信息域；
    • 描述模块功能；
    • 表示模型行为；
    • 分解以模型显示更多细节；
    • 早期模型表示问题的本质，而后期模型提供实现细节。

UML 基础
#

  1. UML 是统一建模语言（Unified Modeling Language）的缩写，是一种用于软件系统分析和设计的标准化建模语言。可视化、详述、构造、文档化
    1734702026206
    1734704969926
  2. UML 语法（图的画法）
    1734752796427

4 个重要的 UML 图
#

  1. 用例图 Use Case Diagram 用例图是从用户角度描述系统功能，是用户所能观察到的系统功能的模型图，用例是系统中的一个功能单元。 用例图列出系统重的用例和系统外的参与者，并显示哪个参与者参与了哪个用例的执行（或称为发起了哪个用例）。

    • 参与者 Actor：在系统外部与系统直接交互的人或事物
    • 用例 Use Case：系统外部可见的一个系统功能单元。系统的功能由系统单元所提供，并通过一系列系统单元与一个或多个参与者之间交换的消息所表达。
      1734753189271
      用例图中的关系（边）及解释
      1734753380330
      泛化：箭头指向的为一般化 包含：箭头指向的为包含，必须执行 扩展：箭头指向的为扩展，可选执行

  2. 类图 Class Diagram 类图以反映类的组成（属性、操作），以及类之间的关系为主要目的，描述了软件系统的静态结构，是一种静态建模方法。类图包括类的内部结构和类之间的联系（关联、依赖、聚合等）。类是对现实世界中的事物（对象）的抽象。

    类图中的术语及解释

    类名：斜体为抽象类

    属性：属性名：属性类型, + 表示 public，- 表示 private，# 表示 protected，缺省值

    操作：操作名(参数列表:参数类型)：返回类型，+ 表示 public，- 表示 private，# 表示 protected，斜体为抽象操作

    1734753968594

    • 接口：一组操作的集合，只有操作的声明，没有操作的实现
    • 抽象类：不能实例化，只能作为其他类的父类，一般至少包含一个抽象操作
    • 模版类：一种参数化的类，在编译时把模版参数绑定到不同的数据类型，从而产生不同的类
      1734754194300

    类图中的关系及解释

    1. 关联关系：描述了类的结构之间的关系，具有方向、名字、角色和多重性等信息
      • 一般关联：1...* 表示 1 至多个，0...1 表示 0 至 1 个；双向关联省略箭头
      • 聚合关系：Aggregation，指明一个聚集（整体）和组成部分之间的关系。类图包含有实物和关系，类图不存在了，实物和关系还可用于其它的类图。
      • 组合关系：Composition，语义更强的聚合，部分和整体具有相同的生命周期。类与关联关系之间有了组合关系，类不存在了，则相应的关联关系也不存在了。
        1734754646473
        1734754687582
    2. 泛化关系：在面向对象中一般称为 继承关系，存在与父类与子类、付接口与子接口之间
      1734754756779
    3. 实现关系：对应于类和接口之间的关系，类 Circle、Rectangle 实现了接口 Shape
      1734754816352
    4. 依赖关系：描述了一个类的变化对依赖它的类产生影响的情况。例如绑定（bind）、友元（friend）等
      1734754919484

    类图与代码的映射 类的映射、关联关系的映射、泛化关系的映射（class SavingsAccount:public Accout）、实现关系的映射（class Circle : public Shape, virtual void Draw();）、依赖关系的映射（模版类）

  3. 顺序图 Sequence Diagram 顺序图用来表示 用例中的行为顺序，当执行一个用例行为时，顺序图中的每条消息对应了一个类操作或状态机中引起转换的事件。顺序图展示对象之间的交互，属于 动态建模。顺序图的重点在 消息序列 上。 浏览顺序图的方法是 从上到下 查看对象间交换的消息。

    1734755478532
    顺序图中的术语及解释

    • 消息格式：operation(parameter list)，向哪个对象发送消息，实际上就是调用它的类中的操作
    • 窄长方框用以强调这个部分处于活动状态
    • 对象生命线表示从上到下的时间顺序，消息 1 在消息 2 之前发生，消息 2 在消息 3 之前发生
      1734755579289
      购票用例的顺序图：
      1734755799257

  4. 状态图 Statechart Diagram 状态图说明对象在它的生命期中响应事件所经历的状态序列，以及它们对那些事件的响应，状态图用于揭示 Actor、类、子系统和组件的复杂特性，为 实时系统建模。

    状态图的组成

    • 状态，对象的状态是指在这个对象的 生命期中的一个条件或状况，在此期间对象将满足某些条件、执行某些活动，或等待某些事件。
    • 转移，是 由一种状态到另一种状态的迁移。这种转移由被建模实体内部或外部事件触发。对一个类来说，转移通常是调用了一个可以引起状态发生重要变化的操作的结果。

    状态图中的术语及解释

    1734756101033

    状态的可选活动表

    1734756171370
    1734756222735

Chapter 4 软件需求分析
#

UML 分析模型
#

  1. UML 分析模型的三个视图

    • 功能模型：描述处理（数据变换），指明系统应该做什么 Use Case Diagram
    • 对象模型：描述静态结构，定义做事情的实体 Class & Object Diagram
    • 动态模型：描述交互过程，规定什么时候做何事 Sequence,State Diagram

  2. 面向对象分析的本质 3 个模型（功能、对象、动态），5 个层面（主题、类和对象、结构、属性、服务）

  3. 典型用例建模方法（Use Case Diagram） 从和系统有交互的实体（外部用户）角度出发，描述系统应该具备哪些功能。

    • 系统边界：包围用例的方框，表示系统的范围，边界内的用例表示系统将来要实现的功能。
    • 参与者：在系统边界之外，透过系统边界与系统进行有意义的交互的任何人或事物。
    • 用例：由系统执行的一个动作序列，给 角色(actor) 提供一项有价值的服务。
    • 关系：角色和用例、角色之间、用例之间有意义的 联系。

    Use Case 图的建立步骤

    • (1) 找出系统外部的参与者和外部系统，确定系统的边界和范围；
    • (2) 确定每一个参与者所期望的系统行为；
    • (3) 把这些系统行为命名为 Use Case；
    • (4) 用泛化、包含、扩展等关系处理系统行为的公共或变更部分；
    • (5) 编制和解释每一个 Use Case 的脚本；
    • (6) 绘制 Use Case 图；
    • [(7)] 区分主事件流和异常情况的事件流，可以把表示异常情况的事件流作为单独的 Use Case 处理；
    • (8) 细化 Use Case 图，解决 Use Case 间的重复与冲突问题。

  4. 类建模方法（Class Diagram）

    The key is finding objects

    如何提取类和对象？

    主题、类和对象、属性、服务、结构 主题是一种比类和对象抽象层次更高、粒度更大的概念，用以建立系统的高层抽象视图；中小型系统可只设一层主题，最多不超过两层；大型系统可只设两层主题，最多不超过三层。

    1734757456644

  5. 动态模型（Sequence, State Diagram)

    用来描述系统与时间相关的动态行为即系统的控制逻辑，表现对象彼此间经过相互作用后，随时间改变的不同运算顺序。 动态模型以“事件”（Events）和“状态”（States）为其模型的主要概念。

需求规范（Requirements Specification）
#

需求工程（Requirements Engineering）包括：Part 1：需求分析；Part 2：需求规范

Requirements Specification 目的：

  • To provide a representation of the software for the customer’s review and approval
  • Developed as a joint effort between the developer and the customer
  • Serve as basis for review for both customer and developer
  • Direct software design and development
  • Culmination of requirements analysis

Requirements Specification 质量：

  • (1) unambiguous（明确的）
  • (2) complete（完整的）
  • (3) verifiable（可验证的）
  • (4) consistent（一致的）
  • (5) modifiable（可修改的）
  • (6) traceable（可追踪的）

Requirements Specification 的方法：

  • 可混合使用的模型：DFD、ERD、DD…Use Case、Class Diagram、Sequence Diagram…
  • 使用但不限于面向结构，面向对象方法
  • IPO 图，在计算机领域 IPO 是指结构化设计中变换型结构的输入（Input）、加工（Processing）、输出（Output）。IPO 图是对每个模块进行详细设计的工具，它是输入加工输出(INPUT PROCESS OUTPUT)图的简称。

需求规格说明书

# 1. 引言

- 1.1 系统的目的
- 1.2 系统范围
- 1.3 项目的目标与成功标准
- 1.4 定义、缩略语和缩写
- 1.5 参考文献
- 1.6 概述

# 2. 当前系统

# 3. 提议的系统

- 3.1 概述
- 3.2 功能需求
- 3.3 非功能需求
  - 3.3.1 可用性
  - 3.3.2 可靠性
  - 3.3.3 性能
  - 3.3.4 可维护性
  - 3.3.5 实施
  - 3.3.6 接口
  - 3.3.7 包装
  - 3.3.8 法律
- 3.4 系统模型
  - 3.4.1 场景
  - 3.4.2 用例模型
  - 3.4.3 对象模型
  - 3.4.4 动态模型
  - 3.4.5 用户界面

# 4. 术语表

Chapter 5 总体设计
#

总体设计基础概念
#

  1. 软件需求 VS 软件设计

    • 软件需求解决的是“做什么”的问题，软件设计解决的是“怎么做”的问题
    • 软件设计分为 总体设计 和 详细设计
    • 软件需求：分析模型；软件设计：设计模型

  2. 总体设计 VS 详细设计

    • 总体设计：确定软件的结构以及各组成部分（子系统或模块）之间的相互关系
      • 总体设计的任务：将复杂系统按功能 分成模块、确定每个模块的功能和模块之间的 调用关系、块间传递的信息、评价模块结构的质量。
    • 详细设计：确定模块内部的算法和数据结构，产生描述各模块程序过程的详细文档
      • 详细设计的任务：为每个模块进行详细的 算法设计，用某种图形、表格、语言等工具将每个模块吹了过程的详细算法描述出来；为模块内的 数据结构进行设计；对数据库进行物理设计（确定数据库的物理结构）；

  3. 什么是软件体系结构？

    • 软件体系结构定义了软件局部和总体计算部件的 构成。从整体看，软件体系结构是由结构- 和功能各异、相互作用的部件集合，按照层次构成的。
    • 软件体系结构定义了组成部件之间的相互作用 关系。
    • 软件体系结构定义了构成系统的合成原理、方法、原则
    • 软件体系结构定义了构成系统应该遵守的 约束 的条件。

  4. 总体设计的任务：

  • 确定软件的组成
  • 确定各组成部分的相互关系
  • 确定软件的运行模式
  • 确定软件的若干原则
  1. 软件设计方法：
  • 结构化设计方法(SD)
  • 面向对象的设计方法(OOD)
  • 面向数据结构的设计方法(JSD 方法)

  1. 评估准则：经验启发式规则、模块化、抽象、信息隐蔽、信息局部化

    什么是好的软件体系结构：模块化（Modularization）、抽象（Abstraction）、信息隐蔽（Information Hiding）、注意点分散(Separation of Concerns)、耦合和内聚 (couple and cohesion)、策略和实现的分离 (separation of police and implementation)、接口和实现的分离 (separation of interface and implementation)、分而制之(Divide-and-conquer)、层次化 (hierarchy)

  2. 总体结构的设计方法

    1. 根据经验划分子系统结构：根据待解决的问题 特点 和用户需求

    2. 结构模式或风格：Architectural Pattern or Style。单机、多机、网络、集中式、分布式、客户端/服务器（表示层、功能层、数据层）

      • 胖客户机和瘦客户机
        1734762539882
      • 三层 B/S 结构
        1734762586126
      • 分布式对象体系结构：对象之间不存在客户机和服务器的界限，接收服务者扮演客户机角色，提供服务者就是服务器；对象可能分布在网络的多个计算机上，通过中间件相互通信
        1734762699190

    3. 由 DFD 图导出总体结构

      I-> P-> O 自顶向下，逐步细化

      1734762814592

      最顶层的控制模块 Cm 协调下述从属的控制功能：

      • （1）输入信息处理控制模块 Ci，协调对所有输入数据的接收；
      • （2）变换中心控制模块 Ct，管理对内部形式的数据的所有操作；
      • （3）输出信息控制模块 Co，协调输出信息的产生过程。

    4. 由类图导出总体结构

总体设计的原则
#

模块化原理
#

  • 模块化（Modularization）

    suppose P1, P2 be two problems,
    function C(x) stands the complexity of problem x,
    function E(x) represents the cost of solving problem x,
    if C(P1) > C(P2)
    Then E(P1) > E(P2)
    Experiential rule:
    C(P1+P2) > C(P1) + C(P2)
    E(P1+P2) > E(P1) +E(P2)

  • 抽象（Abstraction）

    Abstractions allow you to understand the essence of a subsystem without having to know unnecessary details

  • 信息隐蔽（Information Hiding）

    模块中所包含的信息（包括数据和过程）不允许其它不需要这些信息的模块使用。
    设计模块时，应使得一个模块内包含的信息（数据和过程）对于不需要这些信息的模块来说，是不能访问的。

  • 模块独立（Module Independence）

    • 耦合（Coupling）：对一个软件结构内不同模块间互连程度的度量。模块间的连接有 调用、返回、进入、跳出 等

      1734763771187

      • 无直接耦合：如果两个模块之间没有直接关系，它们之间的联系完全是通过主模块的控制和调用来实现的，这就是非直接耦合。这种耦合的 模块独立性最强。
      • 数据耦合：一模块调用另一模块时，被调用模块的输入、输出都是简单的数据(若干参数)。属于 松散耦合。
      • 控制耦合：一模块向下属模块传递的信息 (开关量、标志等控制被调用模块决策的变量) 控制了被调用模块的内部逻辑。可以将被调用模块的判定上移到调用模块中进行，改控制耦合为数据耦合。
      • 公共耦合（公共数据区耦合）：一组模块引用同一个公用数据区，全局变量
      • 内容耦合：一个模块直接访问另一个模块的内部数据结构，或者直接调用另一个模块的内部子程序。最不好的耦合形式。

    • 内聚（Cohesion）：标志一个模块内各个处理元素彼此结合的紧密程度，理想的内聚模块只做一件事情。

      • 功能内聚：模块内的所有元素都是为了完成一个功能而设计的，缺一不可，内聚性最强
      • 过程内聚，顺序内聚
      • 时间内聚（经典内聚）：模块完成的功能在同一时间内执行，这些功能只因时间因素关联在一起。
        1734764266314

追求：

  • 高内聚、低耦合
  • 低耦合：尽量使用数据耦合，少用控制耦合，限制公共耦合的范围，坚决避免使用内容耦合。
  • 高内聚：优先使用功能内聚，尽量满足过程内聚，少用逻辑内聚，坚决避免偶然内聚。

模块独立性度量
#

  • 深度：表示软件结构中控制的层数，它能粗略表示软件的复杂程度。
  • 宽度：表示软件结构同一层内的模块总数。宽度越大系统越复杂，对宽度影响最大因素是模块的扇出。宽度太大可增加深度来减少。
  • 扇出数：是一个模块直接控制（调用）的模块数目（5-9）。扇出越大模块越复杂。
  • 扇入数：是直接调用的上级模块数（3-5）。扇入太大会增加模块接口数，违背模块独立性原则。
  • 上级模块
  • 下级模块

模块的作用域应该在控制域之内：

  • 模块的作用域：是指受该模块判定影响的所有模块数。
  • 模块的控制域：是受这个模块直接或间接控制调用的模块数。
  • 模块的控制范围：本身及其 所有下级模块。
  • 模块的作用范围： 即 直接调用 的模块

Chapter 6 详细设计
#

详细设计初认识
#

Detailed design = data structure+ algorithm

  • 软件定义阶段定义了问题结构，叫作软件设计的 一级蓝图。可用系统流程图表示、或数据流图表示、或用结构化语言表示、或以形式化软件设计语言表示。
  • 软件总体设计确定了软件结构，即确定模块的划分、模块间的接口。可称作软件设计 二级蓝图。用结构图、Jackson 结构图、Warnier 图来表示、或用 HIPO 图来表示。
  • 软件详细设计（也称软件算法设计、软件过程设计、软件逻辑设计）确定每个软件模块的实现算法，可称软件设计的 三级蓝图。可用 程序流程图描述、或用伪码描述。

OOA & OOD

1734765441492

软件复用（Reuse）
#

  1. 软件复用的层次：

    • 知识重用
    • 方法和标准重用
    • 软件成分重用：项目计划、成本估算、体系结构、需求模型和规格说明、设计方案、源代码、用户文档和技术文档、用户界面、数据

  2. 面向对象设计的重用机制

    • 传统上：内部函数
    • 面向对象：内部类（类构件）
      • 实例重用
      • 继承重用
      • 多态重用

详细设计的描述
#

  1. 程序流程图（Program Flow Chart）：顺序、选择、循环。优点：简单直观；缺点：全局结构、数据结构难表示

    1734765918320

  2. N-S 盒图：顺序、IF-THEN-ELSE 分支、CASE 分支、循环、调用。

    1734766038900
    特点：

    • （1）功能域（即某一具体构造的功能范围）有明确的规定，并且很只观地从图形表示中看出来；

    • （2）想随意分支或转移是不可能的；

    • （3）局部数据和全程数据的作用域可以很容易确定；

    • （4）容易表示出递归结构。

      1734766259505

      Do while C1
      if C2
          if C3
              Do
                  S1;
                  if C5
                      S3;
                  else
                      S2;
                   endif
                   S4;
                until C4
                S5;
            endif
         endif
 enddo

Chapter 7 编码或实现
#

  1. 编码阶段的两个重要决策

    • 选择编程语言
    • 选择编码标准或风格

  2. 编程语言的分类

    • 机器语言
    • 汇编语言
    • 高级语言
      1734767094911

  3. C++编程阶段：编译、链接、执行

    1734767129278

  4. 编码风格具体体现

    • 标识符（符号名、变量名）的风格
    • 注释的风格
      • 序言性注释：给出程序的整体说明
      • 功能性注释：嵌在源程序体中，用以描述其后的语句或程序段是在做什么工作
    • 数据说明的风格
    • 语句结构的风格
    • 输入 ／ 输出的风格
    • 程序 layout 风格

  5. 程序复杂性的度量

    • 程序复杂性： 模块内程序代码的复杂程度，例如行数，if 条件判断的个数，loop 循环的圈数等。

    • 算法的时间复杂性（执行的步数）和空间复杂性（占用的存储空间）

    • 复杂性度量方法

      • 代码行度量法

      • McCabe 度量法：计算环路复杂性的方法：根据图论，在一个强连通的有向图 G 中，环的个数由以下公式给出： V(G)＝ m－n ＋ p， 其中，V(G) 是图 G 中环路个数，m 是图 G 中弧数，n 是图 G 中结点数，p 是图 G 中的强连通分量个数。

      • Halstead 的软科学法：度量操作码，操作数；运算符，运算对象

        • 预测方法： n1 表示程序设计时不同运算符(包括保留字)的个数， n2 表示程序设计时不同运算对象的个数， H 表示“程序长度”，则有 H=n1×log2 n1+n2 × log2n2 H 是程序长度的预测值

Chapter 8 软件测试
#

测试在软件开发中非常重视 The biggest cost in software development

软件测试是为了发现错误而运行一个软件的过程。

软件测试基本概念
#

  1. 软件测试的定义或目标（狭义）
    • 测试是为了发现程序中的错误而执行程序的过程
    • 一个好的测试用例 是发现了至今未发现错误的用例
    • 一次成功的测试 是发现了至今未发现错误的测试
    • 程序测试能证明错误的存在, 但不能证明错误不存在。
    • 测试的目的是发现程序中的错误，为了证明程序有错, 而不是证明程序无错。
  2. 软件测试的定义或目标（广义）：用于确保软件符合其规范并满足用户要求的过程 Verification vs. validation
    • Validation: Are we building the right product?The software should do what the users really require
    • Verification: Are we building the product right?The software should conform to its specification
    • V & V must be applied at each stage in the software process.

软件测试的两个方法
#

1734768719528

静态测试 Static Test
#

  • 基本特征是在对软件进行 分析、检查和审阅，不实际运行 被测试的软件。
  • 静态测试约可找出 30 ～ 70%的 逻辑设计 错误.
  • 对需求规格说明书、软件设计说明书、源程序做检查和审阅，包括：
    • 是否符合标准和规范
    • 通过结构分析、流图分析、符号执行指出软件缺陷

动态测试 Dynamic Test
#

  • 通过运行被测程序来检验软件的动态行为和运行结果的正确性
  • 动态测试的两个基本要素：
    • 被测试程序
    • 测试用例（测试数据）

  1. 动态黑盒测试（闭着眼睛测试软件） 黑盒测试，也叫功能测试，是指测试人员不需要了解程序的内部实现，只关注系统的输入与输出，测试系统是否按照需求文档的要求正确执行。

    • 不深入代码细节 的测试方法称为动态黑盒测试。
    • 软件测试员充当 客户 来使用它。
      1734769012513

    黑盒测试样例的设计方法：

    • 等价类划分法：将输入数据划分为若干个等价类，从每个等价类中选取一个数据作为测试数据。Equivalence analysis is the most widely used approach.
      • 有效等价类：用于实现功能和性能的测试
      • 无效等价类：用于测试那些所实现的功能和性能不符合规格说明书的要求
        1734770070873
    • 边界测试：更多错误往往会发生在输入域的边界。
      • 边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件。
      • 边界值分析不仅考虑输入条件，还要考虑输出空间产生的测试情况
      • 测试边界上的合法数据, 以及刚超过边界的非法数据
    • 错误推测法：根据经验、直觉和预感进行测试。缺省值、空白、空值、零、无输入条件
    • 因果图法：相互组合，适合 有多个输入条件的组合，根据输入和输出之间的因果关系，构造因果图，从而设计测试用例
    • 自动软件测试：人工测试耗时、需要回归测试，自动测试可以提高效率、减少人力成本

  2. 动态白盒测试（带 X 光眼镜测试软件） 白盒测试，也叫结构测试或透明盒测试，是指测试人员对被测试软件的内部结构、算法、代码逻辑等有充分的了解，基于程序的内部工作原理来 设计和执行测试用例。

    1734769004218
    1734769221325

    白盒测试的样例设计规则：

    • 语句覆盖：每个语句至少执行一次
    • 判定覆盖：每个判定的每个分支至少执行一次
    • 条件覆盖：每个判定的每个条件的每个取值至少执行一次
    • 判定/条件覆盖：每个判定的每个条件的每个取值至少执行一次，且每个判定的每个分支至少执行一次
    • 条件组合覆盖：每个判定的每个条件的每个取值至少执行一次，且每个判定的每个条件的每个组合至少执行一次
    • 路径覆盖：每个程序路径至少执行一次
    • 点覆盖：每个判定的每个条件的每个取值至少执行一次，且每个判定的每个条件的每个组合至少执行一次，且每个程序路径至少执行一次，It is equal to statement coverage
    • 边覆盖：每个程序的每条边至少执行一次，It is equal to branch coverage

    1734768986799

软件测试的过程
#

软件测试的过程，即软件集成、形成过程：

  • 单元测试：集中对用 源代码 实现的, 每一个程序单元进行测试，检查各个程序模块是否正确地实现了规定的功能。

  • 集成测试：把已测试过的模块组装起来，主要对与设计相关的软件 体系结构 的构造进行测试。

    1734770968403

    • 模块组装集成方式

      • 一次性组装方式：整体拼装，一次性测试
      • 增殖式组装方式：逐步组装成较大的系统，边组装边测试

    • 增殖式组装方式

      • 自顶向下的增殖方式
      • 自底向上的增殖方式：从程序模块结构的最底层的模块开始组装和测试。
      • 混合增殖式测试：首先对 I/O 模块和关键算法模块进行测试，再自底向上组装成完整且独立的子系统，再由主模块开始自顶向下进行增殖测试

  • 确认测试：检查已实现的软件是否满足了 需求规格说明 中确定了的各种需求，以及软件配置是否完全、正确。

    • 有效性测试（黑盒测试）
    • 软件配置复查
    • Alpha 测试，Beta 测试
      • α 测试是由一个开发者在 开发环境下 进行的测试，也可以是 公司内部的用户 在模拟实际操作环境下进行的测试。
      • β 测试是由软件的多个用户，在 实际使用环境下 进行的测试。这些用户 返回有关错误信息给开发者。
    • 验收测试
      1734771302895

  • 系统测试：把经过确认的软件纳入 实际运行 环境中，与其它系统成份组合在一起进行测试。

    1734770714620

  • 功能测试、非功能测试

    1734771438195

  • 其他测试：性能、恢复测试、配置测试、安全性测试、安装测试、兼容测试等等

停止测试条件
#

Testing is a trade-off between budget, time and quality.

可靠性分析
#

可靠性：reliability of software 程序在给定的 时间间隔 内，按照规格说明书的规定，成功运行的概率。

可用性：usability of software 程序在给定的 时间点，按照规格说明书的规定，成功运行的概率。

公式： $$A_{use}=\frac{T_{up}}{T_{up}+T_{down}}$$ $$A_{use}=\frac{MTTF}{MTTF+MTTR}$$

  • MTTF: 平均无故障时间
  • MTTR: 平均修复时间

MTTF 的计算

  • 符号表示

    符号含义
    ETtotal error before testing
    ITsize of program to be tested
    τtime used by testing
    Ed(τ)found errors in [0, τ]
    Ec(τ)corrected errors in [0, τ]

  • 两个基本假定

    • $$ 0.005 <= ET / IT <= 0.02 $$
    • $$ MTTF \propto 1 / \text{hidden bugs} $$

  • 计算公式

$$ \text{MTTF} = \frac{1}{K \left( \frac{E_T}{I_T} - \frac{Ec(\tau)}{I_T} \right)} $$

其中： ( K = 200 )

$$ Ec = ET - \frac{I_T}{K \times MTTF} \quad \text{(stop rule)} $$

Predicting total errors(ET)

  • 植入法：在程序中植入错误

    符号含义
    ( N_p )number of errors planted
    ( n_p )number of errors found within ( N_p )
    ( n )found new errors
    ( N )total number of errors

    $$\frac{N}{n}=\frac{N_p}{n_p} => \frac{n_p}{N_p}=\frac{n}{N}$$ $$N=N_p\times\frac{n}{n_p}$$

  • 分别测试法：区分标记故障和非标记故障

    符号含义
    ( N_1 )found errors by person 1 （标记故障）
    ( N_2 )found errors by person 2 （非标记故障，潜在故障）
    ( n_b )found errors by both person1 and person 2

    $$N=N_1 \times N_2 / n_b$$

调试
#

测试是识别错误的症状，调试是识别错误的原因。

1734773074297
Debugging

  • 软件调试是在进行了成功的测试之后才开始的工作.
  • 调试的任务是进一步诊断和改正程序中潜在的错误
  • 调试活动由两部分组成：性质原因和位置, 修改排除这个错误
  • 调试工作是一个具有很强技巧性和经验性的工作
  • 调试是通过现象，找出原因的一个思维分析的过程
  • 通过 debuger 工具来进行
  • Most integrated development environments, such as JBuilder, include a debugger.

几种主要的调试方法

  • 强行排错法：内存打印、设置打印语句，跟踪程序执行过程
  • 回溯法调试：小程序常用，人工沿着程序的控制流程回溯源代码，找出错误根源
  • 归纳法调试：从一些线索(错误征兆)着手，通过分析它们之间的关系来找出错误。
    1734773254896
  • 演绎法调试：演绎法是一种从一般原理或前提出发，经过排除和精化的过程来推导出结论的思考方法。演绎法排错是测试人员首先根据已有的测试用例，设想及枚举出所有可能出错的原因做为假设；然后再用原始测试数据或新的测试，从中逐个排除不可能正确的假设；最后，再用测试数据验证余下的假设确是出错的原因。
    1734773298643

Chapter 9 软件维护
#

软件的变化是不可避免的，关键是采取适当的策略，有效地实施和管理软件的变化！

软件维护的概念
#

  • 软件维护是软件开发工作完成以后，在用户使用期间，对软件所做的补充、修改和增加工作。
  • 软件运行 ＝ 软件维护
  • 在软件维护中，为 增加和改进软件的功能 所做的维护占 80%，而为改正错误所做的维护仅占 20%。
  • 统计数据表明：实际上用于软件维护的费用占软件总费用的 55-80%。
  • 软件维护比软件开发更困难，需要更多的创造性工作。
  • 一般不涉及体系结构的重大变化

软件维护的类型
#

  • 改正性维护：目的是识别和矫正功能 错误、性能 错误 和实现上的 错误。
    • Emergency Repairs
    • Scheduled Repairs
  • 适应性维护：使软件适应于 外界环境的改变 而对软件所做的修改工作。
  • 完善性维护：为了 扩充软件的功能 或改善软件的性能对软件所做的改变。
  • 预防性维护：为了 以后 更便于维护，或者为了改进可靠性，或者提供更好的基础便于将来提高性能而修改软件。可视为彻底的完美维护或维护的替代方案，Software Re-engineering

可维护性（Maintainability）
#

软件可维护性是指软件被理解、改正、调整和改进的程度

1734773965465
提高可维护性可以通过进行明确的质量保证审查、改进程序的文档、提倡标准化、规范化开发

再工程（Re-engineering）
#

1734774117912

Chapter 10 软件项目管理
#

项目是指为创建一个唯一的产品，或者提供唯一的服务而进行的努力活动。

项目的特点： 目标性、周期性、约束性、不确定性

软件项目的特点：

  • 对象：作为逻辑产品的软件
  • 过程：不是以制造为主，无重复生产过程
  • 属性：成本、进度、质量难以度量和估算
  • 易变性：软件需求通常难以确定且经常变
  • 复杂性：作为逻辑产品，复杂性非常高

软件项目管理的基本概念
#

软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动。

团队分工
#

1734774579158

相关概念
#

  • 基线（BaseLine）是已经通过了正式复审的规格说明或中间产品，它可以作为进一步开发的基础，并且只有通过正式的变化控制过程才能改变。基线标志着软件开发过程的各个里程碑（Milestone）。
    1734774667651
  • ISO 9000：质量保证体系, 用于实现质量管理的组织结构、责任、规程、过程和资源。
    1734774748293
  • CMM
    • 名称：Capability Maturity Model for Software
    • 目的：Improving the Software Development Process
      1734774836104

THE END

相关文章

2024 12 04
·471 字·1 分钟· loading
日常 太阳照常升起 步履不停
2024 11 07
·237 字·1 分钟· loading
日常 太阳照常升起 步履不停
Tongji-DORM-WIFI自动登录
·1941 字·4 分钟· loading
工具 网络 同济
Follow,下一代的聚合信息浏览器
·1406 字·3 分钟· loading
软件推荐 阅读
【书评】变形记
·533 字·2 分钟· loading
书评
【书评】组织部来了个年轻人
·823 字·2 分钟· loading
书评