文章链接

1. 软件与软件工程

1.1.2 软件危机

计算机软件的开发和维护过程所遇到的一系列严重问题。

1) 软件危机表现

• 对软件开发成本和进度的估算很不准确
• 难以准确获取用户需求，用户不满意
• 质量很不可靠，没有适当的文档
• 缺乏方法指导和工具支持，大型软件系统经常失败
• 供不应求：软件开发生产率跟不上计算机应用的迅速发展
• 做好软件定义时期的工作，是降低软件成本提高软件质量的关键。

2) 解决途径

• 组织管理
  • 工程项目管理方法
• 技术措施
  • 软件开发技术与方法
  • 软件工具

1.2 软件工程

用工程、科学和数学的原则和方法研制、维护计算机软件的有关技术及管理方法。

1.2.1 三要素

• 方法
• 工具
• 过程

1.2.2 软件工程目标之间的关系

瀑布模型的特点：

• 阶段间具有顺序性和依赖性

• 推迟实现的观点

  瀑布模型在编码之前设置了系统分析与系统设计的各个阶段，清楚地区分逻辑设计与物理设计，尽可能推迟程序的物理实现，是按照瀑布模型开发软件的一条重要指导思想。

• 质量保证的观点

  • 每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务。
  • 每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误。

2) 快速原型模型

**增量：**小而可用的软件

增量模型的特点：

在前面增量的基础上开发后面的增量
每个增量的开发可用瀑布或快速原型模型
迭代的思路

4) 螺旋模型

螺旋模型是风险驱动的。

螺旋模型的基本思想是，使用原型及其他方法来尽量降低风险。理解这种模型的一个简便方法，是把它看作在每个阶段之前都增加了风险分析过程的快速原型模型。

构建集成模型的特点：

• 面向对象
• 基于构件库
• 融合螺旋模型特征
• 支持软件开发的迭代方法
• 软件重用

2. 可行性研究

2.4 数据流图 DFD

数据流图是一种图形化技术，它描绘信息流和数据从输入移动到输出的过程中所经受的变换（加工、处理）。

它是以图示的方式来表示软件模型

• 在数据流图中没有任何具体的物理部件，它只是描绘数据在软件中流动和被处理的逻辑过程。
• 数据流图是系统逻辑功能的图形表示，即使不是专业的计算机技术人员也容易理解它，因此是分析员与用户之间极好的通信工具
• 设计数据流程图时只需考虑系统必须完成的基本逻辑功能，完全不需要考虑怎样具体地实现这些功能。

2.4.1 顶级数据流图（0级）

第一步从问题描述中提取数 据流图的4种成份：

• 首先考虑数据的源点和终点。
• 再次考虑处理。
• 最后，考虑数据流和数据存储。系统把订货 表送到采购部，因此订货 表是一个数据流；事务需要从仓库送到系统中，显然事务是另一个数据流。产生 表和处理事务在时间上明显不匹配，所以每当有一个事务发生时立即处理它，然而每天只产生一次订货 表。因此，

2.5 数据字典 DD

数据字典是关于数据信息的集合，是数据流图中所有元素严格定义的集合

2.5.1 定义

数据字典有以下四类条目：数据项(数据流分量)、数据流、文件(数据存储)、基本加工(处理)。

1.数据流 ：要定义数据流图中的数据流就要用数据流条目。数据流条目给出了某个数据流的定义，通常是列出该数据流的各个组成数据项。

订货单(数据流条目)=配件 (数据项)+配件名+规格+数量+顾客名+地址；

2.5.2 定义方法

数据元素组成数据的方式：顺序，选择，重复，可选。

数据流条目的描述内容：

（1）名称：数据流名。

（2）别名：数据流的另一个名字。

（3）简述：对数据流的简单描述和说明。

（4）组成：描述数据流由哪些数据项组成，使用如表3-1所示的描述符 来表示数据流的组成

2.数据项条目 ：

数据流的组成成员是数据项，数据项条目是不可再分解的数据单位，是组成数据流和数据存储的最小元素。数据项条目的描述内容如下：

（1）名称：数据项名。

（2）别名：数据项的另一个名字

（3）简述：对数据项的简单描述

（9）注解：对数据项的其它补充说明。

2.6 成本/效益分析

2.6.1 成本估计

2.7 结构化分析方法SA

简介

结构化分析(Structured Analysis，简称SA 法)是面向数据流的需求分析方法，是70年代由Yourdon,Constaintine 及DeMarco 等人提出和发展，并得到广泛的应用。

结构化分析方法的基本思想是**“分解”和“抽象”**。

分解：是指对于一个复杂的系统，为了将复杂性降低到可以掌握的程度，可以把大问题分解成若干小问题，然后分别解决。

图4 是自顶向下逐层分解的示意图。顶层抽象地描述了整个系统，底层具体地画出了系统的每一个细节，而中间层是从抽象到具体的逐层过渡。

抽象：分解可以分层进行，即先考虑问题最本质的属性，暂把细节略去，以后再逐层添加细节，直至涉及到最详细的内容，这种用最本质的属性表示一个自系统的方法就是“抽象”。

2.8 结构化设计方法(SD)

2.8.1 概念

结构化分析方法（Structured Method，结构化方法）是一种软件开发方法，一般利用图形表达用户需求，强调开发方法的结构合理性以及所开发软件的结构合理性。

结构化设计方法(SD)和结构化分析方法(SA)一样遵循_抽象思维模式，采用逐步求精技术，SD通常与SA联系，即依据数据流程图设计程序的结构。

2.8.2 步骤

1) 概要设计与详细设计

概要设计

• 概要设计阶段的主要任务是设计软件的结构、确定系统是由哪些模块组成，以及每个模块之间的关系。
• 它采用结构图（包括模块、调用、数据）来描述程序的结构，此外还可以使用层次图和HIPO（层次图加输入/处理/输出图）。
• 整个过程主要包括
  • 复查基本系统模型
  • 复查并精化数据流图
  • 确定数据流图的信息流类型（包括交换流和事务流）
  • 根据流类型分别实施变换分析或事务分析
  • 根据软件设计原则对得到的软件结构图进一步优化。
• 概要设计的结果是提供一份模块设计书

详细设计

• 而详细设计阶段的主要任务则是确定应该如何具体地实现所要求的系统，得出对目标系统的精确描述。它采用自顶向下、逐步求精的设计方式和单入口单出口的控制结构。
• 常使用的工具包括程序流程图、盒图、PAD（Problem Analysis Diagram，问题分析图）、PDL（Program Design Language，程序设计语言）。

2) 结构图

如图 8-9 所示，结构图的基本成分包括模块、调用（模块之间的调用关系）和数据（模块间传递及处理数据信息）。

4) PAD 和 PDL

PAD 是问题分析图的缩写，它符合自顶向下、逐步求精的原则，也符合结构化程序设计的思想，它最大的特点在于能够很方便地转换为程序语言的源程序代码。

PDL 则是语言描述工具的缩写，它和高级程序语言很相似，也包括数据说明部分和过程部分，还可以带注解等成分，但它是不可执行的。

PDL 是一种形式化语言，其控制结构的描述是确定的，但内部的描述语法是不确定的。PDL 通常也被称为伪码。

3. 需求分析

3.1 需求分析

3.1.1 需求分析的概念

需求分析是软件定义时期的最后一个阶段，它的基本任务是准确地回答“系统必须做什么这个问题，对目标系统提出完整、准确、清晰、具体的要求。
系统分析员应该写出软件需求规格说明书，以书面形式准确地描述软件需求。

3.1.2 不同层次下的软件需求

功能性需求

• 业务需求(Business Requirements)：客户对于系统的高层次目标要求，定义了项目的远景和范畴。
• 用户需求(User Requirements)：从用户角度描述的系统功能需求与非功能需求，通常只涉及系统的外部行为而不涉及内部特性。
• 系统需求(System Requirements, SR)：系统应该提供的功能或服务，通常涉及用户或外部系统与该系统之间的交互，不考虑系统内部的实现细节。

非功能性需求

（质量、性能）

描述了不直接关联到系统功能行为的系统的方方面面。从各个角度对系统进行约束和限制，反映了客户对软件系统质量和性能的额外要求，如可靠性、可用性、性能、可支持性等。详细如响应时间、数据精度、可靠性等。

3.2 需求分析的任务

3.2.1 确定对系统的综合要求

1.功能需求
2.性能需求
3.可靠性和可用性需求
4.出错处理需求
5.接口需求
6.约束
7.逆向需求
8.将来可能提出的要求

3.2.2 分析系统的数据要求

建立数据模型 ——ER图。
描绘数据结构—— 层次方框图和 Warnier 图。
数据结构规范化。

3.2.3 导出系统的逻辑模型

根据前两项分析结果导出详细的逻辑模型，通常用 数据流图、实体- 联系图（ER图）、状态转换图 、 数据字典和主要的处理算法描述这个逻辑模型。

3.2.4 修正系统开发计划

分析建模与规格说明
模型：对事物的一种无歧义的书面描述 。

3.3 分析建模（重要）

3.5.2 活动

活动表

格式：事件名(参数表)/动作表达式**
“事件名”可以是任何事件的名称。

常用的3种标准事件：
1、entry事件指定进入该状态的动作；
2、exit事件指定退出该状态的动作；
3、do事件则指定在该状态下的动作。

需要时可以为事件指定参数表。活动表中的动作表达式描述应做的具体动作。

事件表达式

格式：事件说明［守卫条件］／动作表达式

事件说明格式：事件名(参数表)。
守卫条件是一个过程表达式。

3.5.3 实例

总体设计的基本目的就是回答“概括地说，系统应该如何实现”这个问题，因此，总体设计又称为概要设计或初步设计。

4.1 设计过程

典型的总体设计过程包括9个步骤：

（1）设想供选择的方案
（2）选取合理方案（通常至少选取三种方案：低成本、中等成本和高成本）
（3）推荐最佳方案
（4）功能分解
（5）设计软件结构
（6）设计数据库
（7）制定测试计划
（8）书写文档
（9）审查和复审

4.2 设计原理

4.2.1 模块化

模块化就是把系统划分为多个独立命名且可独立访问的模块，每个模块完成一个子功能，把这些模块集成起来，可以完成用户指定的所有功能。

4.2.2 逐步求精

为了能集中精力解决主要问题而尽量推迟对问题细节的考虑。

4.2.3 信息隐藏和局部化

信息隐藏：一个模块内包含的过程和数据，对于不需要这些信息的其他模块，是不可见，不可访问的。
局部化：把一些关系密切的软件元素物理地放得彼此靠近。

在软件结构设计时，必须遵循信息隐蔽

4.2.4 模块独立

独立的模块容易开发、维护和测试。
模块的独立程度有两个标准度量：内聚和耦合

1) 耦合

耦合是对于不同模块间互联程度的度量
耦合分为

• 数据耦合

  两个模块通过参数交换数据。数据耦合属于低耦合，系统中必须存在。

• 控制耦合

  传递的信息有控制信息。属于中等耦合。

• 特征耦合

  把整个数据结构作为参数传递，而调用模块只需数据结构中一部分。

• 公共环境耦合

  多个模块通过一个公共数据环境相互作用。
  公共环境可以是全局变量、共享的通信区等。

• 内容耦合

  • 一个模块访问另一个模块的内部数据
  • 一个模块不通过正常入口进入另一模块的内部
  • 两模块程序代码重叠
  • 一个模块有多个入口

内容耦合是最高程度耦合，应坚决避免使用内容耦合。
耦合原则：尽量使用数据耦合，少用控制耦合和特征耦合，限制公共环境耦合范围，完全不用内容耦合。

2) 内聚

分类

①偶然内聚：一个模块完成一组任务，任务之间即使有关系，关系也是很松散的。
②逻辑内聚：一个模块完成的任务在逻辑上属于相同或相似的一类。
③时间内聚：一个模块包含的任务必须在同一段时间内执行。
④过程内聚：一个模块内的处理元素是相关的，而且必须以特定次序执行。
⑤通信内聚：模块中所有元素都使用同一个输入数据和产生同一个输出数据。
⑥顺序内聚：一个模块内的处理元素和同一个功能密切相关，而且处理必须顺序执行。
⑦功能内聚：模块内所有处理元素属于一个整体，完成一个单一的功能。

内聚衡量一个模块内部各元素彼此结合的紧密程度。
内聚分为：

（1）低内聚
（2）中内聚
（3）高内聚

4.2.5 抽象

现实世界中一定事物、状态或过程之间总存在着某些相似的方面(共性)。把这些相似的方面集中和概括起来，暂时忽略它们之间的差异，这就是抽象。抽象就是抽出事物本质特性而暂时不考虑细节。

4.3 启发规则

1.改进软件结构提高模块独立性：
通过模块分解或合并，降低耦合提高内聚

5.力争降低模块接口的复杂程度
6.设计单入口单出口的模块
7.模块功能应该可以预测

4.4 面向数据流的设计方法

4.4.1 概念

面向数据流的设计方法把信息流映射成软件结构，信息流的类型决定了映射的方法。

4.4.2 信息流的类型

（1）交换流

4.4.3 变换分析

例题

练习题：
1.耦合是对软件不同模块之间互连程度的度量。各种耦合从强到弱的排列为( )。
A、内容耦合,控制耦合,数据耦合,公共环境耦合
B、内容耦合,控制耦合,公共环境耦合,数据耦合
C、内容耦合,公共环境耦合,控制耦合,数据耦合
D、控制耦合,内容耦合,数据耦合,公共环境耦合

2.软件结构图的形态特征能反映程序重用率的是( )。
A、深度
B、宽度
C、扇入
D、扇出

3.概要设计的目的是确定整个系统的( )。
A、规模
B、功能及模块结构
C、费用
D、测试方案

4.数据耦合和控制耦合相比,则( )成立。
A、数据耦合的耦合性强
B、控制耦合的耦合性强
C、两者的耦合性相当
D、两者的耦合性需要根据具体情况分析

5.当一个模块直接使用另一个模块的内部数据时,这种模块之间的耦合为( )。
A、数据耦合
B、公共耦合
C、标记耦合
D、内容耦合

6.如果在需求分析阶段采用了结构化分析方法,则软件设计阶段就应采用结构化设计方法。（）
7.概要设计与详细设计之间的关系是全局和局部的关系。（）

选择题答案：CCBBD
判断答案：对对

8.什么是软件的概要设计要设计阶段完成的主要任务是什么br> 总体设计又称概要设计,是将软件需求转化为软件体系结构、确定系统级接口、全局数据结构和数据库模式。

5. 详细设计(模块设计)

一般包括结构化程序设计，面向对象设计方法，面向数据结构设计方法(Jackson)

图（a）为 DO – UNTIL型循环结构，（b）多分支结构。

人机界面设计指南

包括一般交互指南、信息显示指南、数据输入指南。

5.3 详细设计工具

工具名	主要优点	主要缺点
程序流程图	简单直观	不考虑全局；不易表示数据结构
盒图(N-S图)	考虑全局；作用域明确	不易绘制和修改
PAD图	清晰表现逻辑结构、数据结构；有直接转换工具	~
判定表	清晰表现动作关系	含义复杂；不够简洁
判定树	形式简单	简洁性比判定表还要差
过程设计语言PDL	便于保持文档和程序一致性；便于数据结构说明	不直观

5.3.1 程序流程图

又称为程序框图，历史最悠久、使用最广泛的方法。

优点：
对控制流程的描绘很直观，便于初学者掌握。

缺点：
1、不够逐步求精，程序员只考虑程序的控制流程，而不考虑全局结构。
2、用箭头代表控制流，因此程序员不受任何约束，可以完全不顾结构程序设计的精神，随意转移控制。
3、不易表示数据结构。

优点：

• 使用表示结构化控制结构的PAD符 设计出来的程序必然是结构化程序。
• 描绘的程序结构十分清晰。
• 程序逻辑易读、易懂、易记。
• 容易将PAD图转换成高级语言源程序，可用软件工具自动完成。
• 即可表示程序逻辑，也可描绘数据结构。
• 支持自顶向下、逐步求精方法的使用。
• 能够详细地表现程序的层次结构

优点：
能清晰地表示复杂的条件组合与应做的动作之间的对应关系。

缺点：
1.含义无法一眼看出，需要有一个简短的学习过程。
2.当数据元素的值多于两个时，判定表的简洁程度也将下降。

5.3.5 判定树

判定树是判定表的变种，也能清晰地表示复杂的条件组合与应做的动作之间的对应关系。多年来判定树一直受到人们的重视，是一种比较常用的系统分析和设计的工具。

优点：
它的形式简单，一眼就可以看出其含义，因此易于掌握和使用。

缺点：
简洁性不如判定表，数据元素的同一个值往往要重复写多遍，而且越接近树的叶端重复次数越多。

画判定树时分枝的次序可能对最终画出的判定树的简洁程度有较大影响。

例题

利用判定树：

5.3.6 过程设计语言(PDL)

也称为伪码，它是用正文形式表示数据和处理过程的设计工具。

PDL具有严格的关键字外部语法，用于定义控制结构和数据结构；同时，PDL表示实际操作和条件的内部语法通常又是灵活自由的，可以适应各种工程项目的需要。它使用一种语言的词汇，同时却使用另一种语言的语法。

伪代码的基本控制结构：

• 简单陈述句结构：避免复合语句。
• 判定结构：IF_THEN_ELSE或CASE_OF结构。
• 选择结构：WHILE_DO或REPEAT_UNTIL结构。

特点：

• 关键字的固定语法，它提供了结构化控制结构、数据说明和模块化的特点。
• 自然语言的自由语法，它描述处理特点。
• 数据说明的手段。应该既包括简单的数据结构，又包括复杂的数据结构。
• 模块定义和调用的技术，应该提供各种接口描述模式。

声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！