软件工程总结

一、绪论

1、定义

软件是计算机程序、规程以及运行计算机系统所需要的文档和数据。

软件 = 程序 + 文档 + 数据

2、软件危机

介绍

• 软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题；概括地说，软件危机包含下述两方面的问题：

  • 如何开发软件，以满足对软件日益增长的需求；
  • 如何维护数量不断膨胀的已有软件。

  开发软件所需高成本和产品的低质量之间有着尖锐的矛盾，这种现象称做软件危机

表现

1. 软件开发计划难以制定和实施
2. 软件开发费用和进度失控
3. 软件的质量无法让用户满意
4. 软件无法维护
5. 软件没有适当的文档资料
6. 软件开发成本逐年上升

原因

• 软件系统本身的复杂性
• 软件开发的方法和技术不合理及不成熟

3、软件工程

定义

• 软件工程是用工程、科学和数学的原则与方法研制、维护计算机软件和有关技术及管理方法。
• 把系统的、规范的、可度量的途径应用于软件开发、运行和维护过程，也就是把工程应用于软件。（IEEE定义）
• 软件工程包括技术和管理两方面的内容，是技术与管理紧密结合所形成的工程学科。

产生背景

1. 由于软件危机的产生导致软件工程概念的诞生；
2. 软件危机主要由于落后的软件开发方式无法满足快速增长软件需求；
3. 软件危机的7个主要方面

三要素

• 方法：给出需求、设计建模、编码、测试的方法。
• 工具：给出各种建模、编码和测试所需要的自动化或半自动化的工具
• 过程：给出指导各种软件类型开发所需要的过程模型

二、软件生命周期模型

戴明环：Plan，Do，Check，Action

1、软件工程过程

定义

• 软件工程过程是为了获得软件产品，在软件工具的支持下由软件工程师完成的一系列软件工程活动。

主要活动

• 软件规格说明：规定软件的功能及其使用限制；
• 软件开发：产生满足规格说明的软件；
• 软件确认：通过有效性验证以保证软件能够满足客户的要求；
• 软件演进：为了满足客户的变更要求，软件必须在使用过程中进行不断地改进。

2、软件生命周期

定义

• 指软件产品从考虑其概念开始，到该软件产品不再使用为止的整个时期，一般包括概念阶段、分析与设计阶段、构造阶段、移交和运行阶段等不同时期。

六个基本步骤

制定计划(P) -> 需求分析(D) -> 设计(D) -> 程序编码(D) -> 测试(C) -> 运行维护(A)

• 制定计划
  • 确定要开发软件系统的总目标；
  • 给出功能、性能、可靠性以及接口等方面的要求；
  • 完成该软件任务的可行性研究；
  • 估计可利用的资源 (硬件，软件，人力等)、成本、效益、开发进度；
  • 制定出完成开发任务的实施计划
• 需求分析
  • 对用户提出的要求进行分析并给出详细的定义；
  • 编写软件需求规格说明书或系统功能说明书及初步的系统用户手册；
  • 提交管理机构评审
• 软件设计
  • 概要设计：把各项需求转换成软件的体系结构。结构中每一组成部分都是意义明确的功能模块，每个功能都和某些需求相对应；
  • 详细设计：对每个模块要完成的工作进行具体的描述，为源程序编写打下基础；
  • 编写设计说明书，提交评审
• 程序编码
  • 具体实现，提交源程序清单
• 软件测试
  • （挑错）单元测试、组装测试 有效性测试
  • 提交：测试报告文档（测试计划、测试用例、测试结果）
• 运行维护
  • 软件交付给用户后的软件开发活动
    • 改正性维护：运行中发现了软件中的错误需要修正；
    • 适应性维护：为了适应变化了的软件工作环境，需做适当变更；
    • 完善性维护：为了增强软件的功能需做变更。
  • 软件维护是更加复杂的软件开发活动

3、软件生命周期模型

定义

• 软件生命周期模型是一个框架，描述从软件需求定义直至软件经使用后废弃为止，跨越整个生存期的软件开发、运行和维护所实施的全部过程、活动和任务，同时描述生命周期不同阶段产生的软件工件，明确活动的执行角色等。

瀑布模型（Waterfall Model）

基于软件生存周期的线性开发模型

特点

• 本阶段的工作对象来自于上一阶段活动的输出，这些输出一般是代表上一阶段活动结束的里程碑式的文档。
• 根据本阶段的活动规程执行相应的任务。
• 产生本阶段活动相关产出—软件工件，作为下一阶段活动的输入。
• 对本阶段活动执行情况进行评审。

演化模型（Evolutional Model）

提倡两次开发

• 第一次是试验开发，得到试验性的原型产品，其目标只是在于探索可行性，弄清软件需求；
• 第二次在此基础上获得较为满意的软件产品。

特点

• 优点：明确用户需求、提高系统质量、降低开发风险

• 缺点：

  • 难于管理、结构较差、技术不成熟；
  • 可能会抛弃瀑布模型的文档控制优点；
  • 可能会导致最后的软件系统的系统结构较差

适用范围

• 需求不清楚
• 小型或中小型系统
• 开发周期短

增量模型（Incremental Model）

定义

• 把软件看作一系列相互联系的增量，每次迭代完成一个增量

增量：

• 小而可用的软件
• 第一个增量通常是软件的核心

特点

• 优点

  • 客户可以在第一次增量后就使用到系统的核心功能，增强了客户使用系统的信心；
  • 项目总体失败的风险较低，因为核心功能先开发出来，即使某一次增量失败，核心功能的产品客户仍然可以使用。
  • 由于增量是按照从高到低的优先级确定的，最高优先级的功能得到最多次的测试，保障了系统重要功能部分的可靠性。
  • 所有增量都是在同一个体系结构指导下进行集成的，提高了系统的稳定性和可维护性。

• 缺点

  • 增量粒度难以选择；
  • 确定所有的需求比较困难 ；

喷泉模型（Fountain Model）

定义

喷泉模型也称迭代模型，认为软件开发过程的各个阶段是相互重叠和多次反复的，就象喷泉一样，水喷上去又可以落下来，既可以落在中间，又可以落到底部。

特点

​ 各个开发阶段没有特定的次序要求，完全可以并行进行，可以在某个开发阶段中随时补充其他任何开发阶段中遗漏的需求。

• 优点：
  • 提高开发效率
  • 缩短开发周期
• 缺点：难以管理

V模型和W模型（V & W Model）

螺旋模型（Spiral Model）

• 主要针对大型软件项目的开发周期长，风险高的特点

四个象限

• 风险分析：明确每一个项目风险，估计风险发生的可能性、频率、损害程度，并制定风险管理措施规避这些风险。
• 制定计划：确定软件项目目标；明确对软件开发过程和软件产品的约束；制定详细的项目管理计划；根据当前的需求和风险因素，制定实施方案，并进行可行性分析，选定一个实施方案，并对其进行规划。
• 实施工程：针对每一个开发阶段的任务要求执行本开发阶段的活动。
• 客户评估：客户使用原型，反馈修改意见；根据客户的反馈，对产品及其开发过程进行评审，决定是否进入螺旋线的下一个回路。

构件组装模型（Component Assembly Model）

定义

• 利用模块化思想将整个系统模块化，并在一定构件模型的支持下复用构件库中软件构件，通过组装高效率、高质量地构造软件系统。构件组装模型本质上是演化的，开发过程是迭代的。
• 构件组装模型的开发过程就是构件组装的过程，维护的过程就是构件升级、替换和扩充的过程。

特点

• 优点：
  • 充分利用软件复用，提高了软件开发的效率
  • 允许多个项目同时开发，降低了费用，提高了可维护性，可实现分步提交软件产品
• 缺点：
  • 缺乏通用的构件组装结构标准，风险较大
  • 构件可重用性和系统高效性之间不易协调
  • 由于过分依赖于构件，构件质量影响着最终产品的质量

快速应用开发模型（Rapid Application Development Model，RAD）

定义

• RAD是一个增量型的软件开发过程模型，强调极短的开发周期

特点

• 缺点：
  • 并非所有应用都适合采用RAD
  • 由于时间约束，开发人员和客户必须在较短的时间内完成一系列的需求分析，沟通配合不当都会导致应用RAD模型的失败
  • RAD适合于管理信息系统的开发，对于其他类型的应用系统，如技术风险较高、与外围系统的互操作性较高等，不太合适

原型方法（Prototype Method）

定义

• 原型指模拟某种最终产品的原始模型；
• 原型方法指在获得一组基本需求后，通过快速分析构造出一个小型的软件系统原型，满足用户的基本要求。
• 用户通过使用原型系统，提出修改意见，从而减少用户与开发人员对系统需求的误解，使需求尽可能准确。
• 原型方法主要用于明确需求，但也可以用于软件开发的其他阶段。

种类

• 废弃策略
  • 探索型：弄清用户对目标系统的要求，确定所期望的特性；探讨多种实现方案的可行性。主要针对需求模糊、用户和开发者对项目开发都缺乏经验的情况。
  • 实验型：用于大规模开发和实现之前，考核技术实现方案是否合适、分析和设计的规格说明是否可靠。
• 追加策略
  • 进化型：在构造系统的过程中能够适应需求的变化，通过不断地改进原型，逐步将原型进化成最终的系统。它将原型方法的思想扩展到软件开发的全过程，适用于需求经常变动的软件项目

统一过程 RUP

定义和特征

• 描述了软件开发中各个环节应该做什么、怎么做、什么时候做以及为什么要做，描述了一组以某种顺序完成的活动。
• 基本特征是“用例驱动、以架构为中心的和受控的迭代式增量开发”（以用例为驱动，软件体系结构为核心，应用迭代及增量的新型软件生命周期模型）

四个阶段

• 初始阶段：阶段目标是通过业务场景（business case）了解业务并确定项目的边界。包括项目的验收规范、风险评估、所需资源估计、阶段计划等。
  • 软件目标里程碑。包括一些重要的文档，如：项目愿景（vision）、原始用例模型、原始业务风险评估、一个或者多个原型、原始业务场景等
• 细化阶段：阶段目标是分析问题领域，建立适合需求的软件体系结构基础，编制项目计划，完成项目中技术要求高、风险大的关键需求的开发。
  • 体系结构里程碑。包括风险分析文档、软件体系结构基线、项目计划、可执行的进化原型、初始版本的用户手册等。
• 构造阶段：阶段目标是将所有剩余的技术构件和稳定业务需求功能开发出来，并集成为产品，所有功能被详细测试。
  • 运行能力里程碑。包括可以运行的软件产品、用户手册等，它决定了产品是否可以在测试环境中进行部署。
• 移交阶段：移交阶段的重点是确保软件对最终用户是可用的。交付阶段可以跨越几次迭代，包括为发布做准备的产品测试，基于用户反馈的少量调整。
  • 产品发布里程碑。

每个阶段又分为若干次迭代，每次迭代有一个核心工作流，都会经历需求、分析、设计、实现和测试等活动

• 9个核心工作流，分为6个核心过程工作流和3个核心支持流。
• 核心过程工作流：业务建模、需求、分析和设计、实现、测试、部署
• 核心支持流：配置和变更管理、项目管理、环境

敏捷模型

定义

• 一种以人为核心、迭代、循序渐进的开发方法，其软件开发过程称为“敏捷过程”

敏捷过程价值观：

• 个人和交互胜过过程和工具（强调面对面的沟通）
• 可以运行的软件胜过面面俱到的文档（把精力集中在可执行的程序上）
• 客户合作胜过合同谈判（团队合作和团队激励）
• 响应变化胜过遵循计划（超强的适应能力）

极限过程：

• 一种轻量级的、敏捷的软件开发方法
• 4个价值观：交流、简单、反馈、勇气
• 4个方面改善：加强交流、从简单做起、寻求反馈、用于实事求是
• 12个核心实践：完整团队、计划对策、测试、简单设计、结对编程、小软件版本、设计改进、持续集成、代码共有、编码标准、系统比喻、可持续的速度

三、软件需求分析

1、需求分析之前的活动

• 预研：主要探索软件项目的目标、市场预期、主要的技术指标等，用于帮助决策者做出是否进行软件项目立项的决定。
• 可行性分析：针对项目的目标和范围进行小范围的概要分析和研究，探索问题域中的核心问题及其相应的解决方案，进一步为决策者提供经济、技术甚至是法律上可行性的分析报告。

2、对象、任务和目标

• 软件需求分析的对象：用户需求。
• 软件需求分析的任务是：准确地定义新系统的目标，回答系统必须“做什么”的问题并编制需求规格说明书。
• 需求分析的目标：借助于当前（业务）系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的“做什么”的问题。（必须展示信息、功能和行为三个方面）

3、原则

操作性原则

• 问题的信息域必须被表示和理解。
• 软件的功能必须被定义。
• 软件的行为（作为外部事件的结果，或者理解为功能存在的理由）必须被表示。

工程化原则

• 首先要正确地理解问题，再建立分析模型。
• 记录每个需求的起源及原因，保证需求的可回溯性。
• 开发一个人机交互过程的原型。
• 给需求赋予优先级：紧张的开发时间要求尽量避免一次性实现每个软件需求，应采用迭代增量的开发模型。
• 努力删除歧义性：因为大多数需求以自然语言描述，存在歧义性的可能性，正式的技术评审是发现并删除歧义性的一种有效方法

4、数据、功能及行为建模

• 数据模型：
  • 信息内容和关系；信息流；信息结构。
• 功能模型：对进入软件的信息和数据进行变换和处理的模块，它必须至少完成三个常见功能：
  • 输入、处理和输出。
• 行为模型：大多数软件对来自外界的事件做出反应，这种刺激／反应特征形成了行为模型的基础。行为模型创建了软件状态的表示，以及导致软件状态变化的事件的表示。

5、需求工程

定义

• 软件的需求分析是一系列复杂的软件工程活动，为了便于对需求进行更好的管理，人们把所有与需求直接相关的活动通称为需求工程。

需求获取

• 需求获取的目的是清楚地理解所要解决的问题，完整地获得用户的需求。并提出这些需求实现条件，以及需求应达到的标准。
• 需求获取的对象
  • 用户：使用软件的人员
  • 客户：购买软件的人员
• 需求获取的难点
  • 用户无法清楚地表达需求
  • 需求的理解问题
  • 用户经常变更需求

流程

准备

• 需求获取的准备工作围绕三项展开：
  • 调查什么？明确访谈主题。
  • 通过什么方式去调查？面谈、会议交流、电话或邮件。
  • “何人”在“何时”调查？ 访谈对象及时间。
• 首先，应起草需求调查问题表，将重点锁定在该问题表内，否则调查工作将变得漫无边际。
• 其次，应当确定需求调查的方式，比如：
  • 与用户交谈，向用户提问题。
  • 参观用户的工作流程，观察用户的操作。
  • 向用户群体发调查问卷。
  • 与同行、专家交谈，听取他们的意见

记录

用户需求说明书

• 对收集到的所有需求信息进行分析，消除错误，归纳与总结共性的用户需求。
• 然后按照规定的文档模板（可自行定义）撰写《用户需求说明书》，调查过程中获取的需求信息可以作为《用户需求说明书》的附件。
• 之后应当邀请同行专家和用户一起评审《用户需求说明书》，尽最大努力使《用户需求说明书》能够正确无误地反映用户的真实意愿。

用户需求说明书与软件需求规格说明书的区别

• 前者主要采用自然语言来表达用户需求，后者采用规范的建模语言表示。
• 后者是前者的细化，更多地采用计算机语言和图形符号来刻画需求，软件需求规格说明书是软件系统设计的直接依据。
• 两者之间可能并不存在一一影射关系
  • 因为软件开发商会根据产品发展战略、企业当前状况适当地调整软件需求，例如用户需求可能被分配到软件的数个版本中；
  • 也存在由于技术条件的限制，删减一些无法实现的、成本太高的需求；
  • 也存在提供更先进的技术来丰富软件需求；
  • 最后，软件开发人员应当依据《软件需求规格说明书》来开发当前产品。

需求类别

• 功能需求：列举出所开发软件在功能上应做什么，这是最主要的需求。
• 性能需求：给出所开发软件的技术性能指标，尤其是系统的实时性和其他时间要求，如响应时间、处理时间、消息传送时间等；资源配置要求，精确度，数据处理量等要求。
• 环境需求：是对软件系统运行时所处环境的要求。
  • 在硬件方面，采用什么机型、有什么外部设备、数据通信接口等等。
  • 在软件方面，采用什么支持系统运行的系统软件（指操作系统、数据库管理系统等）。
  • 在使用方面，需要使用部门在制度上、操作人员的技术水平上应具备什么样的条件等等
• 其他需求：可靠性、安全保密、用户界面、资源使用、软件成本消耗与开发进度、预先估计以后系统可能达到的目标

需求的定义

需求分析与建模

需求分析的步骤（迭代）：

• 需求获取、需求建模、需求描述（编写SRS）、需求验证；
• 需求获取的目的是让开发人员通过各种方式充分和用户交流，全面、准确地了解系统需求；
• 建立需求模型是需求分析的核心，它通过各种图形及符合，可视化地从各个侧面描述系统需求；（结构化方法（包括数据流、数据字典、加工规格说明）和面向对象方法（面向对象方法包括用例模型、补充规约和术语表））
• 需求描述即编写需求规格说明书，它以各方共同认可的文档形式表述，是软件设计和系统验收的可靠依据；
• 需求验证用来检验以上各步的工作成果

四、面向对象分析

1、UML

主要特点

• UML 是一种标准的图形化建模语言，它是面向对象分析与设计的一种标准表示，它
  • 不是一种可视化的程序设计语言，而是一种可视化的建模语言；
  • 不是工具或知识库的规格说明，而是一种建模语言规格说明，是一种表示的标准；
  • 不是过程，也不是方法，但允许任何一种过程和方法使用它。

4+1视图

​UML 用模型来描述系统的结构（静态特征）以及行为（动态特征）。从不同的视角为系统的架构建模，形成系统的不同视图（view）， 称为4+1视图

• 用例视图：强调从用户的角度看到的或需要的系统功能，这种视图也叫做用户模型视图（user model view） 或场景视图（scenario view）；
• 逻辑视图：展现系统的静态或结构组成及特征，也称为结构模型视图（structural model view） 或静态视图（static view）；
• 进程视图：描述设计的并发和同步等特性，关注系统非功能性需求，也称为行为模型视图（behavioral model view）、过程视图（process view）、 协作视图（collaborative view）和动态视图（dynamic view）；
• 构件视图：关注软件代码的静态组织与管理，也称为实现模型视图（implementation model view ）和开发视图（development view）；
• 部署视图：描述硬件的拓扑结构以及软件和硬件的映射问题，关注系统非功能性需求（性能、可靠性等），也称为环境模型视图或物理视图（physical view）；

9个基本图

• 用例图（Use case diagram）：（从用户的角度）描述系统的功能；
• 类图（Class diagram）：描述系统的静态结构（类及其相互关系）；
• 对象图（Object diagram）： 描述系统在某个时刻的静态结构（对象及其相互关系）；
• 顺序图（Sequence diagram）：按时间顺序描述系统元素间的交互；
• 协作图（Collaboration diagram）：按照时间和空间的顺序描述系统元素间的交互和它们之间的关系；
• 状态图（State diagram）：描述了系统元素（对象）的状态条件和响应；
• 活动图（Activity diagram）：描述了系统元素之间的活动；
• 构件图（Component diagram）：描述了实现系统的元素（类或包）组织；
• 部署图（Deployment diagram）：描述了环境元素的配置并把实现系统的元素映射到配置上

视图与图的关系

• 用例视图：使用用例图；
• 逻辑视图：使用类图、对象图，顺序图/协作图；
• 进程视图：使用状态图和活动图；
• 构件视图：使用构件图；
• 部署视图：使用部署图。

2、领域模型

定义

• 针对某一特定领域内概念类或者对象的抽象可视化表示。
• 主要用于概括地描述业务背景及重要的业务流程，并通过UML的类图和活动图进行展示，帮助软件开发人员在短时间内了解业务。
  • 业务背景：可由用户需求说明书或者用例说明中具有代表业务概念或者业务对象的词汇获得，这些词汇可统称为“概念类”；并通过能够代表关系的词汇建立概念类之间的关系，表示成能够代表业务知识结构的类图；
  • 业务流程：一般由角色及其执行的活动（活动及任务节点）构成，活动的输出一般有数据对象和传给另一个活动的消息组成，建议使用UML的活动图进行描述。

识别概念类

• 通过对用例描述中的名词或名词短语寻找和识别概念类；

• 需要注意的是名词可以是概念类，也可能是概念类中表示特征的属性；

  • 属性一般是可以赋值的，比如数字或者文本。

  • 如果该名词不能被赋值，那么就“有可能”是一个概念类。

  • 如果对一个名词是概念类还是属性举棋不定的时候，最好将其作为概念类处理。

  • 需要注意的是：不存在名词到类的映射机制，因为自然语言具有二义性

• 这种方法的弱点是自然语言的不精确性，建议初学者使用

创建领域模型的步骤

1. 找出当前需求中的候选概念类。
2. 在领域模型中描述这些概念类。用问题域中的词汇对概念类进行命名，将与当前需求无关的概念类排除在外。
3. 在概念类之间添加必要的关联来记录那些需要保存记忆的关系，概念之间的关系用关联、继承、组合/聚合来表示。
4. 在概念类中添加用来实现需求的必要属性。

添加关联

• 领域模型中的关联可分为两种：

  • “需要知道”型关联：需要将概念之间的关系信息保持一段时间的关联。领域模型中需要着重考虑。
  • “只需理解”型关联：有助于增强对领域中关键概念的理解的关联。

• 寻找关联时要遵循下述指导原则：

  • 将注意力集中在需要知道型关联。
  • 识别概念类比识别关联更重要，因此领域模型创建过程中应该更加注重概念类的识别。
  • 太多的关联不仅不能有效地表示领域模型，反而容易使领域模型变得混乱。
  • 避免显示冗余或导出关联。

3、用例模型

• 用例模型由以下四个部分组成：
  • 用例图；
  • 用例说明；
  • 系统顺序图（system sequence diagram，option）；
  • 操作契约（operation contract，option）;
• 以用例为核心从使用者的角度描述和解释待构建系统的功能需求

用例图

• 用例图由三个基本元素组成
  • Actor：称为角色或者参与者，表示使用系统的对象，代表角色的不一定是人，也可以是组织、系统或设备；
  • Use_case：称为用例，描述角色如何使用系统功能实现需求目标的一组成功场景和一系列失败场景的集合；
  • Association：表示角色与用例之间的关系，以及用例和子用例之间的关系

用例说明

系统顺序图

• 使用UML的sequence diagram描述角色与系统之间的交互
• 在用例描述的基础上需进一步确定角色与系统之间的交互信息，并以可编程的方式将其命名；
• 系统顺序图中“一般”只需要三个UML的符号元素
  • 角色；
  • 代表软件系统的对象，一般使用system或者系统命名；
  • 角色与system之间的交互信息，简称消息或操作。

注意：

1. SSD是用于替代用例说明文本的一种方式；
2. 图中只有两个对象，表示角色对象与系统对象；
3. 图中的消息名称及参数要求以可编程的方式命名；
4. 消息名称和参数可以通过一个列表使用中文说明具体含义；
5. 用例图中的每个用例都应该对应一张SSD；
6. 角色发给系统的指令（系统事件）是操作契约关注的元素

操作契约

• 系统操作：处理系统事件的操作，也称为系统事件；

• 操作契约是为系统操作（指令）而定义的，参考领域模型中业务对象（概念类）接收到相同的系统事件后，执行必须的业务处理时各业务对象的状态以及系统操作执行的结果，以便软件设计时进行参考。模板如下表所示：

  

创建操作契约

• 创建操作契约的指导原则如下：
  • 根据系统顺序图识别进入到系统内的所有系统事件，即操作；
  • 针对每一个系统操作结合对应的领域模型，找到与此操作相关的概念类；
  • 定义概念类响应该操作的以下三项内容；
    • 对象实例创建和删除；
    • 对象关联形成和断开；
    • 对象属性修改。
• 后置条件中至少有一项存在，该操作才有存在的必要性！
• 后置条件的陈述应该是声明性的，以强调系统状态所发生的变化，无需考虑如何设计和实现的。

五、结构化需求分析

1、分析模型的结构

• 需求分析的分析模型必须达到三个主要目标：
  • 描述客户的需求；
  • 建立创建软件设计的基础；
  • 定义在软件完成后可以被确认的一组需求。
• 结构化分析模型的组成
  • 数据流图：描述功能模型
  • ER图、数据词典：描述数据模型
  • 状态迁移图：描述行为模型

2、数据流图

定义

• 数据流图可以被用来抽象地表示系统或软件，既能提供功能建模的机制。

• 也可提供数据流建模的机制，并可以自顶向下的机制表示层级的功能细节和数据变换细节。

四种基本元素

组成符号：

• 圆框代表加工
• 箭头代表数据的流向，数据名称总是标在箭头的边上
• 方框表示数据的源点和终点
• 双杠（或单杠）表示数据文件或数据库
• 文件与加工之间用带箭头的直线连接，单向表示只读或只写，双向表示又读又写

数据流与加工的关系：

分层的数据流图

• 为表达复杂的实际问题（图形符号过多），需要按照问题的层次结构进行逐步分解，并以分层的数据流图反映这种结构关系。
  • 顶层数据流图：顶层流图仅包含一个加工，它代表被开发系统，其作用在于表明被开发系统的范围，以及它和周围环境的数据交换关系。
  • 中间层数据流图：表示对其上层父图的细化。它的每一加工可以继续细化，形成子图。中间层次的多少视系统的复杂程度而定。
  • 底层数据流图：是指加工不须再做分解的数据流图，称为“原子加工”

两种表示

绘制步骤

• 画数据流图的基本步骤概括地说，就是自外向内，自顶向下，逐层细化，完善求精。具体步骤可按如下来做：

  1. 先找系统的数据源点与汇点。它们是外部实体，由它们确定系统与外界的接口。
  2. 找出外部实体的输出数据流与输入数据流。
  3. 在图的边上画出系统的外部实体。
  4. 从外部实体的输出数据流（即系统的源点）出发，按照系统的逻辑需要，逐步画出一系列逻辑加工，直到找到外部实体所需的输入数据流(即系统的汇点)，形成数据流的封闭。
  5. 按照下面所给的原则进行检查和修改。
  6. 按照上述步骤，再从各加工出发，画出所需的子图

检查和修改数据流图的原则

• 数据流图上所有图形符号只限于前述四种基本图形元素，且必须包括前述四种基本元素，缺一不可。
• 数据流图的主图上的数据流必须封闭在外部实体之间，外部实体可以不止一个。
• 每个加工至少有一个输入数据流和一个输出数据流。
• 在数据流图中，需按层给加工框编号，表明该加工处在哪一层，以及上下层的父图与子图的对应关系。
• 任何一个数据流子图必须与它上一层的一个加工对应，两者的输入数据流和输出数据流必须一致。即父图与子图的平衡，表明在细化过程中输入与输出不能有丢失和强加。
• 图上每个元素都必须有名字。表明数据流和数据文件是什么数据，加工做什么事情

3、数据词典

定义

• 数据词典：对于数据流图中出现的所有被命名的图形元素加以定义，使得每一个图形元素的名字都有一个确切的解释
• 其定义应是严密的、精确的，不可有半点含混并消除二义性，它由以下内容组成：
  • 数据流词条
  • 数据元素词条
  • 数据文件词条
  • 加工词条
  • 外部实体

数据流词条

数据元素词条

数据文件词条

外部实体词条

加工逻辑词条

• 数据流图中的每一个加工除了要进行基本信息的描述之外，还须对加工的逻辑或规则进行描述，其方法有判定表、判定树或结构化英语等。

• 在书写基本加工逻辑的说明时，应满足如下的要求：
  • 对数据流图的每一个基本加工，必须有一个加工逻辑说明；
  • 加工逻辑说明描述基本加工如何把输入数据流变换为输出数据流的加工规则（参考业务规则）；
  • 加工逻辑说明必须描述实现加工的策略而不是实现加工的细节

结构化英语

• 结构化英语也称为PDL，是一种介于自然语言和形式化语言之间的半形式化语言。
• 它是在自然语言基础上加了一些限制而得到的语言，是使用有限的词汇和有限的语句来描述加工逻辑。
• 其词汇表由英语命令动词、数据词典中定义的名字、有限的自定义词和控制结构关键词：
  • IF_THEN_ELSE
  • WHILE_DO
  • REPEAT_UNTIL
  • CASE_OF等组成。
• 其动词的含义要具体，尽可能少用或不用形容词和副词

示例

判定表

• 在某些数据处理问题中，数据流图的加工需要依赖于多个逻辑条件的取值，即完成这一加工的一组动作是由某一组条件取值的组合而引发时，逻辑组合比较复杂，就需要用判定表来表示。

判定树

• 判定树也是用来表达加工逻辑的一种工具。有时候它比判定表更直观。用它来描述加工，很容易为用户接受。

• 在表达一个基本加工逻辑时，结构化英语、判定表和判定树常常交叉使用，互相补充。
• 总之，加工逻辑说明是结构化分析方法的一个组成部分，对每一个加工都要加以说明。
• 应当以结构化英语为主，对存在判断问题的加工逻辑，可辅之以判定表和判定树。

下半部分传送门：https://blog.csdn.net/qq_43791817/article/details/118054089