高项第一章-第四节：软件工程 思维导图

这是一篇关于高项第一章-第四节：软件工程的思维导图，可以帮助您理解熟悉关于软件工程的知识要点，加强记忆，非常实用。

第一章：信息化和信息系统：软件工程

• 1.4.1需求分析
  • 三层次
    • ①业务需求：高层次的
    • ②用户需求：具体的
    • ③系统需求
      • a.功能需求
        • 必须实现的功能，用户利用此功能来满足业务需要
      • b.非功能需求（隐性）
        • 系统必备的属性或品质，如可维护性等
      • c.设计约束：如必须采用X数据库或X操作系统
  • 质量功能部署：将用户要求转化成软件需求的技术，其目的是最大限度地提升软件工程过程中用户的满意度。
    • ①常规需求：用户认为系统应该作到的功能，实现越多用户越满意
    • ②期望需求：用户想当然认为系统应该具备的功能，但并不能正确描述，若没有则用户不满
    • ③意外需求：用户要求范围外的功能（但软件开发人员很乐意赋予），可以得到高满意、高忠诚的用户
  • 需求获取：确定和理解不同的项目干系人的需求和约束的过程。
    • 方法：用户访谈、问卷调查、采样、情节串联板、联合需求计划等。
  • 需求分析
    • SA方法
      • 建立模型的核心是数据字典，分3层次
        • ①数据模型——实体联系图(E-R图)
        • ②功能模型——数据流图（DFD）
        • ③行为模型——状态转换图（STD）
  • 软件需求规格说明书（SRS）：编制该文档的目的是使项目干系人与开发团队对系统的初始规定有一个共同的理解，使之成为整个开发工作的基础。
    • 内容
      • ①范围
      • ②引用文件
      • ③需求
      • ④合格性规定
      • ⑤需求可追踪性
      • ⑥尚未解决的问题
      • ⑦注解
      • ⑧附录
  • 需求验证（需求确认）
  • 统一建模语言（UML）
    • 定义：通用的可视化建模语言，它是面向对象分析和设计的一-种标准化表示，用于对软件进行描述、可视化处理、构造和建立软件系统的文档。支持从需求分析开始的软件开发全过程，独立于软件开发过程。
    • 组成：构造块、规则和公共机制
    • 14种图
      • 结构图
        • 类图
          • 描述一组类、接口、协作和它们之间的关系。在00系统的建模中，最常见的图就是类图。类图给出了系统的静态设计视图。
        • 组合结构图
          • 描述结构化类（例如，构件或类）的内部结构
        • 构件图
          • 描述一个封装的类和它的接口、端口，以及由内嵌的构件和连接件构成的内部结构。构件图用于表示系统的静态设计实现视图。
        • 部署图
          • 描述对运行时的处理节点及在其中生存的构件的配置。部署图给出了架构的静态部署视图，通常一个节点包含一个或多个部署图。
        • 制品图
          • 描述计算机中一个系统的物理结构。制品包括文件、数据库和类似的物理比特集合。制品图通常与部署图一起使用。制品也给出了它们实现的类和构件。
        • 对象图
          • 描述一组对象及它们之间的关系。这些图给出系统的静态设计视图或静态进程视图。
        • 包图
          • 描述由模型本身分解而成的组织单元，以及它们之间的依赖关系。
      • 行为图
        • 活动图
          • 将进程或其他计算结构展示为计算内部一步步的控制流和数据流。活动图专注于系统的动态视图。它对系统的功能建模和业务流程建模特别重要，并强调对象间的控制流程。
        • 交互图：它由一组对象或参与者以及它们之间可能发送的消息构成。
          • 顺序图
            • 强调消息的时间次序的交互图。
          • 通信图
            • 它强调收发消息的对象或参与者的结构组织。
          • 交互概览图
            • 活动图和顺序图的混合物
          • 定时图
            • 它强调消息跨越不同对象或参与者的实际时间，而不仅仅只是关心消息的相对顺序。
        • 用例图
          • 描述一组用例、参与者及它们之间的关系。用例图给出系统的静态用例视图。
        • 状态图
          • 状态图描述一个状态机，它由状态、转移、事件和活动组成。状态图给出了对象的动态视图。它对于接口、类或协作的行为建模尤为重要，而且它强调事件导致的对象行为，这非常有助于对反应式系统建模。
    • 五个系统视图
  • 面向对象分析
    • 任务：运用00方法,对问题域进行分析和理解，正确认识其中的事物及它们之间的关系，找出描述问题域和系统功能所需的类和对象;定义它们的属性和职责，以及它们之间所形成的各种联系。最终产生一个符合用户需求，并能直接反映问题域和系统功能的0OA模型及其详细说明。
    • 不考虑与系统具体实现有关的因素：00A（面向对象分析）的任务是“做什么, 00D（面向对象设计）的任务是“怎么做"。
    • 核心工作：建立系统的用例模型与分析模型。
    • 用例之间的关系
      • ①包含关系：当可以从两个或两个以上的用例中提取公共行为时,应该使用包含关系来表示它们。其中这个提取出来的公共用例称为抽象用例，而把原始用例称为基本用例或基础用例。（如新、删、改，的公共行为是查）
      • ②扩展关系：如果一个用例明显地混合了两种或两种以上的不同场景，即根据情况可能发生多种分支，则可以将这个用例分为一个基本用例和一个或多个扩展用例,这样使描述可能更加清晰。
      • ③泛化关系：当多个用例共同拥有一种类似的结构和行为的时候，可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。在用例的泛化关系中，子用例是父用例的一种特殊形式，子用例继承了父用例所有的结构、行为和关系。
    • 类之间的关系
      • ①关联关系：关联提供了不同类的对象之间的结构关系，它在一段时间内将多个类的实例连接在一起。关联体现的是对象实例之间的关系，而不表示两个类之间的关系。
      • ②依赖关系：依赖关系。两个类A和B，如果B的变化可能会引起A的变化，则称类A依赖于类B。
      • ③泛化关系：泛化关系描述了一般事物与该事物中的特殊种类之间的关系，也就是父类与子类之间的关系。继承关系是泛化关系的反关系，也就是说，子类继承了父类，而父类则是子类的泛化。
      • ④共享聚集（车子与车轮）：即聚合关系，它表示类之间的整体与部分的关系，其含义是“部分”可能同时属于多个“整体”，“部分”与“整体”的生命周期可以不相同。例如，汽车和车轮就是聚合关系。车子坏了，车轮还可以用，车轮坏了，可以再换一个新的。
      • ⑤组合聚集（公司与部门）：即组合关系，它也是表示类之间的整体与部分的关系。与聚合关系的区别在于，组合关系中的“部分”只能属于一个“整体”，“部分”与“整体”的生命周期相同，“部分”随着“整体”的创建而创建，也随着“整体”的消亡而消亡。
      • ⑥实现关系：实现关系将说明和实现联系起来。接口是对行为而非实现的说明，而类中则包含了实现的结构。一个或多个类可以实现一个接口，而每个类分别实现接口中的操作。
• 1.4.2软件架构设计
  • 软件架构风格
  • 软件架构评估
    • • 基于场景
• 1.4.3软件设计
  • 结构化设计
    • 特点
      • ①面向数据流
      • ②以SRS和SA阶段的DFD与数据字典为基础
      • ③自顶向下、逐步求精、模块化
    • 基本思想：将软件设计成由相对独立且具有单一功能的模块组成的结构
      • 概要设计&详细设计
    • 原则：高内聚，低耦合，模块间低耦合，模块内高内聚。
  • 面向对象设计
    • 基本思想：抽象、封装和可扩展性，其中可扩展性主要通过继承和多态来实现。
    • 主要任务：类和对象进行设计，包括类的属性、方法，以及类与类之间的关系。
    • 核心问题：提高软件可复用性，同时提高可维护性
  • 设计模式：前人经验的总结，它使人们可以方便地复用成功的软件设计。设计模式包含模式名称、问题、目的、解决方案、效果、实例代码和相关设计模式等基本要素。
    • 按范围分
      • 类模式
        • 处理类和子类之间的关系，这些关系通过继承建立，在编译时刻就被确定下来，属于静态关系;
      • 对象模式
        • 处理对象之间的关系，这些关系在运行时刻变化，更具动态性。
    • 按目的和用途分
      • 创建型模式
        • 用于创建对象
      • 结构型模式
        • 处理类或对象的组合
      • 行为型模式
        • 描述类或对象的交互以及职责分配
• 1.4.4软件工程的过程管理
  • 能力成熟度模型集成
    • 阶段式模型
    • 连续式模型
• 1.4.5软件测试及其管理
  • 测试用例构成
    • 名称和标识
    • 测试追踪
    • 用例说明
    • 测试的初始化要求
    • 测试的输入
    • 期望的测试结果
    • 评价测试结果的标准
    • 操作过程
    • 前提和约束
    • 测试终止条件
  • 测试方法
    • 静态测试：被测试程序不在机器上运行，而采用人工检测和计算机辅助静态分析的手段对程序进行检测。
      • 文档-检查单
      • 代码-桌前检查/代码走查/代码审查
    • 动态测试：计算机上实际运行程序进行软件测试
      • 白盒测试
        • 将程序看作是一个透明的白盒，测试人员完全清楚程序的结构和处理算法，按照程序内部逻辑结构设计测试用例。
      • 黑盒测试
        • 即功能测试，主要用于集成测试、确认测试和系统测试中。黑盒测试将程序看作是一个不透明的黑盒，完全不考虑（或不了解）程序的内部结构和处理算法。
          • 根据SRS设计测试用例
            • 等价类划分
            • 边界值分析
            • 判定表
            • 因果图
            • 状态图
            • 随机测试
            • 猜错法
            • 正交试验法
  • 分类
    • 单元测试
      • 检查每个模块，发现模块内可能存在的差错。根据SRS进行测试
    • 集成测试
      • 检查模块之间，以及模块和已集成的软件之间的接口关系，验证已集成软件是否符合设计要求。依据软件概要设计说明书
    • 确认测试：用于验证软件的功能、性能和其他特性是否与用户需求一致
      • 内部确认测试
        • 由软件开发组织内部按照 SRS 进行测试
      • Alpha测试
        • 用户在开发环境测试
      • Beta测试
        • 实际环境测试
      • 验收测试
        • 在交付之前，以用户根据SRS的测试，
    • 系统测试
      • 系统测试的技术依据是用户需求或开发合同。
    • 配置项测试
      • 测试的对象是软件配置项
      • 目的是检验其与SRS的一致性
    • 回归测试
      • 测试软件变更之后，变更部分的正确性和对变更需求的符 合性，以及软件原有的、正确的功能、性能和其他规定的要求的不损害性
• 1.4.6软件集成技术
  • 表示集成
    • 即界面集成，属黑盒集成，无须了解程序与数据库内部构造，把零散的界面集成在一个新界面中。
  • 数据集成
    • 通过中间件对数据进行汇总集成，属白盒集成，
    • 分类
      • 数据集成：将多个数据源中的数据合并并存放在一个一致的数据仓库中。
      • 数据交换:将数据转换或统一成适合挖掘的形式。
      • 数据清洗:将重复、多余的数据筛选清除，将缺失的数据补充完整，将错误的数据纠正或者删除，最后整理成为我们可以进一步加工、使用的数据。
      • 数据归纳:在尽可能保持数据原貌的前提下，最大限度地精简数据量。
  • 控制集成
    • 即功能集成/应用集成，属黑盒集成，在业务逻辑层面对应用系统集成，通过公开API访问，
  • 业务流程集成
    • 即过程集成，超越数据和系统，由工作流组成
  • 企业间应用集成（EAI）