软工笔记

开个坑，期末复习用。
参考 这位 和 这位 的笔记，并做了补充。

第一章 软件工程概述

软件的定义
软件的发展和软件危机
软件工程的概念

程序的定义：程序=算法+数据结构。

软件的定义： 软件是包括程序、数据及其相关文档的完整集合。 程序和数据是构造软件的基础，文档是软件质量的保证，也是保证软件更新及生命周期长短的必需品。

软件危机：计算机软件在开发和维护过程中遇到一系列严重问题，导致软件行业的信任危机。具体表现在：

1. 软件的开发成本难以估算，无法制定合理的开发计划。
2. 用户的需求无法确切表达。
3. 软件质量存在问题。
4. 软件的可维护性差。
5. 缺乏文档资料。

产生软件危机的原因：

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

软件工程定义：运用工程化原则和方法，组织软件开发解决软件危机。

软件工程的三要素：方法、工具、过程。方法提供了“如何做”的技术、工具提供了自动或半自动的软件支撑环境、过程将方法和工具综合起来以达到合理及时地进行计算机软件开发的目的。

软件工程的目标：在给定成本和时间的前提下，开发出满足用户需求且具有正确性、可用性等因素的软件产品。

软件工程项目三个基本目标：合理的进度、有限的经费、一定的质量。（和上条类似）

软件工程的终极目标：摆脱手工生产软件的状况，逐步实现软件研制和维护的自动化。

软件工程知识体系指南
SWEBOK（Guide to SoftWare Engineering Body of Knowledge）

第二章 生命周期模型

points:

软件生命周期概念
传统软件生命周期模型
新型软件生命周期模型

软件工程项目三个基本目标：合理的进度、有限的经费、一定的质量。

戴明环：PDCA——Plan，Do，Check，Action。(美国质量管理专家戴明博士针对工程项目的指令目标提出的)

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

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

软件生命周期概念

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

软件生命周期六个基本步骤：PDDDCA
(相当于戴明环PDCA的细分)(只需设成软云)

• 制定计划 P
  确定总目标，给出各方面的要求，可行性研究，预估可用资源，提交审查
• 需求分析 D
  详细进行需求分析，初步编写说明书和用户手册
• 设计 D
  概要设计、详细设计
• 程序编码 D
  就是写代码给过程
• 软件测试 C
  单元测试、组装测试
• 运行维护 A
  改正性维护，适应性维护，完善性维护。
  软件维护是更加复杂的软件开发活动。

软件过程模型：从一个特定角度提出的对软件过程的概括描述，是对软件开发过程的抽象，包括构成软件过程的各种活动(Activity)、软件工件(Artifacts)、参与角色(Actors/Roles) 等。

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

传统软件生命周期模型

传统模型种类：瀑布模型、演化模型、增量模型、喷泉模型、V&W 模型、螺旋模型、构件组装模型、快速应用开发模型、原型方法。

瀑布模型 Water Fall Model

是所有其他软件生命周期模型的基础，最经典。
1970年提出的，属于是软件危机的关键时期。

• 特征
  • 文档驱动，本阶段的工作对象来自于上一阶段活动的输出文档。
  • 每个阶段要产生本阶段的输出——软件文件
  • 每个阶段结束都有评审，方便出现问题立即解决。
• 优点
  • 降低开发复杂度、提高透明性可管理性。
  • 推迟了软件实现，强调必须先分析和设计。
  • 对本阶段活动执行情况进行评审，以文档评审等手段指导整个开发过程，保证了错误不会留到下一个周期。
• 缺点
  • 缺乏灵活性，无法解决需求不明或不准确的问题。
  • 风险控制能力较弱。
  • 文档过多时，增加工作量。且文档的完成情况并不能完全反映实际项目情况，导致错误结论。

演化模型 Evolutional Model

• 提倡两次开发（Do Twice）：第一次得到试验性的原型产品，探索可行性，明确需求。第二次在此基础上开发成品。

相对于瀑布模型而言,演化模型的一个明显优点就是可以处理需求不明确的软件项目，对于探索式的演化模型,能够在开发过程中间逐步向用户展示软件半成品,降低系统的开发风险。
另外,演化模型将用户的参与始终贯穿在开发过程中,使最终的软件系统能够真实地实现用户需求,又保障系统质量。

• (1)探索式演化模型：其目标是与用户一起工作,共同探索系统需求,直到最后交付系统。

• (2)抛弃式演化模型：通过实现一个或多个系统原型理解和明确用户需求,然后给出系统一个较好的需求定义。

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

• 缺点：

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

• 适用范围：需求不清楚、中小型系统、开发周期短。

增量模型 Incremental Model

• 首先对系统最核心或最清晰的需求进行分析、设计、实现、测试。再按优先级逐步对后续的需求进行上述开发工作。结合了演化和瀑布模型的优点。
  

在增量模型中,客户大概或模糊地提出系统须提供的服务或功能,即给出系统的需求框架,以及这些服务或功能的重要作用,从而可以确定系统需求实现的优先级。
为了避免多个增量集成时导致不一致的系统体系结构,增量模型在获取系统框架需求后,针对核心需求及系统的性能要求确定系统的体系结构,并以此体系结构指导增量的集成,保证在整个开发过程中体系结构稳定。

• 优点：
  • 第一次增量实现系统核心功能，增强客户使用系统的信心。
  • 项目总体失败风险较低,因为先开发核心功能，即使某一次增量失败，核心功能还是能用。
  • 最高优先级的功能先开发，得到最多测试，保障可靠性。
  • 增量在同一体系指导下进行集成，提高稳定性和可维护性。
• 缺点：
  • 难以选择增量粒度。
  • 难以确定所有需求。

喷泉模型（迭代模型）Fountain Model

高情商：各个开发阶段没有特定次序要求，可以并行进行，可以随时补充遗漏的需求（低情商：想到什么做什么，瞎 JB 写）。(比较灵活，用的不多)
优点：提高开发效率、缩短开发周期。
缺点：难于管理。
适用于：需求不明晰。

V&W模型

V模型在瀑布模型基础上改进，把测试活动提前，使得模型能够驾驭风险。后来Evolutif公司在V模型的基础上提出了W模型。

V模型的左半部分就是在测试阶段之前的瀑布模型，即V模型的开发阶段，右半部分是测试阶段。V模型明确地划分测试的级别,并将其与开发阶段的活动对应。

W模型强调：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求和设计同样需要测试，即测试与开发是同步进行的。（相当于测试的时间提前了，并且贯穿整个软件的生命周期）
由于W模型扩展测试的内容：增加确认和验证活动，所以它有利于尽早地全面发现问题。

螺旋模型 Spiral Model

• 针对大型软件开发项目的特点而提出来的。
• 分为四个象限螺旋上升：风险分析、制定计划、实施工程、客户评价——进入下一回路。
• 适用于：开发周期长、风险高的大型软件。

构件组装模型：

• 模块化思想，使用复用构件库的组件搭建系统。

• 优点：

  • 软件复用、提高效率。
  • 允许多项目同时开发，降低费用、提高可维护性。

• 缺点：

  • 缺乏通用构建组装标准风险较大。
  • 构建可重用性与系统高效性不易协调。
  • 过分依赖构件，构件质量影响产品质量。

构件组装模型

• 模块化思想，使用复用构件库的组件搭建系统。

• 优点：

  • 软件复用、提高效率。
  • 允许多项目同时开发，降低费用、提高可维护性。

• 缺点：

  • 缺乏通用构建组装标准，风险较大。
  • 构建可重用性与系统高效性不易协调。
  • 过分依赖构件，构件质量影响最终产品质量。

快速应用开发模型（RAD）

英文是 Rapid Application Development

• 开发周期 60-90 天(很短)，分小组同步进行软件各部分开发。
• 缺点：时间短，需要强沟通配合。不适合所有应用。
• 适用于：信息管理系统的开发，对于其他系统不太适合。

原型方法 Prototyping Method

原型指的是 模拟某种最终产品的原始模型。
用户通过使用原型系统提出修改意见。
和增量好像也没什么区别
主要用于明确需求，也可以用于软件开发的其他阶段。（划线部分也是它与增量模型和演化模型的区别）

由于运用原型的目的和方式不同,在使用原型时可采取以下两种不同的策略。

1. 废弃策略:先构造一个功能简单而且性能要求不高的原型系统,针对用户使用这个原型系统后的评价和反馈,反复进行分析和改进,形成比较好的设计思想,据此设计出较完整,准确、一致、可靠的最终系统。系统构造完成后,原来的原型系统废弃不用。探索型和实验型原型属于这种策略。
2. 追加策略:先构造一个功能简单而且性能要求不高的原型系统,作为最终系统的核心,然后通过不断地扩充修改,逐步追加新要求,最后发展成为最终系统。它对应进化型原型。

原型方法的优点

• 原型提供了用户与开发人员良好的沟通手段，易于被人们接受：

  • 原型方法有助于快速理解用户对于需求的真实想法 ；
  • 可以容易地确定系统的性能，确认各项主要系统服务的可应用性，确认系统设计的可行性，确认系统作为产品的结果 ；
  • 软件原型的最终版本，有的可以原封不动地成为产品，有的略加修改就可以成为最终系统的一个组成部分，这样有利于建成最终系统。

• 原型法的适用范围和局限性：

  • 大型系统如不经过系统分析得到系统的整体划分，而直接用原型来模拟是很困难的。
  • 对于大量运算的、逻辑性较强的程序模块，原型方法很难构造出该模块的原型来供人评价。
  • 对于原有应用的业务流程、信息流程混乱的情况，原型构造与使用有一定的困难。

• 原型方法存在的问题：

  • 文档容易被忽略。
  • 建立原型的许多工作会被浪费掉 。
  • 项目难以规划和管理。

新型软件生命周期模型

RUP（Rational Unified Process）

• 软件生命周期分解为 4 各阶段：初始阶段（Inception）、细化阶段（Elaboration）、构造阶段（Construction）和交付阶段（Transition）。每个阶段结束于一个重要的里程碑。在阶段结尾评估是否满足阶段目标，评估通过允许项目进入下一阶段。(除夕狗叫)
  • 初始阶段：软件目标里程碑。
  • 细化阶段：体系结构里程碑。
  • 构造阶段：运行能力里程碑。
  • 移交阶段：产品发布里程碑。
• 特点
  • 用例驱动
  • 软件体系结构为核心
  • 应用迭代及增量的新型软件生命周期模型。

适应性开发：
小步骤，快速反馈和调整

曲线展示每一项活动在不同阶段的工作量的动态分配;说明每一项活动在不同阶段与其他活动之间的关系,展示每一个迭代所必须执行的活动。RUP将软件开发过程通过时间、阶段、迭代与开发活动有机地结合。

综上所述,RUP 的特点可以概述为用例为驱动,以架构为核心的迭代增量式开发模型。通过多次迭代将瀑布一个完整的开发过程分解成多个小的瀑布过程,其优点正好解决瀑布模型开发周期太长的问题,并且在短时间内可以给客户和用户呈现系统的结构,以及对需求理解是否正确。

敏捷及极限编程

敏捷建模（Agile Modeling，AM）是由Scott W. Ambler从许多的软件开发过程实践中归纳总结出来的一些敏捷建模价值观、原则和实践等组成的，它是快速软件开发的一种思想代表，具体的应用有极限编程、SCRUM、水晶、净室开发等。

• XP 极限编程(eXtreme Programming)：基于敏捷建模思想，也是瀑布模型演化而来。
• XP 强调用户满意，开发人员可以对需求的变化作出快速的反应。

第三章 软件需求分析

需求分析的对象、任务、目标
数据、功能、行为建模
需求类别

需求分析的对象、任务、目标

需求分析的必要性

需求分析是一项必须的软件工程活动。它在系统需求分析和软件设计之间起到桥梁的作用：

• 它使得软件开发人员在系统分析的基础上深入描述软件的功能和性能、指明软件和其他系统元素的接口，建立软件必须满足的约束条件。
• 它允许软件开发人员对关键问题进行细化，并构建相应的分析模型：数据、功能和行为模型。
• 分析模型成为设计模型的基础，需求规格说明书也为软件测试人员和用户提供了软件质量评估的依据。
• 它能准确表达用户对系统的各项要求。

分析模型

• 数据模型
• 功能模型
• 行为模型

需求分析的对象：用户要求。

需求分析的任务

1. 准确地定义新系统的目标
2. 回答系统“做什么”的问题
3. 并编写需求规格说明书（结果）

需求分析的目标：借助于当前 （业务）系统的逻辑模型 导出目标系统的逻辑模型 ，解决目标系统的“做什么”的问题。

需求分析的操作性原则：

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

需求分析的⼯程化原则:

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

需求规格说明书的内容：需求分析模型。（描述系统需要做什么，而非如何做系统）

• 给出当前系统及目标系统的逻辑视图，以及当前系统的物理视图。
• 逻辑模型给出软件要达到的功能和处理数据之间的关系 ，而非实现细节。
• 物理模型给出业务环境中的业务实体和业务处理流程 ，是抽象出当前系统逻辑模型的基础。(领域模型，类图)

常用的建模分析方法有：SA（面向数据流的结构化分析方法）、JSD（面向数据结构的 Jackson 方法）、OOA（面向对象的分析方法）等。

数据、功能、行为建模

• 数据模型
  • 信息和内容关系、信息流、信息结构。（类图，ER图）
• 功能模型
  • 对进入软件的信息和数据进行变换的模块，必须至少完成“输入、处理、输出”三个功能。（用例图）
• 行为模型
  • 大多数软件对来自外界的事件做出反应。行为模型创建了软件状态的表示，以及导致软件状态变化的事件的表示（状态机）。（活动图，状态转移图，petri图）

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

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

需求工程

---

• 需求开发
  • 需求获取
  • 需求分析
  • 需求定义
• 需求管理
  • 需求确认
  • 需求跟踪
  • 需求变更控制

---

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

需求获取的流程

需求类别

功能需求：列举出所开发软甲你在功能上应做什么（最主要需求）。

性能需求：给出所开发软件的技术性能指标。系统的实时性和其他时间要求（响应时间、处理时间、消息传送时间等）、资源配置要求、精确度、数据处理量等其他要求。

环境需求：软件系统运行时所处环境的要求。① 硬件方面，采用什么机型、有什么外部设备、数据通信接口等。② 软件方面，采用什么支操作系统、数据库管理系统等。③ 使用方面，需要使用部门在制度上、人员技术水平上具备什么样的条件等。

其他需求类别：

• 可靠性需求：软件的有效性和数据完整性。
• 安全保密需求。
• 用户界面需求。
• 资源使用需求：指所开发软件运行时所需的数据、软件、内存空间等各项资源。以及软件开发时的人力物力需求。
• 软件成本消耗与开发进度需求：软件项目立项之后，根据合同规定，对软件开发的进度和步骤费用提出要求，作为开发管理依据。
• 预估将来系统可能达到的目标：在开发过程中对系统将来可能的扩充与修改做准备。

需求的分析与综合

需求获取之后就需要对比较复杂的需求进行建模分析，进而逐步细化所有的软件功能，找出系统各元素之间的联系、接口特性和设计上的限制，分析它们是否满⾜功能要求，是否合理。

需求定义

第四章 面向对象分析

UML
面向对象分析模型
1. 领域建模
2. 用例建模

1. 领域建模
   1. 领域模型的定义和表示
   2. 业务背景：概念类及关系，类图
   3. 业务流程：活动图(没讲)
2. 用例建模
   1. ⽤例图
   2. ⽤例说明
   3. 系统顺序图
   4. 操作契约

UML概念及画法

UML（Unified Modeling Language）：面向对象的统一建模语言。

• 不是一种可视化的程序设计语言，而是—种可视化的建模语言;
• 不是工具或知识库的规格说明，而是一种建模语言规格说明，是一种表示的标准;
• 不是过程，也不是方法，但允许任何一种过程和方法使用它。

4+1 视图：从不同视角为系统架构建模，形成系统的不同视图。分别为：

• 用例视图Use Case View（用户模型视图、场景视图）：强调从用户角度看到的或需要的系统功能。
• 逻辑视图Logical view（结构模型视图、静态视图）：展现系统的静态或结构组成及特征。
• 进程视图Process View（行为模型视图、过程视图、协作视图、动态视图）：描述设计的并发和同步等特性，关注系统非功能性需求。
• 构件视图Component View（实现模型视图、开发视图）：关注代码的静态组织与管理。
• 部署视图Deployment View（环境模型视图、物理视图）：描述硬件的拓扑结构以及软件和硬件的映射问题，关注系统非功能性需求（性能、可靠性等）。
  

每一种 UML的视图都是由一个或多个图(Diagram)组成的,一个图就是系统架构在某个侧面的表示,所有的图组成系统的完整视图。UML 规范提供下述9种基本的图形元素：

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

UML 视图与图的关系：

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

UML类图的画法

基本结构

类之间的关系

依赖关系

当发现一个类“须知道”另一个类并使用它的对象时,这两个对象之间存在依赖关系。

注意:此时声明两个类之间存在依赖关系时,仅仅说明它们在对象的级别上存在关系,而非对象的内部属性和操作,因此依赖关系是类之间关系最薄弱的环节。UML规范中用带有箭头的虚线表示依赖关系,并且特别注意两个概念类之间谁依赖谁。

关联关系

当一个类的属性声明另一个类的对象或者定义另一个类的对象引用时﹐说明这两个类之间存在关联关系。

聚合关系

当一个类A(整体类)拥有另一个类B(部分类),同时其他的类C也可分享类B,即类B不完全被类A所拥有时,它们之间存在聚合关系。

类的组合关系

当一个类A(整体类)完全拥有另一个类B(部分类),且其他任何类都不能分享类B时，它们之间存在组合关系。当整体类消失时,部分类也不会存在。

类的继承关系

当一个类(父类)是另外一个类或一些类(子类)的类型时,它们之间存在继承或者泛化关系。

关联类

在关联建模中,存在一些情况下,需要其他类,因为它包含关于关联有价值的信息。对于这种情况,使用关联类来绑定这些基本关联。关联类和一般类一样表示。不同的是,主类和关联类之间用一条相交的点线连接。

面向对象的需求分析建模

领域模型

领域模型：领域内概念类或对象的抽象可视化表示（将客观世界中的事物可视化抽象化）。主要用于概括地描述业务背景和重要的业务流程，通过类图和活动图展示。

• 业务背景：描述概念类之间的关系，表示成能够代表业务知识结构的类图。
• 业务流程：由角色及其执行的活动构成。由活动图描述。

创建领域模型的步骤：

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

识别概念类或属性：

• 属性一般是可以赋值的（如数字、文本），而概念类不可以。
• 如果对一个名词是概念类还是属性不确定，将其作为概念类处理。
• 不存在名词到类的映射机制，因为自然语言具有二义性。

领域模型中的关联可分为两种：“需要知道”型和“只需理解”型关联，着重考虑前者。

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

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

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

用例模型

用例模型是“目标系统”的逻辑模型，定义了目标系统“做什么”的需求。由四部分组成：
以用例为核心从使用者的角度描述和解释待构建系统的功能需求

• 用例图
• 用例说明
• 系统顺序图 SSD
• 操作契约 Operation Contract

创建用例模型的步骤：

1. 确定问题域的分析范围;
2. 确定该范围内可能出现的角色；
3. 根据业务背景或者领域模型，确定每个角色需要的用例，并形成用例图；
4. 基于确定的用例，整理成规范的用例描述文本；
5. 在可能的情况下，将多个角色的用例图整合成一个相对完整的用例图；
6. 针对每个用例，结合相应的用例描述，确定系统顺序图中角色与系统之间的交互，绘制基于用例的系统顺序图；
7. 基于每个系统顺序图，确定每个事件交互经过系统处理后应该返回给角色的声明性结果，即操作契约；

用例图：由三个基本元素组成。

• Actor：称为角色或参与者，使用系统的对象（不一定是人）。
• Usecase：用例，描述角色如何使用系统功能实现需求目标的一组成功场景和一系列失败场景的集合。
• Association：角色和用例之间的关系、用例和子用例之间的关系。

用例之间的关系：

• 包含：一部分行为经常会出现在多个用例中，为了避免重复，可以创建一个子功能级别的用例，并让其他的用例包含它。（比如取款包含身份验证和有效性验证两个子用例）
• 扩展：（多个）基本用例中的某些场景存在相同的条件判断的情况，可以将其抽取出来作为基本用例的子用例；

用例图示例

系统顺序图 SSD

确定角色与系统之间的交互关系，以代码风格命名。包含：

• 角色。
• 代表软件系统的对象，一般使用 system 或系统命名。
• 角色与 system 之间的交互信息，简称消息或操作。

操作契约

为系统操作定义。领域模型中业务对象接收到系统事件后，执行必须的业务处理时各业务对象的状态以及系统操作执行的结果。

第五章 结构化需求分析方法

结构化分析模型的组成
数据建模(ER)
功能建模(数据流图)
行为建模(结构化动态分析：状态迁移图、时序图、Petri⽹等)
数据字典
软件需求规格说明书（领域+用例）

需求分析的分析模型必须达到三个主要⽬标

• 描述客户的需求；
• 建⽴创建软件设计的基础；
• 定义在软件完成后可以被确认的⼀组需求。

结构化分析模型的组成

如图

数据建模

概念性数据模型基于实体-关系（ER）法，也称为实体关系模型。描述了从用户角度看到的数据，反映用户现实环境，但与软件系统中的实现方法无关。
数据对象描述：描述了数据对象实体的名称及其所有属性。
数据对象的基数：一对一、一对多、多对多。

功能建模

当数据或信息“流”过计算机系统时将会被系统的功能所处理、加⼯或变换后再将处理或变换后的数据从系统输出。基于计算机的系统可被表示为数据流图的基本结构。

数据流图有四种基本元素

数据流图的例子：医院就诊管理系统例子


第⼀层数据流图:
⽬标是要确定该层具有多少个子加工，以及子加工之间新增的数据流
解释顶层数据流图中每⼀条数据流从外部实体流⼊到系统级的加工之
后，这些数据流是如何被接收和处理的。

• 子加工的分析：尽可能将系统分解为多个⼦系统，降低问题域的复杂程度，经分析得到：挂号处理⼦系统、问诊处理⼦系统等；
• 子加工之间有⽆新增数据流：（示例）两个可能的解决⽅案

第⼆层数据流图

• 确定⼦系统内部具体的业务功能。
• 解释每⼀个数据流进⼊到加⼯后，系统内是否还存在⼀些加⼯：接收数据流、分解数据流、转换数据流、处理数据流直到存储必要的数据信息进⼊数据⽂件存储，并产⽣需求规定的数据数据流。

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

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

行为建模

为了直观地分析系统的动作，从特定的视⻆出发描述系统的⾏为，需要采⽤动态分析的方法。

其中最为常⽤的结构化动态分析方法有：

• 状态迁移图
• 时序图
• Petri⽹等