软件设计师-软件工程

自顶向下，逐步分解

数据的输入，存储都涉及不同的数据结构，面向数据结构的基本思想是根据数据结构导出程序结构。

典型的面向数据结构的设计方法包括 

面向数据结构的设计方法并没有明显地使用软件结构的概念，对于模块独立性原则也重视不足，因此并不适合于复杂的软件系统

用于发现需求，描述需求，主要包括功能需求、性能需求、环境需求、可靠性需求、
安全保密要求、用户界面需求、资源使用需求、软件成本消耗与开发进度需求、预先估计以
后系统可能达到的目标

对问题进行分析，然后在此基础上整合出解决方案

这个步骤经常是反复进行的，常用的方法有面向数据流的结构化分析方法，面向数据结构的Jackson方法，面向对象
的分析方法，以及用于建立动态模型的状态迁移图和Petri网

也就是对已经确定的需求进行文档化描述，该文档通常称为软件需
求说明书（需求规格说明书）

它是需求分析工作的最后一步，主要是对功能的正确性、完整性和清晰 性，以及其他需求给予评价

是指系统必须完成的那些事，即为了向它的用户提供有用的功能，产品必须执 行的动作

是指产品必须具备的属性或品质，如可靠性、性能、响应时间、容错性、扩 展性等

也称为限制条件、补充规约，这通常是对解决方案的一些约束说明，例如必须 采用国有自主知识版权的数据库系统、必须运行在UNIX操作系统之下等等

是指反映组织机构或客户对系统、产品高层次的目标要求，通常问题定义本身 就是业务需求

是指描述用户使用产品必须要完成什么任务、怎么完成的需求，通常是在问题 定义的基础上进行用户访谈、调查，对用户使用的场景进行整理，从而建立从用户角度的需求

是从系统的角度来说明软件的需求，它就包括了用特性说明的功能需求，质量 属性以及其他非功能需求，还有设计约束

需求开发

需求管理

在开始建立分析模型前先理解问题

开发原型

记录每个需求的起源及原因

使用多个需求视图

给需求赋予优先级

努力删除含糊性

加工

数据流

数据存储文件

数据源点或汇点

自外向内，自顶向下，逐层细化，完善求精。

保持父图与子图的平衡

根据层次关系一般将数据流图分为顶层数据流图、中间数据流图和底层数据流图

数据项条目

数据流条目

文件条目

加工条目

数据流设计

数据元素字典设计

数据处理字典设计

数据结构字典设计

数据存储设计

名称

别名或编号

分类

描述

何处使用

结构化语言

判定树

判定表

数据设计是实施软件工程中的4个设计活动的第一个。由于数据结构对程序结构和过程复杂性都 有影响，数据结构对软件质量的影响是很深远的

好的数据设计将改善程序结构和模块划分，降低过程复杂性

数据设计将分析时创建的信息域模型变换成实现软件所需的数据结构

在实体-关系图（E-R图）中定义的数据对象和关系以及数据字典中描述的详细数据内容为数据设计活动奠定了基础

主要目标是开发一个模块化的程序结构，并表示出模块间的控制关系

体系结构设计将程序结构和数据结构相结合，为数据在程序中的流动定义了接口

接口设计描述了软件内部、软件和协作系统之间以及软件域人（用户）之间如何通信

一个接口意味着信息流（如数据和/或控制流），因此，数据和控制流图提供了接口设计所需的信息

接口设计要实现的内容包括一般交互、信息显示和数据输入

过程设计应该在数据设计、体系结构设计和接口设计完成之后进行

所有的程序都可以建立在一组已有的逻辑构成元素上，这一组逻辑构成元素强调了"对功能域的维护",其中每一个逻辑构成元
素有可预测的逻辑结构，从顶端进入，从底端退出，读者可以很容易地理解过程流

过程的抽象

数据抽象

控制抽象

信息隐蔽是开发整体程序结构时使用的法则，即将每个程序的成分隐蔽或封装在一个单一的设 计模块中，并且尽可能少地暴露其内部的处理

通过信息隐蔽可以提高软件的可修改性、可测试性和可移植性，它也是现代软件设计的一个关 键性原则

模块独立是指每个模块完成一个相对独立的特定子功能，并且与其他模块之间的联系最简单

保持模块的高度独立性，也是在设计时的一个很重要的原则。通常我们用耦合（模块之间联系的紧 密程度）和内聚（模块内部各元素之间联系的紧密程度）两个标准来衡量，我们的目标是高内聚、 低耦合。

内聚

耦合

符号名的命名

程序的注释

视觉组织

数据说明的次序应当规范化，使数据属性容易查找。

当多个变量名用一个语句说明时，应当对这些变量按字母的顺序排列。

如果设计了一个复杂的数据结构，应当使用注释来说明在程序实现时这个数据结构的固有特点

在一行内只写一条语句，并且采取适当的移行格式，使程序的逻辑和功能变得更加明确

程序编写首先应当考虑清晰性，不要刻意追求技巧性，使程序编写得过于紧凑

程序编写得要简单，写清楚，直截了当地说明程序员的用意

除非对效率有特殊的要求，程序编写要做到清晰第一，效率第二。不要为了追求效率而丧
失了清晰性。事实上，程序效率的提高主要应通过选择高效的算法来实现

首先要保证程序正确，然后才要求提高速度。反过来说，在使程序高速运行时，首先要保证它是正确的

让编译程序做简单的优化

尽可能使用库函数

避免使用临时变量而使可读性下降

尽量用公共过程或子程序去代替重复的功能代码段

用调用公共函数去代替重复使用的表达式

使用括号来清晰地表达算术表达式和逻辑表达式的运算顺序

避免不必要的转移。如果能保持程序的可读性，则不必用GOTO语句

尽量只采用三种基本的控制结构来编写程序

用逻辑表达式代替分支嵌套

避免使用空的ELSE语句和IF…THEN IF…的语句

避免使用ELSE GOTO和ELSE RETURN结构。

使与判定相联系的动作尽可能地紧跟着判定。

  （18）避免采用过于复杂的条件测试。
  （19）尽量减少使用"否定"条件的条件语句。不要让读者绕弯子想。
  （20）避免过多的循环嵌套和条件嵌套。
  （21）不要使GOTO语句相互交叉。
  （22）避免循环的多个出口。
  （23）使用数组，以避免重复的控制序列。
  （24）尽可能用通俗易懂的伪码来描述程序的流程，然后再翻译成必须使用的语言。
  （25）数据结构要有利于程序的简化。
  （26）要模块化，使模块功能尽可能单一化，模块间的耦合能够清晰可见。
  （27）利用信息隐蔽，确保每一个模块的独立性。
  （28）从数据出发去构造程序。
  （29）不要修补不好的程序，要重新编写。也不要一味地追求代码的复用，要重新组织。
  （30）对太大的程序，要分块编写、测试，然后再集成。
  （31）对递归定义的数据结构尽量使用递归过程。
  （32）注意计算机浮点数运算的特点，例如：浮点数运算 10.0*0.1 通常不等于1.0.
  （33）不要单独进行浮点数的比较。用它们做比较，其结果常常发生异常情况。
  （34）避免不恰当地追求程序效率，在改进效率前，要做出有关效率的定量估计。
  （35）在程序中应有出错处理功能，一旦出现故障时不要让机器进行干预，导致停工。

黑盒测试法

白盒测试法

灰盒测试法

桌前检查（Desk Checking）

代码审查

代码走查

单元测试又称为模块测试，是针对软件设计的最小单位（程序模块）进行正确性检验的测试工
作。其目的在于检查每个程序单元能否正确实现详细设计说明中的模块功能、性能、接口和设计约
束等要求，发现各模块内部可能存在的各种错误。单元测试需要从程序的内部结构出发设计测试用
例，多个模块可以平行地独立进行单元测试。

单元测试的计划通常是在软件详细设计阶段完成的。

集成测试也称为组装测试、联合测试（对于子系统而言，则称为部件测试）。它主要是将已通
过单元测试的模块集成在一起，主要测试模块之间的协作性。

集成测试计划通常在软件概要设计阶段完成。

确认测试也称为有效性测试，主要验证软件的功能、性能及其他特性是否与用户要求（需求）
一致。确认测试计划通常在需求分析阶段完成

根据用户的参与程度，通常包括4种类型

如果项目不只包含软件，还有硬件和网络等，则要将软件与外部支持的硬件、外设、支持软 件、数据等其他系统元素结合在一起，在实际运行环境下，对计算机系统的一系列集成与确认测 试

一般地，系统测试的主要内容包括功能测试、健壮性测试、性能测试、用户界面测试、安全性 测试、安装与反安装测试等

系统测试计划通常是在系统分析阶段（需求分析阶段）完成的

性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能
指标进行测试

负载测试和压力测试都属于性能测试，两者可以结合进行，统称为负载压力测试

性能测试的目的

性能测试的类型

测试类中定义的每个方法，基本上相当于传统软件测试中的单元测试

测试封装在同一个类中的所有方法与属性之间的相互作用。在面向对象软件中类是 基本模块，因此可以认为这是面向对象测试中所特有的模块（单元）测试

也称为主题层，测试一组协同工作的类或对象之间的相互作用。大体上相当于传 统软件测试中的子系统测试，但是也有面向对象软件的特点

把各个子系统组装成完整的面向对象软件系统，在组装过程中同时进行测试

为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的误使用，应当进行的诊断和改正错误的过程就叫做改正性维护

20%

在使用过程中，外部环境（新的硬、软件配置）、数据环境（数据库、数据格式、数据输入/输出方式、数据存储介质）可能发生变化。为使软件适应这种变化，而去修改软件的过程就叫做适应性维护。

25%

在软件的使用过程中，用户往往会对软件提出新的功能与性能要求。为了满足这些要求，需要修改或再开发软件，
以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性。这种情况下进行的维护活动叫做完善性维护。

50%

这是为了提高软件的可维护性、可靠性等，为以后进一步改进软件打下良好基础