软件工程2010

计算机科学与技术学院

软件工程哈尔滨工业大学 (威海 )计算机科学与技术学院

孟凡超Email ： [email protected]

Tele:15163155787

2 计算机科学与技术学院

参考教材软件工程 -原理、方法与应用 .史济民等 ,高等教育出版社。软件工程 . 张海藩 . 人民邮电出版社。Software Engineering: Theory and Practice(软件工程 ). Shari Lawrence等，人民邮电出版社。UML2 and the Unified Process Practical Object-Oriented Analysis and Design(UML2.0和统一过程 ).Jim Arlow.机械工业出版社。…


主要内容

5555

6666

33 33

77778888

2222

4444

9999

软件测试软件测试软件维护软件维护

软件工程概述软件工程概述

软件编码软件编码软件设计软件设计

软件需求分析软件需求分析

软件质量管理软件质量管理软件工程管理软件工程管理

1111软件开发模型软件开发模型


主要内容

5555

6666

33 33

77778888

2222

4444

9999








软件工程概述主要内容软件软件工程软件工程与计算机科学的区别软件工程与计算机系统工程


软件工程概述

软件 =程序 +文档

可执行部分可执行部分不可执行部分不可执行部分

文档1

文档2

文档3

程序

软件：软件是能够完成预定义功能的可执行的计算机程序和使程序正常执行所需要的数据，加上描述程序的操作和文档。

简明地表述，可以写作：软件 =程序 +文档。


软件工程概述

main( ){ int i, j; 　 // 变量定义 char Str[10]; i = i + j ; // 语句说明 ……}

C 语言程序

Class Order{ String number; // 属性　 String customer; create() // 方法 { …… } ……} Java 语言程序

程序：程序是为了解决某个特定问题而用程序设计语言描述的适合计算机处理的语句序列。


软件工程概述程序设计语言具有良好、严格的语法和语义。目前程序设计语言主要有以下类型面向机器：如汇编语言、机器语言等面向过程：如 Fortran、 Pascal、 C等面向对象：如 C#、 Java等面向问题：如结构化查询语言 SQL等


软件工程概述文档：软件开发活动的记录，主要供人们阅读，既可用于专业人员和用户之间的通信和交流，也可以用于软件开发过程的管理和运行阶段的维护。文档类型：需求分析文档、软件设计文档、软件测试文档等。编写文档的目的促进对软件的开发、管理和维护；便于各种人员 (用户、开发人员 )的交流。


软件工程概述软件的类型系统软件：计算机系统软件是计算机管理自身资源(如 CPU、内存、外存、外设等 )，提高计算机使用效率并为计算机用户提供各种服务的基础软件。例如，操作系统、数据库管理系统等。实时软件：监测、分析和控制现实世界发生的事件，能以足够快的速度对输入信息进行处理，并在规定的时间内作出反应的软件。例如，各种设备运行监控软件等。


软件工程概述嵌入式软件：嵌入式计算机系统将计算机嵌入在某一系统之中，使之成为该系统的重要组成部分，控制该系统的运行，进而实现某一特定的物理过程。用于嵌入计算机系统的软件称为嵌入式软件。例如，航空航天系统、指挥系统、汽车控制系统等。科学和工程计算机软件：它们以数值算法为基础，对数值量进行处理和计算，主要用于科学和工程计算。例如，数值天气预报、导弹计算、石油勘探、计算辅助设计 (CAD)等。


软件工程概述事务处理软件：用于处理事务信息，特别是商务信息的计算机软件。事务信息处理是软件最大的应用领域。例如，工资管理系统、人事管理系统、企业资源计划系统 (ERP)等。人工智能软件：支持计算机系统产生人类某些智能的软件。它们求解复杂问题不是用传统的计算或分析方法，而是采用诸如基于规则的演绎推理技术和算法。应用领域有专家系统、模式识别、自然语言理解、人工神经网络、程序验证、自动程序设计、机器人学等。


软件工程概述CASE工具软件： CASE工具软件一般为支撑软件生存周期中不同活动而研制，包括项目管理工具、需求分析工具、编程环境 (编辑器、编译器、链接器和测试器于一体 )、软件测试工具等。


软件工程概述软件的特征不会老化逻辑产品 (智力、无形 )

维护困难和复杂生产只需复制软件开发性质如成本、进度等难以估计软件的开发更加依赖于开发人员的业务素质、智力、人员的合作、组织和管理


软件工程概述软件工程：软件工程是用工程、科学和数学的原则与方法研制、维护计算机软件的有关技术及管理方法。首次提出： 1968 年，北大西洋公约组织在原西德召开计算机科学会议，由 Fritz Bauer 首次提出了“软件工程”的概念。提出背景：解决软件危机。


软件工程概述软件危机什么是软件危机软件危机的表现软件危机的根源软件危机的解决途径


软件工程概述软件危机：软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。

两个主要问题如何开发软件，以满足对软件的日益增长的需求。如何维护数量不断膨胀的已有软件。


软件工程概述软件危机的表现软件成本高

IBM 360 OS, 5000 多人年，耗时 4 年 (1963 －1966)，花费 2 亿多美元美国空军： 1955 年软件占总费用 (计算机系统 )的 18%， 70 年 60%， 85 年达到 85 ％美国全球军事指挥控制系统，硬件 1 亿美元，软件高达 7.2 亿美元


软件工程概述软件质量得不到保证软件应用面的扩大：科学计算、军事、航空航天、工业控制、企业管理、办公、家庭软件越来越多的应用于安全犹关 (safety critical)的系统，对软件质量提出更高的要求80 年代欧洲亚丽安娜火箭的发射失败，原因是软件错误美国阿托拉斯火箭的发射失败，原因是软件故障


软件工程概述英国 1986 年开发的办公室信息系统 Folios 经 4年，因性能达不到要求， 1989 年取消日本第 5 代机因为软件问题在投入 50 亿美元后于1993 年下马


软件工程概述软件进度难以控制项目延期比比皆是由于进度问题而取消的软件项目较常见只有一小部分的项目能够按期完成


软件工程概述软件维护非常困难软件维护的多样性软件维护的复杂性软件维护的副作用


软件工程概述软件成本占系统总成本的比例逐年上升

软件、硬件成本变化趋势


软件工程概述软件危机的根源与软件本身的特点有关。软件不同于硬件，它是计算机系统的逻辑部件而不是物理部件。在写出程序代码并在计算机运行之前，软件开发过程的进展情况较难衡量，软件开发的质量也较难评价。因此，管理和控制软件开发过程相当困难。软件不易于维护。软件维护通常意味着改正或修改原来的设计，客观上使软件较难维护。软件不同于一般程序，它的规模大，不易于维护。


软件工程概述在软件开发过程中，或多或少地采用了错误的方法和技术。对用户需求没有完整准确的认识，就匆忙着手编写程序。


软件工程概述软件危机的解决途径技术措施：使用更好的软件开发方法和开发工具。组织管理措施：软件开发不是某种个体劳动的神秘技巧，而应该是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目。


软件工程概述软件工程三要素方法：软件工程方法是完成软件工程项目的技术手段，它支持项目计划和估算、系统和软件需求分析、软件设计、编码、测试和维护。工具：软件工程使用的工具是人类在开发软件的活动中智力和体力的扩展和延伸，它自动或半自动地支持软件的开发和管理、支持各种软件文档的生成。


软件工程概述过程：软件工程中的过程贯穿于整个工程的各个环节，在这一过程中，管理人员应对软件开发的质量、进度、成本等进行评估、管理和控制，包括计划跟踪与控制、成本估算、人员的组织、质量保证、配置管理等。


软件工程概述

结构化程序开发

面向对象开发

分布式对象 /系统

基于构件的开发

面向服务的开发

软件开发方法的演化


软件工程概述

数据

操作

对象

数据

消息数据

面向对象开发

对象

对象

面向对象编程范型的 3个基本特征：封装、继承和

多态。


软件工程概述

数据

对象

数据

数据

消息对象

构件的接口

基于构件开发：指以构件的创建，构件的管理以及复用已有的构件组装形成应用为基本活动的开发方法。目前有代表性的构件规范有 COM/DCOM、EJB和 CORBA。

构件：模块化的、可部署、可替换的软件系统组成部分，它封装了内部的具体实现并对外提供一组接口。


服务层

软件工程概述

服务 1 服务 2 服务 3 服务 4

异构系统的功能被封装为服务以方便复用应用 1(J2EE) 应用 2(.Net)应用 3(Legacy)

应用层

面向服务的开发：指以服务的创建、服务的管理以及复用已有的服务组装形成应用为基本活动的开发方法。面向服务的编程技术Web Service、 BPEL、 SCA等。

服务：是自治、开放、自描述、与实现无关的网络构件。


软件工程中涉及到的人员

软件工程概述

客户

发起系统

开发人员客户

构建系统

使用系统

需要的资

金合同契约

需要

软件系统

客户 (Customer)：是为将要开发的软件系统支付费用的公司、组织或个人。

开发人员 (Developer)：是为客户构建软件系统的公司、组织或个人，其中包括任何协调并指导程序员和测试人员的管理人员。

用户 (User):是将实际使用系统的人，包括坐在终端前的人、提交数据的人和阅读输出的人。


软件工程概述软件工程的目标可修改性 (modifiability)：容许对系统进行修改而不增加原系统的复杂性。有效性 (efficiency)：指软件系统的时间和空间效率。可靠性 (reliability)：能够防止因概念、设计和结构等方面的不完善造成软件系统失效，具有挽回因操作不当造成软件系统失效的能力。


软件工程概述可理解性 (understandability)：系统具有清晰的结构，能直接反映问题的需求。可维护性 (maintainability)：软件产品交付用户使用后，能够对它进行修改，以便改正潜在的错误和其它属性，使软件产品适应环境变化等方面工作的难易程度。可重用性 (reusability)：是指软件可以在多种场合使用的程度。可适应性 (adaptability)：软件在不同系统约束条件下，使用户需求得到满足的难易程度。


软件工程概述可移植性 (portability)：软件从一个计算机系统或环境搬到另一个计算机系统或环境的难易程度。可追踪性 (traceability)：根据软件需求对软件设计、程序进行正向追踪，或者根据程序、软件设计对软件需求进行逆向追踪的能力。可互操作性 (interoperability)：多个软件元素相互通信并协同完成任务的能力。


软件工程概述

LINIX UNIX Windows

Fortran Java

Application

.Net/COM

J2EE/EJB

Web service

Architecture framework design pattern

Support software middleware

C/C++

软件工程技术发展的一种途径

屏蔽计算机硬件的异构性发展了操作系统

屏蔽应用软件和开发平台之间的差异产生了体系结构 /框架 /设计模式

屏蔽操作系统之间和编程语言之间的异构性出现了支撑软件和中间件

屏蔽不同中间件之间的异构性发展了Web服务


软件工程概述

LINIX UNIX Windows

Fortran Java

Application

.Net/COM

J2EE/EJB

Web service

Architecture framework design pattern

Support software middleware

C/C++

软件工程技术发展的一种途径


软件工程概述软件工程与计算机科学的区别计算机科学研究的是构成计算机和软件系统基础的有关理论和方法。软件工程研究软件制作中的一些实际问题。软件工程应以计算机科学理论作为基础。软件工程是一门实践性比较强的学科。对于实际、复杂的问题，计算机科学的经典理论不可能总是适用的，这时需要软件工程的方法来解决。


软件工程概述软件工程与计算机系统工程系统：系统是一组相互关联、能在一起工作从而达到某个目标的相关元素的集合。计算机系统：通过处理信息来完成某些预定义目标而组织在一起的元素的集合或排列。计算机系统构成要素：软件 (Software)、硬件 (Hardware)、人 (People)、数据库 (Database)、文档 (Document)、过程 (Procedure)。


软件工程概述

系统

过程

硬件

软件

人数据库

文档

输入输出

基于计算机的系统要素


软件工程概述计算机系统工程：是指与构造基于计算机系统有关的过程、方法和技术。硬件工程软件工程人机交互工程数据库工程


主要内容

5555

6666

33 33

77778888

2222

4444

9999








软件开发模型本章主要内容软件生存周期软件开发模型开发模型选用实例


软件开发模型软件生存周期软件生存周期：软件从定义开始，经过开发、使用和维护直到最终退役的全过程称为软件生存周期。典型的软件生存周期分为：计划时期：问题定义、可行性研究开发时期：需求分析、软件设计、编码、测试运行时期：软件维护


软件开发模型

需求分析

软件设计

编码

维护

测试

问题定义

可行性研究计划时期

开发时期

维护时期


软件开发模型软件开发模型软件开发模型：一个软件项目开发和维护的总体过程思路的框架。软件开发模型作用：指出了软件开发过程各阶段之间的关系和顺序；为软件开发过程提供原则和方法；为软件工程管理提供里程碑和进度表。


软件开发模型主要的软件开发模型

传统的软件开发模型软件演化模型面向对象开发模型形式化方法模型基于构件的软件开发模型


软件开发模型瀑布模型 (Waterfall Model)

是W.Royce于 1970 年提出。在瀑布模型中，各阶段的工作顺序展开。瀑布模型的特征阶段间的顺序性和依赖性推迟实现观点：需求分析软件设计编码质量保证观点：每一阶段都要完成规定文档，没有完成文档，就认为没有完成该阶段的任务；每一阶段都要对已有的文档进行复审，以便尽早发现问题，消除隐患。


软件开发模型用户要求

需求分析

需求规格说明

总体设计

软件结构图

详细设计

模块说明

编码程序清单

单元测试

综合测试

确认测试

系统测试瀑布模型的阶段和文档


软件开发模型瀑布模型存在问题软件开发的初始阶段指明软件系统的全部需求是困难的，有时甚至是不现实的。需求确定以后，用户和软件项目负责人要等到相当长的时间 (设计实现测试运行 )才能得到一份软件的最初版本。如果用户对这个软件提出比较大的修改意见，那么软件项目将会受到巨大的人力、财力和时间方面的损失。


软件开发模型快速原型模型 (Rapid Prototype Model)

原型：是一个部分开发的产品，它使客户和开发人员能对计划开发的系统来实现一小部分关键需求，以确保需求是一致的、可行和符合实际的。快速原型模型：首先建立一个能够反映用户主要需求的原型，让用户实际看一看未来系统的概貌，以便判断哪些功能是符合需求的，哪些还需要改进。然后将原型反复改进，最终建立完全符合用户要求的新系统。


软件开发模型

需求分析

原型评价

最终系统设计

最终系统实现

原型开发规格说明

可运行原型

用户反馈

快速原型模型的生存周期模型


软件开发模型建立快速原型的方法：原型系统仅包含未来的主要功能以及系统的重要接口。原型系统充分展示软件的可见部分，如数据的输入方式、人机界面、数据的输出格式。为了尽快向用户提供原型，开发原型系统时应尽量使用能缩短开发周期的语言和工具。将原型系统作为基础，通过补充与修改获得最终的实际系统。


软件开发模型阶段化开发模型循环周期：从编写需求文档到系统交付的时间称为循环周期。减少循环周期的方法：阶段化开发。阶段化开发方法：使用阶段化开发方法设计系统时，能够使其一部分一部分地交付，从而在系统其余部分正在开发的同时，用户已经获得了一部分功能。因此，通常会存在两个并行的系统：运行系统或产品系统和开发系统。


软件开发模型

构建发布1

构建发布 2 构建发布 3

发布 1 发布 2 发布 3

开发系统(Development System)开

发人员

用户

时间

准备用来替换现行产品系统的下一个版本

产品系统(Production System)

当前正在被客户和用户所使用的

系统

阶段开发模型的生存周期模型


软件开发模型

增量开发 (Incremental Development)

迭代开发 (Iterative Development)

在增量开发中，需求文档中指定的系统按照功能划分为子系统。定义发布时首先定义一个小的功能子系统，然后在每一个新的发

布中增加新功能。

迭代开发是在一开始就提交一个完整的系统，然后在每一个新的发布

中改变每个子系统的功能

增量开发和迭代开发


软件开发模型采用阶段化开发方法的原因即使还缺少某些功能，但在早期的发布中就可以开始培训。培训过程可以使开发人员观察某些功能的如何执行的，并为后面的发布提供改进的建议。这样开发人员可以很好地对用户的反馈做出反应；可以及早地为那些以前从未提供的功能开拓市场；当运行系统出现未预料到的问题时，经常性的发布可以使开发人员能全面、快速地修复这些问题；针对不同的发布版本，开发团队将重点放在不同的专业领域技术上。


软件开发模型螺旋模型 (Spiral Model)

螺旋模型：在瀑布模型和快速原型模型的基础上增加了风险分析。螺旋模型是一类迭代模型，每迭代一次，螺旋线就前进一周。螺旋模型步骤：确定目标、选择方案，设定约束条件，选定完成本周期所定目标和策略；


软件开发模型分析该策略可能存在的风险。必要时通过一个原型来确定风险的大小，然后据此决定是按原定目标执行，还是修改目标或终止项目；在排除风险后，实现本螺旋周期的目标；最后一步是评价前一阶段的结果，并且计划下一轮的工作。


软件开发模型

确定目标、可选方案及约束

操作概念

预算 1预算 2预算 3预算 4

风险分析 1

需求、生命周期计划

约束 1

约束 2

约束 3

约束 4

风险分析 2

风险分析 3

风险分析 4

原型 1 原型 2 原型 3 原型 4

软件需求

经确认的需求

开发计划软件设计

评估方案，明确并排除风险

可选方案 2 可选

方案 1

可选方案 3

可选方案 4

计划下一阶段

集成和测试计划

开发验证下一级产品

经确认的设计

详细设计

编码

单元测试

系统测试

验收测试实施计划

评审约定部分

累计费用螺旋模型的生存周期模型


软件开发模型面向对象开发模型面向对象编程语言20 世纪 60 年代 : Simula67

20 世纪 80 年代 : Smalltalk

20 世纪 90 年代 : C++ 、 Java

面向对象建模语言统一建模语言 (UML)


软件开发模型面向对象的基本概念对象：对象是对现实世界中个体或事物的抽象表示，是它的属性和相关操作的统一封装体。属性表示对象的性质，属性值规定了对象所有可能的状态。对象的操作是指该对象可以展示的外部服务。类：类用于表示某些对象的共同特征 (属性和操作 )，对象是类的实例。继承关系：它是现实世界中遗传关系的直接模拟，可以来表示类之间的内在联系以及对属性和操作的共享。子类可以沿用父类的某些特征，同时子类也可以具有自己独立的属性和操作。


软件开发模型整体 -部分关系：分为聚合和组合。聚合表示对象之间松散整体 -部分关系，例如，计算和外设置之间的关系。组合表示对象之间强的整体 -部分关系，例如，树和树叶之间的关系。消息：消息传递是对象与其外部世界相互关联的唯一途径。对象可以向其他对象发送消息以请求服务，也可以响应其他对象传来的消息，完成自身固有的某些操作，从而服务于其他对象。


软件开发模型

将新构件存入库中

标志候选构件

在构件库中查找构件

进行下一次迭代

构造构件

是否存在构件？

是

否

计划风险分析用户

通信

产品开发与发布用户评估

提取构件

构件集成模型 (Component Integration Model)


软件开发模型

UP的历史

Rational 统一过程 (RUP)是 IBMUP 的商业版本。 RU

P 是 UP 的扩展。

统一过程 (Unified Process, UP)模型


软件开发模型

需求分析设计实现测试

迭代

评估计划项目相关其他活动

UP中 5个核心工作流

其它工作流

需求 : 捕获系统应该做

什么

分析 : 精化和结构化需

求

设计 : 在系统架构内实现需求

实现 : 构造软件

测试 : 验证实现是否如期望那样工

作


软件开发模型

第 1次迭代

第 2次迭代

第 n-1次迭代

初始细化构造

移交需求

第 n次迭代

分析

设计

实现

测试

随着项目按 UP的阶段进展，每个核心工作流的工作量发生变化


软件开发模型

与需求比较后修正

形式化规格说明

形式化开发记录

变换 n

变换 2变换 1

测试

系统需求

目标系统

转换模型 (Transformation Model)


软件开发模型

计算无关模型(CIM)

平台独立模型(PIM)

代码 (Code)

平台相关模型(PSM)

PIM 是独立于任何底层平台的( 例如， EJB, .Net) 、表达软件系统业务语义的模型。

PSM 包含了所有在 PIM 中表达的功能，并且还添加了针对实现平台

的设计思想。软件系统 (Software Syste

m)

映射

产生

部署

模型模型的体系结构 (Model Driven Architecture, MDA)

CIM 是非常高级层次的抽象模型，它以一种独立于计算机的方式捕获了系统的关键需求以及问题域的词汇。


软件开发模型开发模型选用实例教材购销系统根据学校的教学计划，向选课的学生及时供应所需教材。根据缺书登记补充采购所缺的教材，通知学生补售。


主要内容

5555

6666

33 33

77778888

2222

4444

9999








软件需求分析主要内容需求分析的任务与步骤需求获取的常用方法分析建模结构化分析方法软件需求说明


软件需求分析需求分析的任务建立分析模型 (Analysis Model)

分析模型：分析模型是描述软件需求的一组模型。分析模型的作用

•记录用户对原始问题和目标软件的描述；•帮助分析人员发现用户需求中的不一致，排除不合理的部分，挖掘潜在的用户需求；•形成需求说明、进行软件设计的基础。


软件需求分析编写需求规格说明 (Software Requirement Specification, SRS)

软件需求规格说明：是软件开发人员在分析阶段需求完成的文档。软件需求规格说明的要求

•准确性和一致性•清晰性和没有二义性•直观、易读和易于修改


软件需求分析需求分析的步骤需求获取

•分析系统所包含的数据；•确定软件功能需求和界面需求；•确定质量需求。

需求提炼：分析建模•结构化分析模型 (数据流图、实体关系图、控制流图、状态转换图等 )；•面向对象分析模型 (用例图、类图、交互图等 )。


软件需求分析需求描述：编写软件需求规格说明书

•软件需求规格说明必须用统一的格式，例如，国际标准 IEEE 标准 830-1998、中国国家推荐性标准 GB9385；•指明需求来源，例如客户要求、业务规范或政法规等。

需求验证•检查软件需求规格说明的正确性、一致性性、清晰性；•确保需求说明可以作为系统验收的依据。


软件需求分析实例 . 从用户调查中了解到某高校向学生销售教材的手续是：先由院办公室的张秘书开一购书证明，学生凭证明找教材科的王会计开购书发票，向李出纳交付书款，然后到书库找保管领书。

将上述手工操作流程改为计算机处理流程。


软件需求分析(1)通过对现实环境的调查研究，获取当前系统的具体模型。

学生

张秘书

王会计

李出纳

赵保管

学生

购书申请

购书证明

购书发票

领书单书

学生购买教材的具体模型


软件需求分析(2)分析需求，建立系统分析模型，包括当前系统模型和目标系统模型。•去掉具体模型中的非本质因素，提炼出当前系统的逻辑模型。

审查有效性

学生

开发票

开领书单

发书

学生

购书单

有效购书单

发票

领书单书

学生购买教材的逻辑模型


软件需求分析•分析当前系统与目标系统的差别，建立目标系统的逻辑模型。

学生

审查并开发票

开领书单

发书

学生

购书单

发票

领书单书

计算机售书系统的逻辑模型

目标系统是一个使用计算机的系统。一般来说，它的功能比当前现行业务系统更强，不必也不

应该完全模拟现行系统！


软件需求分析(3) 整理综合需求，编写软件需求说明。

(4) 验证需求，完善和补充目标系统的描述。•通过目标系统的人 -机界面，与用户一起确认目标系统功能，并且确定哪些功能交给计算机去做，哪些功能由人工完成。•复审需求说明，补充迄今尚未考虑过的细节，例如系统的响应时间、增加出错处理等。


软件需求分析

学生

审查并开发票

开领书单

学生

购书单

发票

领书单

改进的计算机售书系统的逻辑模型

无效购书单


软件需求分析需求获取的常用方法常规的需求获取方法建立联合分析小组：由用户、系统分析员和领域专家组成。客户访谈：系统分析员深入现场，与用户方的业务人员进行多次交流。要做到“心中有数”、“了解客户”、“事先准备”。问题分析与确认：多次访谈，每次及时整理有用内容，与用户确认最终方案。


软件需求分析快速原型法在需求分析中的应用快速原型法在需求分析阶段作用：确定软件系统外部行为和特征。快速原型获取的需求

•用户界面•模拟系统的外部特征


软件需求分析

数据词典

数

据

流

图

实体关系图

状态转换图

加工

控制规

规

格

格

说

说

明

明

数据对

象

描

述功能模型

行为模型

信息模型

结构化分析建模模型


数据词典

数

据

流

图

实体关系图

状态转换图

加工

控制规

规

格

格

说

说

明

明

数据对

象

描

述功能模型

行为模型

信息模型

软件需求分析

结构化分析建模模型数据流图 (DFD)指明系统中的数据是如何流动和变换的，以及描述使用数据流进行变换的功能 .

在 DFD 中出现的每个功能的描述写在加工规格说明

(PSPEC) 中 .

状态转换图 (STD) 用于指明系统在外部事件的作用下将会如何动作，表明了系统的各种状态以及各种状态之间的变

迁 .

控制规格说明 (CSPEC) 描述了控制方面的附加信息 .

数据字典(DD) 是系统所涉及的各种数据对象的总和 .

实体关系图 (E-RD) 描述数据对象之间的关系 .

在 E-R 图中出现的每个数据对象的属性均可用数据对象说明 (DOSPE

C) 来描述 .


软件需求分析结构化分析模型的组成与描述工具数据流图 (DFD)、数据字典 (DD)和加工规格说明 (PSPEC)：这是是早期结构化分析模型的基本组成成分；控制流图 (CFD)/状态转换图 (STD)、控制规格说明 (CSPEC)：这是是早期结构化分析模型的扩展成分，用以适应实时软件的建模需求。实体关系图 (ER)/IDEF1X模型：适用于具有复杂数据结构的软件软件模型。


软件需求分析数据流图 (Data Flow Diagram, DFD)

数据流图：数据流图是用来刻画数据流和加工的信息系统建模技术。数据流图也称为泡泡图 (Bubble Chart)、变换图 (Transformation Graph) 或过程模型 (Process Model)。

加工 /转换 /处理

数据流实体数据存储

DFD图的基本符号


软件需求分析数据流 (Data Flow)：数据流是带有箭头的数据流向，表示数据元素的运动方向。数据流是一组成分固定的数据组成的。每一个数据流必须有一个合适的名字。为数据流命名时，可以从其组成成分或含义角度来考虑。数据流可以从加工流向加工，从加工流向数据存储或从数据存储流向加工，也可以数据源点流向加工或从加工流向数据终点。两个加工之间可以有几股数据流。


软件需求分析

检查取款单合理性

取款单

合理取款单

不合理取款单

账目

生产

统计

生产日报

生产月报

生产统计报表

+


软件需求分析加工 (Process)：加工表示要执行的一个功能，如检查取款单合理性、生产、统计等。加工是对数据进行的操作，如果把数据流比喻为工厂的传送带，则加工就好像工厂里的加工工序。每个加工都要有一个确定的名称来命名，名称的选取要能够反映加工的主要功能。如果加工命名发生困难，则加工中可能还包含几种类型不同的加工，需要进一步进行分解。每个加工一般有一个编号，编号说明该处理在层次分解中的位置。


软件需求分析加工通常以下列方式处理数据：只改变数据流的状态，但不改变数据流的结构。

例如，加工 “检查取款单的合理性” 用来检查每一个取款单是否合理。如果取款单合理，传送一个“合理取款单”数据流，如果不合理，则传送一个“不合理取款单”数据流，“合理取款单”和“不合理取款单”的组成成分完全一样，都是取款单，只是状态发生了变化。


软件需求分析将一种数据流转换为另一种数据流，即数据流的结构发生了变化。

例如，输入数据流“生产日报”或“生产月报”经过加工“统计”后变成输出数据流“生产统计报表”，显然，传入、传出的数据流的组成发生了变化。

生产

统计

生产日报

生产月报

生产统计报表

+


软件需求分析实体 (Entity)：也称为外部项，它既可以作为数据流的源，也可以作为数据流终点。

数据流源点

数据流终点

学生

审查并开发票

开领书单

学生

购书单发票

领书单

无效购书单


软件需求分析数据存储 (Data Store)：表示数据的存储位置，用双杠表示。数据存储和加工之间的箭头有指向数据存储、背离数据存储和双向三种 :

(1)如果加工要读数据，则数据是从数据存储流出；

(2)如果加工要写或修改数据，则数据流是流向数据存储；

(3)如果加工既要读数据，又要写数据，则数据流是双向的。


软件需求分析数据流之间的关系：与关系 (用“ *”表示 )、或关系 (用” +”表示 )、互斥关系 (用“”表示 )。

互斥关系与关系

检查取款单合理性

取款单

合理取款单

不合理取款单

账目

生产

统计

生产日报

生产月报

生产统计报表

+

或关系


软件需求分析层次 DFD

对于一个大型的系统，如果用一张数据流图画出所有的数据流和加工，则图纸将极其庞大复杂，因而难于理解。为了达到简单性要求，通常采用层次或自顶向下分解的方法，将系统 DFD中的每一个加工视为一个子系统，然后继续向下分解，直到每一个加工容易理解为止，这就是结构化分析方法“自顶向下、逐步分解”的基本原则。


软件需求分析分层 DFD 由：顶层、底层和中间层组成。

(1)顶层 DFD说明系统边界，即系统的输入和输出数据流，顶层 DFD 只有一张。

(2)底层 DFD 由一些不可再分解的加工组成，这些加工称为基本加工。

(3)在顶层和底层之间的是中间层，中间层的 DFD描述了某个加工的分解，而它的组成部分又要进一步分解。


软件需求分析

顶层 DFD

教材购销系统的层次 DFD

教材购销系统

学生

书库保管员

购书单

领书单

缺书单

进书通知

第 2 层 DFD(0)

1销售

学生

书库保管员

购书单

领书单

缺书单

进书通知

2采购

F1 教材存量表

F2 缺书登记

进书通知


软件需求分析

1.1审查购书单有效性

学生

购书单

无效购书单

领书单

发票F1 教材存量

表

F2 缺书登记

进书通知

第 3 层 DFD-销售子系统(1)

1.2开发票

1.3打印发票

1.4登记售书和打印领书单

1.5登记缺书

1.6产生补售书单

采购

有效购书单

F3 学生用书表

F4 售书登记表

发票学生

暂缺书单

补售书单


软件需求分析

销售

F1 教材存量表

F2 缺书登记

进书通知

2.3修改教材库存和待购量

2.2按出版社统计缺书

2.1按书号汇总缺书

F5 待购教材表 F6 教材一览表

书库保管员

缺书单

进书通知

第 3 层 DFD- 采购子系统(2)


软件需求分析数据字典 (Data Dictionary, DD)

数据：出现在软件中的数据可以分为 3种情况：

(1) 只含有一个数据项 ( 或数据元素 )；

(2) 由多个相关数据项组成的数据流；

(3)数据存储 (数据文件或数据库 )。


软件需求分析数据字典：数据字典是对软件系统中的每个数据规定一个条目，以保持数据在系统中的一致性。数据字典用简洁、清晰、易理解的文字描述条目，说明数据流图的加工功能、性能、要求及设计约束等。数据流图与数据字典配套使用，完整地描述软件需求。


软件需求分析

数据流名：发票别名：购书发票组成：学号 +姓名 +{书号 +单价 +数量 + 总价 }+书费合计备注：

数据流

例如，发票是一个数据流，其条目内容与书写格式如下表所示。数据项

名称数据流“发票”字典条

目


软件需求分析数据文件

例如，各班学生用书表是一个数据文件，其条目内容与书写格式如下表所示。

文件名：各班学生用书表别名：组成： {系编号 +专业和班编号 + 年级 +{书号 }}

组织：按系、专业和班编号从小到大排列备注：

数据文件“各班学生用书表”字典条目


软件需求分析数据项：无论是独立的或者包含在数据流或文件中的数据项，一般都应在字典中设置相应的条目。

数据项名：年级别名：取值及含义：F-freshman,一年级M-sophomore,二年级J-junior，三年级S-senior，四年级备注：

数据项“年级”的条目


软件需求分析

数据项名：数量别名：购书量取值：正整数备注：

数据项“数量”的条目

数据项名：书费合计别名：取值： 00.00-99.99

备注：

数据项“书费合计”的条目


软件需求分析在字典中使用 =、 +、 |、 {}、 ()等符号和注释符“ *……*”将数据流或数据文件写成公式形状的定义。符号含义“=” 表示等价于 ( 或定义为 )

A+B 表示 A和 B的顺序连接A|B 表示 A和 B的选择连接{A}n 表示 n个 A的重复连接{} 表示可以重复数据() 表示可选数据


软件需求分析例：

发票 =(学号 )+姓名 +{发票行 }+书费合计

发票行 =书号 +单价 +数量 + 总价

各班学生用书表 ={系编号 +专业和班编号 + 年级+{书号 }}

系编号 ={数字 }2 * 两位数字，例如 01,12*

专业和班编号 ={数字 }3 * 三位数字，例如 305*

年级 =F|M|J|S *在 4个字母中任选一个 *

书号 ={字母 }+{数字 } *例如，Math11, Eng2等 *


软件需求分析加工说明 (Process SPECification, PSPEC)

加工说明是对 DFD中每个加工所作出的说明， PSPEC是由输入数据、加工逻辑和输出数据等部分组成，加工逻辑阐明把输入数据转换为输出数据的策略，是加工说明的主体。加工说明的主要描述方法：结构化语言 (Structured Language)

判定表 (Decision Table)

判定树 (Decision Tree)


软件需求分析结构化语言自然语言加上结构化的形式，就形成了结构化语言。结构化语言是一种介于自然语言与程序设计语言之间的语言，既具有结构化程序清晰易读的优点，由具有自然语言的灵活性，不受程序设计语言的严格的语法约束。结构化程序可以使用顺序、选择、循环等控制结构。结构化语言借用这些结构来描述加工，其形式简单，易于用户理解。


软件需求分析判定表：判定表采用表格化的形式，适合于表达含有复杂判断的加工逻辑。判定表和结构化语言可以配合使用。判定树：判定树是判定表的图形表示，其适用场合与判定表相同。用户可以根据习惯，在两种中选用一种。


软件需求分析例，某公司为推销人员制定了奖励办法，把奖金与推销金额及预定收款的数额挂钩。凡每周推销金额不超过 10000 元，按预收货款是否超过 50%，分别奖励推销额的 6% 或 4%。反之若推销金额超过 10000 元，则按预收货款是否超过 50%，分别寄奖励推销额的 8% 或 5%。对于月薪低于 1000 元的推销员，分别另发鼓励奖 300、 200和 500、 300 元。

判定表： 44页的图 3.12

判定树： 44页的图 3.13


软件需求分析加工说明的作用是说明“做什么”，而不是“怎么做”，因此对加工逻辑的描述不宜过细，过细就变成设计，使开发人员过早地卷入如何实现的细节，但是，需求说明又是软件设计的依据，如果过简，又会使设计人员无据可依。


软件需求分析实体关系图 (Entity-Relationship Diagram, ERD)

实体关系图包括：数据对象、描述数据对象的属性以及数据对象之间的关系。数据对象：是对软件必须理解的复合信息的表示。所谓复合信息是指一系列不同性质或属性的事物。属性：定义了数据对象的性质。可以用属性来为数据对象的实例命名，描述该实例，引用另一数据对象的实例。关系：数据对象之间相互连接的方式称为关系。


软件需求分析实体关系图表示P.Chen定义的符号

实体名称实体表示

学生成绩

示例

属性名称

属性表示

学生

学号姓名性别

专业籍贯示例


软件需求分析

关系名称

关系表示

工程零件供应

供应商

1m

n

存储

仓库

1

m

示例


软件需求分析 IDEF1X模型

实体独立标识实体依赖标识实体

关系标识联接关系非标识联接关系分类关系非确定关系


软件需求分析属性 / 关键字

主关键字次关键字外来关键字


软件需求分析实体：表示具有相同属性或特征的一个现实或抽象事物的集合。实体的实例是实体抽象概念的一个具体的值。实体分为独立标识实体：不依赖于其它实体存在的实体。依赖标识实体：必须依赖于其它实体才能存在的实体，也称为丛属实体。


软件需求分析

实体名 / 实体号

实体名 / 实体号

独立实体表示符号

依赖实体表示符号

学生 /1

学生成绩 /2


软件需求分析属性：属性表示实体的特征或性质。候选关键字：候选关键字是由一个实体中的一个或多个属性组成，它唯一确定实体的每一个实例。主 / 次关键字：每个实体至少有一个候选关键字。如果一个实体中有多个候选关键字，则制定其中的一个为主关键字，其它关键字为次关键字。


软件需求分析实体名 /实体号

属性名[ 属性名 ]…

[ 属性名 ](AK1)[ 属性名 ](AK2)[ 属性名 ](AK2)

主关键字属性

次关键字

雇员 /1雇员号

身份证号码 (AK1)雇员名 (AK2)生日 (AK2)…


软件需求分析

发票 /2

发票编号学号姓名书费合计

发票行 /3

发票编号发票行号书号单价数量总价

独立标识实体依赖标识实体( 不能脱离发票而独立存在 )


软件需求分析确定联接关系：是实体间的一种关系，在这种关系中被称为父实体的每一个实例与子实体的 0、 1 或多个实例联接，子实体中的每个实例同父实体中的 0 或1个实例联接。标识联接关系：在标识连接关系中，父实体的主关键字属于子实体的主关键字。非标识连接关系：在非标识连接关系中，父实体的主关键字不属于子实体的主关键字。


软件需求分析

实体 A/1

关键字 A

实体 B/2

关键字 A(FK)关键字 B

父实体

关系名

子实体标识联接

关系


软件需求分析

零个、1个或多个

P

1个或多个

Z

0个或1个

n

只有n个

nm

有 n 到m个

(n)

参考注释中的说明

实体 A/1

关键字 A

实体 B/2

关键字 B

父实体

关系名

子实体关键字 A(FK)非标识联接

关系


软件需求分析

发票 /2

发票编号学号姓名书费合计

发票行 /3

发票编号发票行号书号单价数量总价

包含


支票账户/1

支票账户号

启用日期截止日期支票限额使用金额收费金额

存款账户/2

存款账户号

存款日期取款日期存款余额利率利息

贷款账户/2

贷款账户号

贷款日期还款日期贷款金额利率贷款余额

账户/4

账户号

类型开始日期截止日期

支票账户/1

支票账户号

支票限额使用金额收费金额

存款账户/2

存款账户号

存款余额利率利息

贷款账户/3

贷款户号

贷款金额利率贷款余额

软件需求分析分类关系：

一般实体

分类实体分类实体集

鉴别器分类属性


软件需求分析分类关系分为：完全分类关系：完全分类关系是联接两个或多个实体之间的关系，在这些实体中，存在一个一般实体，它的每个实例恰好与一个且仅与一个分类实体的一个实例相联系。一般实体的每个实例和与之相关联的一个分类实体实例描述的是现实世界的同一事物。非完全分类关系：它允许一般实体的一个实例不与任何分类实体的实例相联系，即对一般实体的分类是不完全的。


软件需求分析

一般实体一般实体鉴别器

分类实体分类实体

鉴别器

完全分类关系非完全分类关系


软件需求分析控制流图 (Control Flow Diagram, CFD)与控制说明 (Control SPECification, CSPEC)

实时系统：实时系统与现实世界的外部实体进行交互时具有鲜明的时间特性。其数据流应显式地区分为时间上连续的数据流和离散的数据流 (控制信号或事件 )。数据流图扩展： CFD是为了适应实时系统的分析而提出来的，通常与 DFD 配合使用，目的是使分析员在用 DFD和 PSPEC表示数据流和加工的同时，也能够用 CFD和 CSPEC表示控制流和控制加工。


软件需求分析CFD与 DFD的关系

DFD

PSPEC

CFD

CSPEC

行为模型

过程模型输入数据输出数据

输入控制输出控制

数据条件

加工激活信号


软件需求分析

处理 /加工数据流实体数据存储

CFD的符号

控制流被引用的控制说明

CFD的符号： CFD在 DFD的基础上增加了两个符号控制流和被引用的控制说明。


软件需求分析控制流：采用带有箭头的虚线来表示，虚线箭头表示控制流从一个加工流向另一个加工的方向。虚线箭头旁边可以标注控制信息或事件，控制信息通常取布尔值或离散值。被引用的控制说明：采用短竖线表示。控制说明主要用于描述：当事件或控制信息被感知时软件如何行动；作为事件发生的结果，哪些加工将被激活。


软件需求分析对于实时系统，在创建了 DFD(过程模型 )之后还必须创建 CFD(行为模型 )，以便描述相关的事件以及系统状态在时间坐标系中的变迁。

例如，首先画出光电管采集 DFD。


软件需求分析

光电管采集

计数传送

工控机处理

班数据处理

实时数据显示

半小时数据班数据

信号

半分钟数据

光电管采集 DFD

例如，首先画出光电管采集 DFD。


软件需求分析在光电管采集 DFD的基础上加上事件和控制信息，并加上控制说明的引用，即可得到光电管采集系统的CFD。

光电管采集 CFD

光电管采集

计数传送

工控机处理

班数据处理

实时数据显示

半小时数据班数据

信号

半分钟数据

物品经过

某型号累加

无动作

半分钟

半小时

翻屏

人工驱动信息

时钟


软件需求分析结构化分析方法

结构化分析就是使用 DFD、 DD、 ER/IDEF1X、 PSPEC(结构化语言、判定表、判定树 )、 CFD、 CSPEC和 STD等建模语言来建立结构化规格说明的目标文档。结构化分析方法步骤由顶向下对系统进行功能分解，画出分层 DFD图；由后向前定义系统的数据和加工，编制 DD和 PSPEC；编制需求规格说明书。


软件需求分析画出分层数据流图由外向里绘制 DFD

•画出系统的输入输出数据流•画出系统的内部•画出加工的内部

由顶向下绘制 DFD：绘制分层 DFD时应该注意以下几个方面问题：编号、父图与子图的平衡、局部数据存储和局部外部数据存储、分解程度等。


软件需求分析编号：为了便于管理，需要按照以下规则为数据流图和其中的加工编号：•顶层 DFD 无图号，顶层加工不编号；•第二层 DFD的图号为 0，第二层 DFD中的加工编号为 1,2,…,n；•第三层每个 DFD的编号就是父图中加工的编号，第三层每个 DFD中加工的编号由 DFD图号、小数点和局部号构成，以下各层以此类推。


软件需求分析

1 20

A B

A BV

图编号

1.1 1.21.3

A VM N1

处理编号


软件需求分析教材购销系统

DFD


软件需求分析父图与子图的平衡：父图中某个加工的输入输出数据流应该与相应子图的输入输出数据流相同，层次 DFD的这种特点称为“平衡”。平衡是指子图的所有输入数据流必须是父图中相应加工的输入数据流，子图的所有输出数据流必须是父图中相应加工的输出数据流。


软件需求分析


软件需求分析局部数据存储和局部外部数据存储•随着 DFD图的分解，在下层 DFD中允许出现父图中没有的数据存储和外部实体。•除了底层 DFD需要画出全部数据存储外，各中间层的 DFD仅显示处于加工之间的接口数据存储，其余数据存储不必画出来，以保持图面的简洁。


软件需求分析F5和 F6是采购子系统局部数据存储，与父图中的其它加工无关，所以在父图中不

必画出。F1和 F2是采购子系统与销售子系统之间的接口，所以在父图中必须

画出。


软件需求分析分解程度•分解应该自然，概念上合理、清晰；•只要不影响 DFD的易理解性，可以适当地多分解，这样可以减少 DFD的层数；•一般来说，在上层分解的快一些，而在下层则分解得慢些，这是因为约接近下层功能越具体，分解速度快会增加用户理解的困难；•每一加工分解的子加工一般不超过 7个。


软件需求分析确定数据定义与加工策略

从最低 DFD的数据终点开始，沿着 DFD一步步向数据源点回朔，来分析每一个数据项的来龙去脉。

数据流：领书单、发票、暂缺书单、购书单 (有效 /无效 )、补售书单、进书通知。数据存储：教材存量表、缺书登记、学生用书表、售书登记

数据流：缺书单、进书通知。数据存储：教材存量表、缺书登记、待购较教材表、教材一览表


软件需求分析需求分析复审父图与子图不平衡未区分局部文件和局部外部文件分解速度太快不遵守加工编号规则


软件需求分析

面向对象分析方法


软件需求分析统一建模语言 (unified Modeling language, UML)

Booch： Booch方法

Rumbaugh：对象建模技术 (OMT)

Jackson： Jackson方法


软件需求分析

统一过程 (Unified Process， UP)

UP的历史

Rational 统一过程(RUP) 是 IBMUP 的商业版本。 RUP 是

UP 的扩展。

统一过程 (Unified Process)


软件需求分析为什么称为统一

开发生命周期： UML提供用于从需求分析工程到实现，贯穿整个软件开发生命周期的可视化建模语法。

应用领域： UML 已经内应用于从关键实时嵌入式系统到管理决策支持系统中任何事物的建模。

实现语言和平台： UML独立于语言和平台。它不仅对纯粹 OO语言 (例如 Java,C#)据具有极好的支持，而且对于混合 OO语言，如 C++，甚至非 OO语言也同样有效。


软件需求分析开发过程：尽管统一过程 (UP) 及其变体可能是

OO系统的首选开发过程， UML能够支持很多其它软件工程过程。

它本身内部概念： UML在其内部概念的一个小集合的应用上，勇于尝试保持一致和统一。


软件需求分析 UML的结构


软件需求分析

图：类图复合结构图对象图包图状态图

图：组件图

图：类图复合结构图对象图

图：部署图

逻辑视图

进程视图

实现视图

部署视图图：用例图交互图

用例视图

关注：项目词汇表功能

关注：性能伸缩性吞吐量

关注：系统装配配置管理

关注：系统拓扑分发移交安装

UML架构 (4+1视图 )


软件需求分析UML架构 (4+1视图 )

用例视图：该视图把系统的基本需求捕获为一组用例以及提供构造其他视图的基础。逻辑视图：捕获问题领域的词汇，作为类和对象集合。重点展示对象和类是如何组成系统、实现所需系统行为。进程视图：建模系统中作为活动类的可执行线程和进程。


软件需求分析UML架构 (4+1视图 )

实现视图：建模组成系统系统的物理代码的文件和组件。部署视图：建模把组件物理地部署到一组物理的、可计算节点上，如计算机和外设上。


软件需求分析用例图


软件需求分析用例图：是由主题 (Subject)、用例 (Usecase)、参与者 (Actor)和关联 (执行者与用例、用例与用例、执行者与执行者 )组成。

用例 :是参与者想要系统做的事情。

参与者 (角色 ):说明当与系统直接交互时，一些外部实体采用的角色。

主题 (系统边界 )：定义由谁或什么 (即，参与者 )使用系统，系统能够为哪些参与者提供什么特定利益(即，用例 )。


软件需求分析用例规格说明：用例名称：采用动词或者动词短语描述，通过用例的名称，业务读者能够清晰地知晓用例建模的业务功能或过程。用例 ID: 它唯一地标识项目中特定的用例。简要描述：捕获用例的目的。参与者：第一参与者 - 实际触发用例的那些参与者；第二参与者 - 在用例被触发之后，与用例进行交互的参与者。


软件需求分析前置条件和后置条件：前置条件说明在用例触发之前什么必须为真，后置条件说明在用例执行之后什么必须为真。主流：用例中陈述性的、具有时序的步骤序列。附流：主流的一串分支。通常表示异常、分支和中断的路径。


软件需求分析用例名称用例 ID简要描述

参与用例的参与者前置条件

主流

后置条件附流


软件需求分析用例图中的关系参与者泛化：一般参与者和特殊参与者之间的泛化关系。用例泛化：一般用例和特殊用例之间的泛化关系。包含关系：用例之间的关系，它允许一个用例包含另一个用例的行为。扩展关系：用例之间的关系，它允许一个用例使用另一个用例中的一个或多个片段来扩展它的行为。


软件需求分析参与者泛化：一般参与者和特殊参与者之间的泛化关系。使用参与者泛化可以简化问题。


软件需求分析一般参与者

参与者泛化

特殊者泛化


软件需求分析用例泛化：一般用例和特殊用例之间的泛化关系。在用例泛化中，子用例是父用例的特殊形式，子用例可以：从父用例那里继承特征；添加新的特征；覆写 ( 改变 ) 已继承的特征。


软件需求分析用例特性继承添加覆写关系 Y Y N

扩展点 Y Y N

前置条件 Y Y Y

后置条件 Y Y Y

主流中的步骤 Y Y Y

附流 Y Y Y


软件需求分析

一般用例

特殊用例

用例泛化

例：用例泛化继承不改变 3.(3.)继承和重复编号 6.2(6.1)继承且覆写 1(o1)继承、覆写及重编号 5.2(o5.1)添加 6.3


软件需求分析

继承不改变 3.(3.)继承和重复编号 6.2(6.1)继承且覆写 1(o1)继承、覆写及重编号 5.2(o5.1)添加 6.3


软件需求分析包含关系：用例之间的关系，它允许一个用例包含另一个用例的行为。我们将包含用例称为基用例，把被包含用例称为内含用例，内含用例给它的基础用例提供行为。基础用例执行到包含点，那么执行传递给内含用例，当内含用例完成时，控制再次返回基础用例。


软件需求分析

基础用例

内含用例

包含关系


用例包含实例

软件需求分析


软件需求分析

基础用例包含用例


软件需求分析扩展关系：用例之间的关系，它允许一个用例使用另一个用例中的一个或多个片段来扩展它的行为。基础用例提供了一组扩展点，扩展点是钩子，在此可以添加新的行为，扩展用例提供了一组插入片段，这些片段被插入到基础用例钩子位置。


软件需求分析

扩展用例

基础用例扩展关系


软件需求分析

扩展类

基础用例

扩展用例

扩展类名称

单一片段插入


软件需求分析单一片段插入

基础用例扩展用例


软件需求分析多重片段插入

基础用例

扩展用例

扩展类名称


软件需求分析多重片段插入

基础用例扩展用例


软件需求分析条件扩展


软件需求分析对象图


软件需求分析对象图对象：是数据和函数的内聚单元。每个对象都是某个类的一个实例，该类定义了由该类所有对象所共有的特征。对象特征：标识：这是在时间和空间上对象唯一存在。它把该对象同所有其它对象区分开。状态：特定时刻对象所有有意义的属性值集合。行为：对象为其它对象提供的服务。在分析建模中为一组操作，调用操作可能引发状态迁移。


软件需求分析

123456Jim

300.00

Deposit()

withdraw()

getOwner()

setOwner()

属性值

操作

对象中的数据被隐藏，仅能通过调用对象的函数才能操纵数据。

封装


软件需求分析

Bank对象

Account对象

Bank对象发送信息“ withdraw 150.00”给 Account

对象

Account对象响应，调用它的取款操作。该操作减少账户余额 150.00

withdraw(150.00)

对象交互产生系统的行为交互涉及对象之间来回发送消息。当接收到消息时，则调用相应的方法，这可能引起状态

的改变。

消息机制


软件需求分析

JimsAccount:Account

accoutNumber:String=“123456”owner:String=“Jim”balance:double=300.00

对象名称类名称

属性名称

属性类型

属性值

名称分栏

属性分栏

UML对象符号


软件需求分析链接：当一个对象承载到另一个对象的对象引用时，产生链接。链接是两个对象之间的语义联系，它允许消息从一个对象发送到另一个对象。不同的OO语言以不同的方法实现链接， Java把链接实现为对象引用， C++把链接实现为指针或引用，或者通过在对象中直接包含另一个对象来实现链接。

bookClub:Club

张三 :Person

李四 :Person

王二 :Person

chairperson

secretary

member

角色名称

双向链接


软件需求分析类图


软件需求分析类：共享相同属性、操作、方法、关系或者行为的一组对象的描述符。类和对象关系每个对象恰是一个类的实例。相同类的不同对象具有相同的属性，但是可以具有这些属性的不同值。不同属性值引起相同类的不同对象的不同行为。使用构造型 <<instantiate>> 依赖，你能在类和它的对象之一之间表示实例化关系。


软件需求分析对象的实例化是使用它的类作为模板创建新对象。大多数 OO语言提供被称作构造函数的特殊操作，当需要创建对象时，调用它，构造函数创建或初始化对象，构造函数是类范围的。一些 OO语言提供被称作析构函数的特殊操作，当需要销毁对象时，调用它，析构函数在对象后起清理作用。


软件需求分析

<<entity>>Account

-number:String-owner:String-balance:double=0.0

+create(theNumber:String, theOwner:String)+deposit(amount:double)+withdraw(amount:double)+getNumber():String +getOwner():String +getBalance():double +setOwner(theOwner:String)

{author=Jim, Status=tested}

名称分栏

属性分栏

操作分栏

可见性修饰

构造型类名称标记值

初始值

类范围操作 (加下划线 )

UML类符号


软件需求分析类的命名规则以大写字母打头，混合大小写，其中每个单词以大写开头。避免缩写。尽量用完整单词来描述。如果存在特定领域的缩略词 (例如， ERP-Enterprise Resource Planning)，被广泛使用并且能够被模型的所有读者所理解，那么你可以使用它。


软件需求分析属性分栏命名规则•采用以小写字母开头，然后混合大小写。•属性名通常是名词或者名词短语。语法规则

可见性名称类型多重性初始值

visibility name: type [multiplicity]=initialValue


软件需求分析

修饰可视性名称语义+ public 能够访问该类的任何元素可以访问该类

带有的公共可视性的任何特征- private 只有该类的操作才能访问该类待有的私

有可视性的特征# protected 只有该类及其子类的操作才能访问该类

带有的保护可视性的特征~ package 与该类处于相同包中的或者是在嵌套子

包中的任何元素能够访问该类带有的包可视性的任何特征

1)可视性：可视性修饰作用于类内属性和操作。它也可以作用于关系上的角色名称。


软件需求分析

原始类型语义UML Integer 整数

UnlimitedNatural

大于等于零的整数

Boolean 可以取值 true 或者 false

String 字符的序列，字符串被双引号括起来

OCL Real 浮点数

2)类型：属性的类型可以是其他的类型或者原始类型。


软件需求分析3) 多重性：多重性允许你在一个属性上通过使用多重性表达式建模两种显著不同的事物：集合和空值。

4)初始值：当某个类实例化对象时，初始值允许你说明属性此时采用的值。

5)构造型和标记值：

<<stereotype>> attribute{tag1=value1,tag2=value2,…}address{ addedBy=“Jim”, data Added=“20MAR2004”}


软件需求分析操作分栏操作：操作是绑定到特定类的函数。操作名称通常是动词或者动词短语。操作具有的特征：名称、参数列表和返回类型。操作语法规则：

visibility name(direction parameterName:parameterType =defaultValue,…):returnType

操作签名

参数列表


软件需求分析

参数方向语义in p1:Integer 默认情况，

该操作使用 p1作为输入参数该操作以某种方式使用 p1的值p1 不能被该操作所修改

inout p2:Integer

该操作接受 p2作为输入参数 /输出参数该操作以某种方式使用 p2的值，并且接受该操作的输出p2可以被该操作所修改


软件需求分析

参数方向语义out p3:Integer

该操作使用 p3作为输出参数该参数作为接收器接受该操作输出的值P3可以被该操作所修改

return p4:Integer

该操作使用 p4作为返回值参数该操作返回 p4作为返回值之一


软件需求分析关系实例化：类与对象之间的关系。关联：关联是类间的语义联系。依赖：依赖表示两个或者多个元素之间的关系，对一个元素 (提供者 )的改变可能影响或提供信息给其他元素 ( 客户 )。继承：发生在存泛化关系的类之间。


软件需求分析

JimAccount:AccountaccoutNumber:String=“123456”owner:String=“Jim”balance:double=300.00

TomAccount:Account

accoutNumber:String=“123457”owner:String=“Tom”balance:double=1000.00

AccountaccoutNumber:Stringowner:Stringbalance:doubledeposit()withdraw()getOwner()setOwner()

<<instantiate>> <<instantiate>>

实例化


软件需求分析

Company Personemploys

1 *

关联名称导航性

多重性

Company Personemployer1 *

角色名称

多重性

employee

导航性

关联：关联是类间的语义联系。如果两个对象之间存在链接，这些对象的类间必定存在关联，这是因为链接是关联的实例 .


软件需求分析关联语法

1) 关联名称•可以前缀或后缀一个小黑箭头表明名称应该阅读的方向。•应该是动词或动词短语。•采用 lowerCamelCase格式 ( 第一个词的首字母小写 , 后面每个词的首字母大写 )。


软件需求分析•可以使用关联名称或者角色名称，但不要同时使用两者。•类有到其自身的关联，称为自反关联，它表示该类的对象可以具有到该类的其它对象的链接。

2)角色名称•可以在关联的一端或两端上为类赋予角色名称。•应该是名词或名词语法描述角色的语义。•采用 lowerCamelCase格式。


软件需求分析3) 多重性•多重性表明在任意时刻关系所能够涉及的对象数目。•对象可以任意去留，但多重性约束任意时刻对象的数目。•多重性在内部说明以逗号隔开，例如， 0..1， 3..5 。•没有默认的多重性，如果多重性没有显式地表示出来，那么多重性没有确定。


关联实例

软件需求分析

Company Personemployee

1 7

BankAccount

employer

1 1..*

owner operator

0..*0..*


软件需求分析

Order Product**可导航的

不可导航的

Company Person1 *

可导航的

可导航的

4)导航性•在关系箭头的端部显示，如果关系没有箭头，那么它是双向的。 •导航性表明消息仅能够在箭头的方向上传递。


软件需求分析5) 关联类：•关联类既是关联又是类，它可以具有属性、操作和关系。•当两个类间具有多对多关系时，有时存在一些属性，它们不能简单地放入任何一个类中，此时，可以使用关联类。


软件需求分析

Company Person* *

关联类实例

Company Person* *

salary: doubleJob关联类关联类由类、关

联和虚线组成


软件需求分析

一些对象弱相关，像计算机和它的外设

一些对象强相关，像树和树叶

聚合组合

•两类特殊的关联：聚合和组合。


软件需求分析

Computer Printer0..1 0..*

整体或聚集部分聚合

聚合语义：

聚集有时能够不依赖部分而独立存在，有时又不能；部分可以独立于聚集而独立存在；如果有一些部分遗失，聚集在某种意义上是不完整的；部分的所有权可能由几个聚集来共享。

1)聚合：聚合是一种整体 -部分关系，其中聚集由许多部分组成。


软件需求分析

如果 C是 B的部分， B是 A的部分，那么 C是 A的部分

A B C

Product

自反对称

*

*

A:Product

B:Product C:Product

D:Product

不允许循

环

•聚合是可传递的

•聚合是非对称的


软件需求分析

Product

自反对称

*

*

A:Product

B:Product C:Product

D:Product


软件需求分析

Tree leaf1 0..*

组成部分组合

2)组合：组合是一种更强形式的聚合，也具有类似的语义，但是更加受约束。组合具有传递性和非对称性。

组合与聚合的区别在于：在组合中，部分脱离了整体就不能独立存在，此外，组合中的每个部分至多属于一个整体，也只能属于一个整体；在聚合中，一个部分可以由几个整体共享。


软件需求分析

类型语义Usage(使用 ) 客户使用由提供者所提供的服务以实

现它的行为。

依赖：依赖表示两个或多个建模元素之间的关系，对于一个元素 (提供者 )的改变可能影响或提供信息给其他元素 ( 客户 )。


软件需求分析

类型语义Abstraction(抽象 ) 这表示客户和提供者之间的关系，提

供者必客户更加抽象。“更加抽象”意味着提供者和客户处于开发中的不同阶段，例如，提供者处于分析模型，客户处于设计模型。

Permission(授权 ) 提供者为客户提供某种权限以访问提供者的内容，这是一种提供者控制和限制对其内容访问的方法。


软件需求分析存在五种类型的 Usage 依赖： <<use>>、 <<call>>、 <<parameter>>、 <<send>>和 <<instantiate>>。1） <<use>>：下列任何一种情况产生 <<use>>依赖：•类 A的操作需要类 B的参数；•类 A的操作返回类 B的值；•类 A的操作在实现中使用类 B的对象，但是不是作为属性来使用。


软件需求分析

A

foo(b:B)bar():BdoSomthing()

B<<use>> 提供者客户


软件需求分析2） <<call>>：操作之间的依赖，客户操作调用提供者操作。

3） <<parameter>>：提供者是客户操作上的参数。

4） <<send>>：客户把提供者 (它必须信号 )发送到指定的目标。

5） <<instantiate>>：客户是提供者的实例 (对象与类之间的实例化关系 )。


软件需求分析

Shape

Square Circle Triangle

is a kind of

父类超类基类先辈特

化泛

化

更一般元素

更特殊元素

儿子子类后裔

泛化：泛化是一般元素和特殊元素之间的关系，特殊元素完全与一般元素一致，但是包含更多信息。


软件需求分析•类继承：类继承发生在泛化关系的类之间。子类继承父类：属性、操作、关系和约束，同时可以添加新的特征以及覆写超类的操作


软件需求分析Shape

origin:Pointwidth:intHeight:intdraw(Grahics g)getArea():intgetBoundingArea():int

Square

draw(Grahics g)getArea():int

Circle


覆写超类操作


软件需求分析•抽象操作：抽象操作没有实现，它作为占位符而存在，所有具体子类必须实现所有继承的抽象操作。•抽象类：抽象类具有一个或多个抽象操作。抽象类不能实例化，抽象类定义了其具体子类必须实现的一组抽象操作的契约。


软件需求分析

抽象操作

具体操作

抽象类

具体类

Shape

origin:Pointwidth:intHeight:intdraw(Grahics g)getArea():intgetBoundingArea():int

Square


Circle



软件需求分析•多态：多态就是“多种形态”。它允许你使用抽象类来设计系统，然后在运行时替换成具体的子类，这样系统非常灵活和容易扩展，仅添加更多子类而已。•多态操作：具有多于一种的实现。不同的类以不同的方式实现相同的多态操作，多态允许不同的实例以不同的方式响应相同的消息。


软件需求分析顺序图


软件需求分析用例实现：是由一组类所组成，这些类实现了用例中所说明的行为。

RegistrationManager

Course Student0..*0..*

registration

1 1

0..* 0..*course

student

用例分析类图


软件需求分析顺序图：表示把生命线之间的交互表示为事件的时间序列。

:RegistrationManager:Registrar

uml:Course

addCourse(“UML”)

<<create>>

生命线

激活

同步消息

返回消息

The Registrar selects “add

course”.

sd addCourse

注释

对象创建消息

对象在该点被

创建

关键字

顺序图名称


软件需求分析生命线：生命线代表交互中的单一参与者，也即，它代表特定类元的实例如何参与交互的。名称：用于引用交互中生命线。类型：类元的名称，生命线代表该类型类元的一个实例。选择器：布尔表达式，可以选择满足该条件的单一实例。如果没有选择器，生命线选择该类元的任意实例。


软件需求分析消息：消息代表交互中两条生命线之间特定种类的通讯。通讯包括操作调用、创建或者销毁实例和发送信号。同步消息：发送者等待接收者结束执行所需要的操作。异步消息：发送者不等待接收者返回，继续执行下一步。消息返回：更早消息的接收者返回控制焦点给那个消息的发送者。


软件需求分析创建消息：发送者创建由接收者说明的类元的实例。销毁消息：发送者销毁接收者。发现消息：消息的发送者在交互的范围之外。当你想要显示消息接收，但是不想显示消息来自何方，使用它。丢失消息：消息永远没有达到目的地。可以用于显示消息丢失的出错条件。


软件需求分析

aMessage(aParameter)

aMessage(aParameter)

<<create>>aMessage():A

同步消息

异步消息

返回消息

消息创建

发现消息

丢失消息


软件需求分析组合区：顺序图可以被划分区域，该区域被称为组合区。每个组合区具有一个操作符，一个或多个运算单元，以及零个或多个监护条件。操作符：操作符确定运算单元是否被执行。主要的操作符有 opt、 alt、 loop、 break、 ref和 critical。监护条件：监护条件确定运算单元是否被执行。


软件需求分析opt操作符： opt操作符表示单一运算单元执行，当且仅当监护条件为真。否则执行将在组合片段之后。 opt操作符等价于编程构件：

if(condition1) then action1


软件需求分析alt操作符： alt操作符表示进行选择。每个运算单元具有其自身的监护条件，在监护条件为真时，将执行。如果其它监护条件同时不为真时，带有监护条件的 else中的可选运算单元执行。 alt操作符等价于编程构件：

if(condition 1) then operation 1else if(condition 2) then operation 2…else if(condition n) then operation nelse operation m


软件需求分析

shoppingBasket

getItem():Item

Item

quantity:int

setQuantity():int

1

0..*

用例：管理购物篮


软件需求分析

:ShoppingBasket:Customer

item:Item

getItem()

sd ManageBasket

alt [chanageQuantity]

[deleteItem]

setQuantity()

Opt[item.quantity<=0]<<destroy>>

<<destroy>>


软件需求分析loop操作符： loop操作符表示循环。 loop操作符等价于编程构件：

loop min times then while (condition is true) loop(max-min) times使用 loop语法的要点：•没有max、min 或者 condition的 loop是无穷循环；•如果只给定min，那么 max=min；•Condition通常是布尔表达式，但是它可以是任意文本，如果它的内容清晰。


软件需求分析Break操作符：具有单一监护条件，如果它为真， break主体被执行，并且 loop 被终止。


软件需求分析sd LoopAndBreakSyntax

:A :B

loop min,max[condition1]

op1()

loop[condition2]

op2()

op3()

op4()

循环 min 次，然后当condition1为 true，循环 (max-min) 次

break[condition3]

当 condition2为 true，执行循环循环中断

结束后执行 op3

如果 break执行，op4将不执行

当 condition3为 true，循环中断


软件需求分析状态图


软件需求分析状态图：对状态机的行为进行建模，使用状态机建模的类元包括类、用例、子系统、系统。状态机的主要构成要素：状态：对象生命周期中的条件或状况，在此期间，对象满足某种条件，执行某些活动或等待某些事件。事件：具有时间和空间位置的、有意义事情的规格说明。迁移：响应事件从一个状态变化到另一个状态。


软件需求分析

Off OnturnOn

turnOffburnOut

灯泡


软件需求分析

EnteringPassword

entry/display password dialogexit/validate passwordkeypress/echo “*”help/display helpdo/get password

状态名称

入口和出口动作

内部迁移内部活动

动作语法： eventName/someAction

活动语法： do/someActivity

状态


软件需求分析

A B

event1,event2[guardcondition]/anAction

行为状态机

迁移当事件 event1和 event2发生时，如果条件 condition成立，则执行动

作 anAction


软件需求分析

OnLoan

Overdue FineDue

Terminated

[after maximumDuration]

returnBook

returnBook

payFine

Loan

[extend]

[!extend]

监护条件互斥

带有汇合和分支的交叉

连接迁移 -交叉伪状态


软件需求分析

Unpaid

Overpaid Fullypaid Partiallypaid

acceptPayment

[payment>balance] [payment<balance]

[payment=balance]

MakeRefund

acceptPayment

BankLoan

选择伪状态

连接迁移 -选择伪状态


软件需求分析事件分为：调用事件：请求在类语境的实例上调用特定的操作。信号事件：信号是在对象间异步传递的信息包。改变事件：当布尔条件由假转为真时发生。时间事件：时间事件用关键字 when和 after表示。关键字 when说明被触发的特定时刻。 After说明事件被触发的阀值时间。


软件需求分析

deposit(m)/balance=balance+m

InCredit

Rejecting withdrawalentry/logRejectedWithdraw()

Accepting withdrawalentry/balance-m

withdraw(m)[balance<m]

withdraw(m)[balance>=m]

close()

BankAccount

调用内部事件动作

调用外部事件条件入口

动作

调用事件


软件需求分析

deposit(m)/balance=balance+m

InCredit

Rejecting withdrawal

entry/logRejectedWithdraw()

Accepting withdrawal

entry/balance-m



close()

BankAccount

信号发送RejectedWithdrawal

信号事件


软件需求分析

ProcessRejectedWithdrawl(e:RejectedWithdrawal)

Calling customer

信号接收

<<signal>>RejectedWithdrawal

date:DateaccountNumber:StringrequestedAmout:doubleavailabelBalance:double


软件需求分析改变事件

deposit(m)/balance=balance+mbalance>=5000/notifyManager()

InCredit

Rejecting withdrawal

entry/logRejectedWithdraw()

Accepting withdrawal

entry/balance-m



close()

BankAccount布尔表

达式

RejectedWithdrawal


软件需求分析面向对象分析方法识别参与者发现用例类建模确定分析模型中的类 (属性和操作 )

建立类 - 关系模型 (一般 -特殊、关联、整体 -部分、依赖 )

定义主题或子系统建立对象 -行为模型


软件需求分析识别参与者使用系统主要功能的人有哪些？ (计划员 )

需要借助系统完成日常工作的人是谁？ (班组长、材料员、分厂工作人员 )

谁来维护、管理系统，保证系统正常工作？ (系统管理员 )

系统控制的硬件设备有哪些？ (光电管、 PLC、工控机、触摸屏、大屏幕 )

系统需要和哪些其他系统接口？ (物资系统 )

对系统感兴趣的人和事是哪些？ (企业领导 )


软件需求分析发现用例参与者需要从系统中获得哪些功能？需要角色做什么？

企业领导需要查看报表，了解生产任务完成情况以及材料消耗情况 (报表查询 )

计划员需要根据单耗制定材料计划 (制定材料计划 )

大屏幕需要读取实时数据，翻屏显示 (实时数据翻屏 )


软件需求分析参与者需要读取、生产、删除、修改或存储系统中的某种信息吗？

系统管理员要维护基础数据，进行排班 (基础数据维护 )

工控机会自动生成数据 (自动生成数据 )

材料员需要手工生成数据 (人工生成数据 )


软件需求分析系统中发生的事件需要通知参与者吗？参与者需要通知系统某事件吗？这些事件能干什么？

进行班数据合并时，某个班组尚未输入数据，需要通知材料员，由材料员通知班组长系统需要的输入 /输出的是什么信息？这些信息从哪里来？到哪里去？

材料员要接入物资系统数据和导入分厂数据

光电管需要自动采集数据

班组长需要通过触摸屏输入不良品数据，手工输入班数据


软件需求分析系统当前需要解决的问题是什么？

采集生产数据，实时了解显象管生产的产量和质量，计算材料单耗


软件需求分析


软件需求分析类建模确定分析模型中的类

考察系统的使用用例的实例，首先将这些实例中的名词或名词短语汇总起来，得到候选类，然后考察这些候选类的特征，进而确定哪些类应该包含在分析模型中。

例如，对光电管生产检测系统的描述中，可以确定下列为分析模型中的类？

光电管、 PLC计数器、触摸屏、工控机、大屏幕、部门、规格、流水线、工序、不良品、材料、在制品、物料、指标数据、实时数据等。


软件需求分析建立类 - 关系模型：确定类之间的关系。•一般 -特殊关系•整体 -部分关系•关联关系物料

材料在制品

国产材料进口材料显象管

荫罩屏锥


软件需求分析定义主题或子系统

复杂的系统的分析模型可以包含许多类，为了简化问题的复杂度，当类模型中的某个子集可以相互协作共同完成一组内聚的功能时，可以将它们定义为主题或子系统。主题或子系统是一种抽象，可以供指向分析模型更详细内容的引用，当从外界观察时，主题或子系统可以被视为黑盒子。


软件需求分析建立对象 -行为模型•为用例建立顺序图，描述用例的实现。•为类、子系统或整体系统建立状态图，描述类、子系统或系统的在事件的驱动下的状态变迁。


软件需求分析软件需求说明软件需求说明 (SRS)：是软件开发人员在需求分析阶段需要完成的文档。例如， IEEE830-1998、GB856D-88。软件需求说明主要内容引言；叙述在问题定义阶段确定的关于软件的目标与范围，简要地介绍系统背景、盖帽、软件项目约束和参考资料等；


软件需求分析主体部分：信息描述、功能描述、行为描述•信息描述：给出软件所包含信息的详细描述，包括信息的内容、关系、数据流向、控制流向和结构等。•功能描述：对软件功能要求说明，包括系统功能划分、每个个功能的处理说明、限制和控制描述等。•行为描述：对系统状态变化以及事件和动作的叙述，据此可以检查外部事件和软件内部控制特征。


软件需求分析质量保证：软件在交付前需要进行的功能测试和性能测试，并规定源程序和文档应该遵循的各种标准。接口描述：描述了系统的用户界面、硬件接口、软件接口和通信接口等说明。其它描述：系统设计和实现上的限制，系统的假设和依赖等其它需要说明的内容。


主要内容

5555

6666

33 33

77778888

2222

4444

9999








软件设计软件设计的任务软件设计：数据设计、体系结构设计、接口设计和过程设计。数据设计：将分析阶段创建的信息模型转变成软件实现所需的数据结构；体系结构设计：定义软件主要组成部件之间的关系；接口设计：描述软件内部、软件和接口系统之间以及软件与人之间是如何通信的；过程设计：将软件体系结构的组成部分转变成对软件组件的过程性描述。


软件设计软件设计阶段概要设计：体系结构设计和接口设计，编写概要设计文档；详细设计：确定各个软件组件的数据结构和操作，产生描述各软件组件的详细设计文档。软件设计方法 (结构化设计 )

面向数据流设计方法面向数据结构的 Jackson方法


软件设计软件设计的基本概念模块 (Module) ：模块是一个拥有明确定义的输入、输出和特性的程序实体。例如，汇编语言中的子程序FORTRAN语言中的辅助程序Pascal语言中的过程Java语言中的类和包模块化设计 (Modular Design)：将大型软件按照规定的原则划分成一个个较小的、相对独立但又相互关联的模块的过程，称为模块化设计。


软件设计抽象 (Abstraction) ：抓住事物的本质和共性。抽象体现了分层的思想，最高层级的抽象程度最高，越是到较低层次，越可以看到更多的细节。由高级抽象到低级抽象转换过程中，需要进行一连串的过程抽象和数据抽象。过程抽象：是把完成一个特定功能的动作序列抽象为一个过程名和参数表，以后通过指定过程名和实际参数调用此过程。数据抽象：把具有相同性质的一组数据对象抽象为一个数据类型名，用此类型名可以定义多个具有相同性质的数据对象。在该抽象数据类型中可以加入对该数据施加的操作。


软件设计细化 (Refinement) ：细化是与抽象相反而又互补的一个概念，细化的实质就是分解。信息隐藏 (Information Hiding) ：在把系统分解为模块时，模块内部的数据与过程对不需要了解这些数据与过程的模块隐藏起来，只有为了完成软件的总体功能而必须在模块间交换的信息，才允许在模块间传递。软件复用 (Software Reuse)：是指在开发新的软件系统时，不必从头开始，而是充分利用现有的构件来完成。面向对象技术的流行加快这一理想的实现。


软件设计模块化设计分解 (Decomposition)

问题分解复杂度 C(P1+P2)>C(P1)+C(P2)

问题分解工作量 E(P1+P2)>E(P1)+E(P2)

其中， P1、 P2 由问题 P1+P2分解而得到， C为问题的复杂度， E为解题需要的工作量。


软件设计

模块数与开发工作量的关系

1

接口成本1

模块成本

模块数

软件开发工作量

1 总成本最小成本区间


软件设计模块独立性 (Module Independence) ：独立性可以从两个方面来度量：模块本身的内聚性 (Cohesion)和模块之间的耦合 (Coupling)。内聚：内聚是指完成同一个任务时对模块各个组成部分的需要程度。耦合：耦合是指两个模块之间的相互依赖程度。

模块独立性越高，则块内联系越强，块间联系越弱。


软件设计内聚：内聚是指完成同一个任务时对模块各个组成部分的需要程度。

偶然内聚

逻辑内聚

时间内聚

过程内聚

通讯内聚

顺序内聚

功能内聚

弱强

低内聚中内聚高内聚

•偶然性内聚：模块内各组成成分在功能上是互不相关的。


软件设计

逻辑性内聚实例：计算全班学生最高分计算全班学生平均分

读入分数

计算平均分计算最高分

平均 /最高

输出结果

逻辑内聚性模块•逻辑性内聚：通常由若干个逻辑功能相似的成分组成。


软件设计•时间内聚：这类模块所包含的成分是由相同的执行时间将它们连结到一起。

例如，一个初始化模块可能包含：为变量赋值、打开某个文件等为正式处理作准备的功能，由于要求它们在同一时间内执行，故称为时间性内聚。


软件设计•过程内聚：当一个模块中包含的一组任务必须按照某一特定的次序执行时，就称为过程内聚。

过程性内聚性模块

建立方程组系数矩阵

高斯消去法

回代

高斯消去法解题流程


软件设计•通讯内聚：模块内各组成部分都使用同一种输入数据，或者产生同一输出数据。

开领书单

登记售书

领书单

售书登记表

发票

具有相同的输入数据

删除

修改售书登记表

具有相同的输出数据


软件设计•顺序内聚：模块中的各组成部分是顺序执行的。在顺序内聚模块中，上一个组成部分的输出是下一个组成部分的输入。


高斯消去法

回代

高斯消去法解题流程

顺序性内聚性模块


软件设计•功能性内聚：模块内成分结合在一起，用于完成单一任务。在这类模块中，所有的成分结合在一起，用于完成一个单一的功能。

“一个模块，一个功能”已成为模块化设计的一条准则！

在下图中，如果每个处理框编制成一个模块，则产生的 3个模块都是功能性模型。


高斯消去法

回代

功能性内聚性模块


软件设计耦合：耦合是指两个模块之间的相互依赖程度。

非直接耦合

数据耦合

特征耦合

控制耦合

外部耦合

公共耦合

内容耦合

弱强

低耦合中耦合较强耦合强耦合

•非直接耦合：模块之间没有任何联系。


软件设计•数据耦合和特征耦合：模块 x和模块 y之间通过交换数据发生联系，如果 x和 y交换的是简单变量，则 x和 y之间构成数据耦合，如果 x和 y之间交的是数据结构，则 x和 y之间构成特征耦合。

计算应扣款

计算水费

计算电费

用水量水费

用电量电费

数据耦合

计算应扣款

计算水费

计算电费

房租水电

水费电费

房租水电

房租水电=房租 +用水量 +用电量

特征耦合


结构化设计•控制耦合：如果模块 x为了控制模块 y的行为而向其传递一个控制参数，该参数是一个开关值或标记量，则 x和 y发生控制耦合。•外部耦合和公共耦合：如果模块 x和模块 y访问同一全局变量，则 x和 y发生外部耦合。如果模块 x和模块 y访问同一全局性数据结构，则 x和 y发生公共耦合。•内容耦合：如果模块 x可以直接调用模块 y中的数据，或者允许 x 直接转移到 y中去，则 x和 y发生内容耦合。


结构化设计

A

B C

D

L

N

数据结构

公共耦合


软件设计设计方法自底向上设计 (Bottom-Up Design)：将一个大的系统由顶层开始向下逐层细化，直到分解为一系列相关又独立的模块为止的过程。自顶向下设计 (Top-Down Design)：从一个局部的模块开始，逐渐扩展到整个系统的设计过程。协同设计：描述人与人之间，组与组之间的协作设计。


软件设计用户界面设计让用户驾驭软件，而不是软件驾驭用户。尽可能减少用户的记忆。保持界面的一致性。考虑用户的文化背景与偏爱。


软件设计并发系统设计并发是一种允许两个活动同时发生而不互相干扰的方法。并发系统设计的一个需要解决的重要问题是怎样确保同时执行的组件 (模块 )间对共享数据的一致性。互斥是一种同步并发进程的流行方法。


软件设计软件设计说明书范围：描述了设计工作的整体范围，其大部分内容来自软件需求说明书。数据设计：描述数据对象和形成的数据结构、外部文件和数据库结构、内部数据结构等。体系结构设计：说明从分析模型导出的软件体系结构，包括模块的层次结构。


软件设计接口设计：描述人机界面的设计规则，外部数据、系统或设备接口、内部接口及其设计规则。模块的过程设计：描述每个模块的处理说明、设计语言描述、调用其它模块和内部设计结构。其他：测试、设计约束和一些特殊注释等内容。


软件设计设计复审复审的经济效益复审目的在于及早发现设计中的缺陷和错误。纠正错误的代价。对于些大型软件的调查表明，假定纠正在设计阶段发现的一个错误花费的代价为1，则在单元测试中纠正一个错误的代价将升为 6.5，在综合测试到系统测试期间上升至 15，而在交付使用后支付的费用将高达 67。


软件设计

不扩大的差错差错检出率

扩大的差错新产生的差错

来自前阶段的差错

传往下阶段的差错

差错传播模型


软件设计设计复审的作用

00%0

10

概要设计6

0%4×1.5

25

详细设计10

20%27×3

25

编码 /单元测试10 6

4

37 10

27

94

50%0

0

综合测试

50%0

0

确认测试

50%0

0

系统测试47 24 1294

潜伏的错误

差错传播模型 ( 无设计复审 )


软件设计

070%0

10

概要设计

250%1×1.5

25

详细设计

560%10×3

25

编码 /单元测试3 2

1

15 5

10

24

50%0

0

综合测试

50%0

0

确认测试

50%0

0

系统测试12 6 324

潜伏的错误

差错传播模型 (有设计复审 )


软件设计复审的指导原则在传统的软件设计中，概要设计复审与过程设计复审应该分开进行。概要设计复审需要有用户代表和领域专家参与。应该接受被人的批评指正。复审中提出的问题应详细记录。复审结束前，应作出本次复审能否通过的结论。


软件设计复审的内容概要设计复审：重点放在系统的总体结构、模块划分、内外结构等方面。

•软件结构是否满足需求•结构形态是否合理•层次是否清晰•模块的划分是不是符合优化原则•系统的人机界面、内外部接口、以及出错处理是不是合理


软件设计过程设计复审：重点放在模块的具体设计上。

•模块设计能否满足其功能与性能要求•选择算法与数据结构是否合理，是否符合编程语言的特点•设计描述简单、清晰

复审的方式正式复审 (Formal Review)

非正式复审 (Informal Review)


软件设计传统的设计方法面向数据流设计 (SD方法 ) ：将分析阶段的数据流图作为设计的基础，在设计阶段，按照数据流图的不同类型 ( 变换型或事务型 )将它们转换为相应的软件结构。面向数据设计 (Jackson方法 )：将分析阶段的数据结构作为设计的基础，在设计阶段根据数据结构导出程序结构。

SD方法侧重体系结构设计， Jackson方法侧重于于过程设计


软件设计

数据词典

数据

流图

实体关系图

状态转换图

加工

控制规

规

格

格

说

说

明

明

数据对象描述

过程设计

接口设计

体系结构设计

数据设计

从分析模型导出设计模型


软件设计结构化设计方法SD方法是 20世纪 70 年代中期由 Stevens、Myers与 Constantine等人最先提出。20世纪 70 年代后期， Yourdon等人 SA方法，把结构化思想推广到分析阶段。


软件设计结构化设计方法步骤：概要设计 ( 体系结构设计 )

详细设计 (过程设计 )

设计评审


软件设计

P1

P2P3P4

P5

问题空间

M1 M2

M3

M4 M5

软件“解”

软件结构的演变


软件设计

P

软件“解1”

M1 M2 M3 M4 M5 M1 M2

M3

M4

M5

软件“解

3”

问题M1

M2

M3

M4 M5

软件“解

2”


软件设计结构图 (Structure Chart, SC)

结构图：软件结构概要设计阶段的工具。反映系统的功能实现以及模块与模块之间的联系与通信，即反映了系统的总体结构。结构图的表示方法：用矩形表示模块，用带箭头的连线表示模块间的调用关系。在调用关系的两旁，标出传入和传出模块的数据流。


软件设计

模块

模块间调用关系数据流

(数据信息 )

SC图的符号

数据流(控制信息 )

数据流


软件设计结构图的 6种模块：传入、传出、变换、源、漏和控制。

(a) 传入

X

Y

(b) 传出

Y

X X Y

(c) 变换

X

(d)源

X

(e)漏 (f)控制…


软件设计SC图中的模块调用简单调用：调用线的箭头指向被调用模块。

例如，在图 (a)中，允许模块 A 调用模块 B和 C，反之则不可以。调用 B时， A向它传送数据流 X和 Y， B向 A返回数据流 Z。调用 C时， A向 C传送数据流 Z。

B

A

C

X,YZ

Z

B

A

C

1 2入出

X,Y Z

Z -

1

2

(a)简单调用两种表示方法


软件设计

A

B C D

X,Y

ZZ

Y

(a)选择调用表示方法

选择调用：用菱形符号表示选择。

例如，图 (b)的左侧的菱形表示：模块 A 根据它内部的判断，来决定要不要调用模块 B；右侧的菱形表示：模块 A 按照另一判断结果，选择调用模块 C 或模块 D。


软件设计

A

B C

1 2

(c)循环调用表示方法

循环调用：用叠加在调用线始端的环形箭头表示循环。

例如，下图含义是：模块 A将根据其内在的循环重复调用 B， C等模块，直到在 A模块内部出现满足循环终止的条件为止。


软件设计数据流图的类型变换型结构：这类结构由 3部分组成：传入路径(Afferent Path)、变换中心 (Transform Center)和传出路径 (Efferent Path)。流经这 3部分的数据流分别称为传入流、变换流和传出流。

变换中心

传入路径

传出路径

基本模型

时间

传入流传出流

变换流

数据流

信息


软件设计事务型结构：这类结构由至少一条接受路径 (Reception Path)、一个事务中心 (Transaction Center)与若干条动作路径 (Action Path)组成。

…

…

T

变换传入传出

事务中心

同时存在两种结构的系统

事务型结构的系统基本模型

变换中心

接受路径

动作路径

.

.

.

事务型结构系统的基本特征是具有在多种事务中执行某类事务的能力。


软件设计SD方法的步骤复审 DFD图，必要时可再次进行修改或细化；鉴别 DFD图所表示的软件系统的结构特征，确定它所代表的软件结构是属于变换型还是事务型；按照 SD方法规定一组规则，把 DFD图转换为初始的 SC图；按照优化设计的指导原则改进初始的 SC图，获得最终 SC图。


软件设计从 DFD图导出 SC图的步骤


软件设计

变换型 DFD图初始 SC图

事务型 DFD图初始 SC图

DFD向初始 SC 映射方法

变换映射(Transform Mappin

g)

事务映射(Transaction Mappi

ng)


软件设计变换映射第一步：划分 DFD图边界

•一般依赖于具体的问题和设计人员的经验。•有些系统没有加工中心，系统的逻辑输入和逻辑输出部分完全相同数据流，此时应如实地把 DFD图划分为传入和传出两部分，不要强求一律硬分成 3个部分。


软件设计•除传入部分外，在变化中心甚至传出部分可可能从系统外部接受某些输入数据流，称为二次传入数据。分析时，应按照实情把二次传入数据看成变换中心或传出部分的一个成分，不应当作为传入部分的一部分。•有些 DFD图可能画的太粗，缺少应有的细节，遇到这种情况，设计人员可对自己用作分析的 DFD图进行补充，必要时甚至重画。


软件设计例如，对下面 DFD图进行划分，区分传入、传出和变换中心 3部分。

A B CP R

W

U VD E Q

a bc

d e

r

p

w

u v

变换中心传入部分传出部分

在 DFD图上划分传入、传出和中心加工


软件设计第二步：完成“第一级分解”，建立初始 SC图的框架。

初始 SC图的框架通常包括最上面的两层模块：顶层和第一层。任何系统的顶层只含有一个用于控制的主模块。它的下一层一般包括传入、传出和中心变换 3个模块，分别代表系统的 3个相应分支。

主模块

传入模块

变换中心模块

传出模块


软件设计

MC

MA MT ME

c,e c,e w,u

w,u 第一级分解后的 SC图

A B CP R

W

U VD E Q

a bc

d e

r

p

w

u v



软件设计

MC

MA1 Q ME1

ce w,u

第一级分解后的 SC图

(另一种画法 )

MA2 ME2P R

e p c,p

r r w u

A B CP R

W

U VD E Q

a bc

d e

r

p

w

u v



软件设计第三步：完成“第二级分解”，细化 SC图的各个分支。

对上步的结果继续进行由顶向下的分解，直至画出每个分支所需要的全部模块，称为“第二级分解”或“分支分解”。这一步得到的结果便是系统的初始 SC图。


软件设计

A

B

C

D

E

MA

a

b

c

d

e

c,e传入分支的分解

(之一 )

Read A

Get B

Get C

Read D

Get E

MA

a

b

c

d

e

A to B

B to C D to E

ab

b

c

de

传入分支的分解

(之二 )

c,e


软件设计

W

V

U

MEw

v

u

w,u

传出分支的分解

(之一 )

Write W

Write V

Put U

ME

w

v

u

w,u

U to V

uv

传出分支的分解

(之二 )


软件设计

MT

Q

w,u

P R

e

p c,p

r r

中心加工分支的分解


软件设计

初始 SC图

顶层

第一层

第二层


软件设计事务映射第一步：在 DFD图上确定事务中心、接受部分( 包括接受路径 )和发送部分 ( 包括全部动作路径 )。

事务中心通常位于 DFD图中多条路径的起点，从这里引出受中心控制的所有动作路径。向事务中心提供启动信息的路径，是系统的接受路径。动作路径通常不止一条，且每条均具有自己的结构特征。


软件设计

A E F

G H

I

…

…

T

CB D

事务中心

接受部分

发送部分

⊕⊕

传入变换传出

ab

e

g

c d

f

hi

同时具有两种结构的系统


软件设计第二步：画出 SC图框架，把 DFD图的 3个部分分别映射为事务中心控制模块、接受模块和动作模块。事务控制模块

接受模块发送模块

顶层

第一层

事务控制事务分析发送

事务型 SC图上层结构

MC

MA MS

a b,e,g

be

g


软件设计第三步：分解和细化接受分支和发送分支，按成初始SC图。

P

T1 T2 Ti

A1 A2 A3 Aj

D

1

D

2

D

k

处理层

事务层

操作层

细节层

处理层相当于发送模块

每一个动作路径映射为一个事务模块

操作层和细节层的模块被上层模块所共享，可以被多个上层模块

调用动作分支典型结构


软件设计

MC

MA MS

a b,e,g

be

g

AB

TE TG

DB DC DD

AE

DF

AG

DH DI

b

cc d

d

e

f

g

h i

初始 SC图 (一种画法 )

TB

b


软件设计结构化设计的优化原则对模块分割、合并和变动调用关系的指导规则•以提高模块的独立性为首要标准•提高内聚，降低耦合，简化模块接口•少用全局性数据和控制信息•模块大小适中


软件设计保持高扇入 /低扇出的原则•扇入：调用一个给定模块的次数。扇入高则上级模块多，能够增加模块的利用率。•扇出：一个模块直接调用其它模块数目。扇出低则表示下级模块少，可以减少模块调用和控制的复杂度。通常扇出数以 3-4个为宜，最好不超过 5-7个。

M

…

M的扇入

M

…

M的扇出


软件设计•通过增加中间层减少扇出

M

煎饼形结构

M

塔形结构


软件设计

M

塔形结构

•设计良好的软件通常具有瓮形结构，两头小，中间大。


软件设计作用域 /控制域规则•控制域：一个模块的控制域等于模块本身加上其下级模块。•作用域：一个模块的作用域是受这个模块中的判定所影响的模块。

作用域 /控制规则的含义：•作用域不要超出控制域的范围。•软件系统的判定，其位置离受它控制的模块越近越好。


软件设计

Top

X Y

A

B1

B

B2

模块 B2内有一判定，其作用域超出了 B2的控制域，违反了作用域应保持在控制域内的规则。


软件设计Top

X Y

A

B1

B

B2

判定位置移到 Top

(判定位置过高 )

Top

X Y

A

B1

B

B2

判定位置移到 Y(判定位置适中 )

Top

X Y

A B1

B

B2

判定位置移到 B，将A移到 B的下级模块

(判定位置最佳 )


软件设计


学生

购书单领书单


表

F2 缺书登记进书通知

1.2开发票

1.3打印发票

1.4登记售书

1.5登记缺书


采购

有效购书单

F3 学生用书表

F4 售书登记表

发票学生

暂缺书单

补售书单

1.7开领书单

教材购销系统的结构设计示例第一步：细化并修改 DFD图。

修改后销售子系统 DFD图

无效购书单


软件设计

销售

F1 教材存量表

F2 缺书登记

进书通知2.3

修改教材库存

和待购量



F5 待购教材表

F6 教材一览表

书库保管员

缺书单

进书通知

F7 进书登记表修改后采购子系统 DFD图


软件设计第二步：鉴别 DFD图的类别。


学生

购书单领书单


表

F2 缺书登记

进书通知

1.2开发票

1.3打印发票

1.4登记售书

1.5登记缺书


采购

有效购书单

F3 学生用书表

F4 售书登记表

发票学生

暂缺书单

补售书单

1.7开领书单

修改后销售子系统 DFD图

无效购书单


软件设计

销售

F1 教材存量表

F2 缺书登记

进书通知2.3

修改教材库存

和待购量



F5 待购教材表

F6 教材一览表

书库保管员

缺书单

进书通知

F7 进书登记表

该 DFD图属于事务型结构


软件设计第三步：画出 SC图框架。

教材购销系统

读出用户选择销售

采购

用户命令销售命令

采购命令

教材购销系统 SC框架

初售补售

初售命令

补售命令

统计缺书

登记进书

统计命令

登记命令


软件设计第四步：分解动作分支、补充动作层与细节层。

采购

统计缺书登记进书

按书号汇总缺书

按出版社统计缺书

打印缺书单

修改教材待购量

修改教材库存量

统计命令

缺书登记表

待购教材表

待购教材表

暂缺书单

进书通知

进书通知

登记命令

采购子系统初始 SC图

暂缺书单


软件设计销售

初售补售

获得有效购书单

开发票开领书单

登记售书

获取补售书单

登记缺书审查购书单有效性

读购书单

读进书登记表

初售命令

补售命令

有效购书单

有效购书单

购书单

有效购书单

发票

暂缺书单

发票

补售书单发票

领书单

补售书单

进书通知

销售子系统初始 SC图

打印发票

发票发票

打印领书单

发票发票


软件设计第五步：改进 SC图，获得最终的 SC图。

例如，对于教材购销系统，可以进行如下改进•改进系统的上层框架。

教材购销系统分析用户命令

选择用户所需功能

初售补售统计缺书登记进书

(1)(2) (3)

(4)

(1)初售命令

(2)补售命令

(3)统计缺书命令

(4)登记进书命令

最终 SC图上层框架


软件设计•改进“获取有效购书单”和“获得补售书单”分支

获得有效购书单

错购审查重购

审查

打印无效书单

有效购书单

购书单

有效购书单无效书号

有效购书单

无效书号有效

购书单无效书

号

改进后的获得有效购书单分支


软件设计

获得补售书单

读进书登记表

产生补售书单

书号

补售标志

补售书单

补售书单

改进后的获得补售书单分支


软件设计

销售子系统最终 SC图


软件设计过程设计 (详细设计 )

目的：为软件结构图 SC中的每一个模块确定采用的算法和块内数据结构，用某种选定的表达工具给出更清晰的描述。任务：为每一模块编写过程设计说明书，并设计出一组测试用例，以便在编码阶段对模块代码进行预定的单元测试。


软件设计•为每个模块确定采用的算法，选择某种适当的工具表达算法的过程，写出模块的详细过程描述；•确定每一模块使用的数据结构；•确定模块接口的细节，包括对系统外部的接口和用户界面，对系统内部其它模块的接口，以及关于模块输入数据、输出数据及局部数据的全部细节。


软件设计过程设计的原则与方法清晰第一的设计风格•20世界 60 年代， Dijkstra提出从高级语言中取消 GOTO语言建议。•优先考虑程序的清晰度，把效率的考虑放在第二位。•1972 年，Mills提出每个控制结构只该有一个入口和一个出口原则。


软件设计结构化的控制结构•1966 年， Bohm和 Jacopini 证明：任何程序的逻辑均可用顺序、选择和循环 3种控制结构或它们的组合来实现，从而在理论上为结构化程序设计奠定了基础。•1968 年 Dijkstra 建议进使用这 3种控制结构来构成程序。•1972 年，Mills提出每个控制结构只该有一个入口和一个出口原则。


软件设计

顺序 1选择

T F

1

F

T

循环 (do-While)

3种基本控制结构的流程图


软件设计结构化程序：如果在详细设计中，所有模块都只使用单入口、单出口的 3种基本控制结构，则不论一个程序包含多少个模块，也不论一个模块包含多少基本控制结构，整个程序将仍能将保持一条清晰的线索。


软件设计

F

T

循环 (do-until)

Case 1 Case 2 Case n…

多分支结构(Case)


软件设计

…GOTO n

.

.

.n…

…GOTO n

…

…n……

允许的转移不允许的转移

Goto语句允许和不允许用法


软件设计逐步细化的实现方法

例，在一组数中找出其中的最大数

第一步

1.输入一组数；

2.找出其中的最大数；

3.输出最大数。


软件设计

第二步

2.1. 任取一数，假设它就是最大数；

2.2.将该数与其余各数逐一比较；

2.3.若发现有任何数大于该以假设的最大数，即取而代之。


软件设计

第三步

1输入一个数组；

2.1令”最大数” =数组中的第一个元素；

2.2从第二个元素至最末一个元素依次做；

2.3如果新元素 >“最大数”

则“最大数” =新元素；

3输出最大数。


软件设计常用的表达工具流程图和 N-S图

S1

S2

T FC

S1 S2

While C

SWhile C

S

用 N-S图表述的基本程序结构

顺序结构选择结构重复结构


软件设计例，在一组数中找出其中的最大数

数据结构：数组、最大数

过程描述：

1 输入一个数组

2.1 令最大数为数组中的第一个元素；

2.2 从数组的第二个元素至最末一个元素依次做

2.3 如果该元素大于最大数，则将该元素的值赋予最大数

3 输出最大数


软件设计MAX=A[1]

I=2

I<N

MAX<A[I]

MAX=A[I]

I=I+1

1

1

F

FT

MAX=A[1]

FOR I=2 TO N

MAX<A[1]

MAX=A[1]

T F

流程图表述 N-S图表述

T


软件设计伪代码 (Pseudo Code)和 PDL语言

IF<条件 >

一条或数条语句

ELSEIF<条件 >


…

ELSEIF<条件 >


ELSE


ENDIF

IF 判断重复的条件


ENDIF

Do while there are input

…

Do until end statement

…

Do for each item in the

…

PDL描述的 IF结构

PDL描述的 IF结构

PDL描述的几种 Do结构


软件设计

Input array AMax=A[1]DO for i=2 to N IF Max<A[1] Set max=A[1]

一条或数条语句 ENDIFENDDO

PRINT MAX

PDL表述


软件设计过程设计示例

步骤 1：写出模块说明。模块说明由“模块功能”与“模块界面”两部分构成。

开发票

打印发票

登记缺书

有效购书单

暂缺书单

发票

开发票分支的 3个模块


软件设计开发票模块

(1)功能：•按有效购书单上的书号检索“教材存量表 (F1)”的存书数量。•若存书数量不小于购书数量，则将购书量记入发票行；若存书数量小于购书数量，则将存书数量记入发票行，并调用“登记缺书”模块。•按上述两种实际情况更新“教材存量表”的数量。


软件设计•产生由书号、单价、数量、总价组成的发票行。•累计各发票行的总价，计算出书费合计。•调用“打印发票”模块打印发票。


软件设计(2)界面 ( 接口 )：

•受“初售”模块调用。•调用“登记售书”模块。•有条件地调用“登记缺书”模块。•调用“打印发票”模块。


软件设计登记缺书模块

(1)功能：•对每项缺书产生一暂缺书单。•将暂缺书单记录入“缺书登记表”文件。

(2)界面：•缺书时由“开发票”模块调用。•打印发票模块


软件设计打印发票模块

(1)功能：•打印发票头。•为每一出售的书号打印一个发票行。•打印书费合计。

(2)界面：•受“开发票”模块调用。


软件设计步骤 2：将模块说明细化为详细逻辑。

采用 IOP图 (Input-Process-Output) 来描述每个模块的业务逻辑

(1)在 IOP图中，处理框中的内容可以用任一种详细设计工具来描述 (流程图 /N-S图 /伪代码 /PDL语言 / 其它 )。

(2)如果一个模块受其它模块调用，则该模块属于子程序的性质，所以它们的输入 /输出数据可以理解为子程序的形式参数。

(3)模块设计应该包含数据结构设计。


软件设计对每张有效购书单

令发票.班号=有效购书单.班号

令发票.姓名=有效购书单.姓名

令发票头标志=“假”

读有效购书单.购书行

如果购书行.书号=“空”

打印“无有效教材”，返回调用模块

否则

重复做

检索“教材存量表”，读出该书的记录

令原存量=教材存量表.数量

令教材存量表.数量=原存量—购书行.数量

如果教材存量表.数量<0

则发票行.数量=原存量

调用“登记缺书”模块

否则

发票行.数量=购书行.数量

将教材存量表.数量写回教材存量表文件

令发票行.书号=购书行.书号

令发票行.单价=教材存量表.单价

令发票行.总价=发票行.单价发票行.数量

令发票.书费合计=发票.书费合计+发票行.总价

调用”打印发票模块”

直至购书行.书号=“空”

调用”打印发票模块”

有效购书单

购书单行

班号

姓名

有效购书单

.班号.姓名.书号

教材存量表.数量

发票头标志：

发票

.班号.姓名.发票行

输入

开发票模块IPO图处理输出

文件

教材存量表

有效购书单 =

班号 +姓名 +{购书行 }

购书行 =书号 +数量发票 =班号 +姓名 +{发票行 }+书费合计

发票行 =书号 +单价+数量 + 总价

数据结构


软件设计


软件设计Jackson方法Jackson图： Jackson方法用图形描述数据结构和程序结构，这种图形称为 Jackson图，数据结构图中的方框表示数据，程序结构图中的方框表示模块，结构图中的“ *”表示重复，“”表示选择。Jackson方法的基本步骤：建立数据结构；以数据结构为基础，对应地建立程序结构；列出程序中要用到的各种基本操作，再将这些操作分配到程序结构中适当的模块。


软件设计三种基本结构：顺序结构：顺序结构的数据由一个或多个数据元素组成，每个元素按确定次序出现一次。选择结构：选择结构的数据包含两个或多个数据元素，每次使用这个数据时按一定条件从这些数据元素中选择一个。重复结构：重复结构的数据根据使用时的条件由一个数据元素出现零次或多次组成。


软件设计A

B C D

A seqBCD

end A

A

B C D

A select cond1B

or cond2 C

or cond3 D

end A

A

B*

A iter {until/while} condB

end A

顺序结构选择结构循环结构

A

B C D

A

B C D

A

B*

S1 I2


软件设计例：设计一个打印表格的程序，表格形式见下表，这里“类别”可以是“教师”和“学生”两种。“状态”这一项，如果“类别”是“教师”，则印出他的“工龄”，如果是“学生”则印出他的“年级”。

姓名年龄类别状态张三 22 学生 3

李四 21 学生 2

王五 30 教师 2

马六 32 教师 4


软件设计

表格

表头表体

行 *

姓名年龄类别状态

工龄年级

数据结构


软件设计产生表格

产生表头产生表体

产生行 *

产生姓名

产生年龄

产生类别

产生状态

产生工龄产生年级

程序结构


软件设计Jackson方法的设计步骤

数据结构(Jackson图 )

程序结构(Jackson图 )

程序的过程性表示(Jackson伪代码 )

程序分析程序设计

映射

Jackson 方法

问题结构(DFD图 )

软件结构(SC图 )

各模块的过程描述(PDL等工具 )

概要设计过程设计

映射

SD 方法


软件设计Jackson方法步骤用 Jackson图画出输入数据和输出数据的数据结构。找出输入数据结构和输出数据结构的多余信息，仅保留需要用到的数据单元，仍用 Jackson图表示并按照下列映射规则导出相应的程序结构。


软件设计•为每一对在输入结构和输出结构中有对应关系的数据单元画一个处理框；•为输入数据结构中的每一个剩余的数据单元画一处理框；•为输出数据结构中的每一个剩余的数据单元画一处理框；•所有处理框在程序结构图上的位置应与由它处理的数据单元在数据结构 Jackson图上的位置相对应。


软件设计

帐号 (CNO)

日期 (DATE)

付款额 (PMT)

10001 2009-1-1 200

10001 2009-1-2 100

10002 2009-2-1 400

10002 2009-3-1 400

帐号 (CNO)

余额 (BALANCE)

10001 150

10002 600

帐号 (CNO) 日期 (DATAE)

付款额 (PMT)

旧余额 (OLDBAL)

新余额 (NEWBAL)

10001 2009-1-1 200

10001 2009-1-2 100

300 150 450

10002 2009-2-1 400

10002 2009-3-1 400

800 600 1400

1100 1850

付款账 (PAY-FILE) 总账 (C-M-T)

信用卡帐目会计报表 (ACCT-REPT)


软件设计第一步：画出数据结构图

PAY-FILE

CNO-GROUP*

PAY-REC*

帐号 (CNO)

日期 (DATE)

付款额 (PMT)

10001 2009-1-1 200

10001 2009-1-2 100

10002 2009-2-1 400

10002 2009-3-1 400

付款账 (PAY-FILE)

CNO DATA PMT

付款帐数据结构


软件设计

C-M-F

CUST-REC*

BALANCE

帐号 (CNO)

余额 (BALANCE)

10001 150

10002 600

总账 (C-M-T)

CNO

总帐数据结构


软件设计

信用卡帐目表数据结构


软件设计第二步：画出程序结构图

PAY-FILE

CNO-GROUP*

PAY-REC*

C-M-F

CUST-REC*

BALANCE

ACCT REPT

CUST DATA

CNO-GROUP*

CUST TOTAL

MASTER TOTALS

CNOBAL

DATA

OLD BAL

NEW BAL

TOTAL PMT

TOTAL BAL

PAY-REC

REPT-LINE*输入数据结构与输出输入数据结构与输出数据结构对应关系数据结构对应关系


软件设计PROC ACCT REPT

PROC CUST DATA

PROC CNO-GROUP*

COMP CUST TOTAL

PROCMASTER TOTALS

PROC CNOCOMP

BAL DATA

PROC OLD BAL

COMP NEW BAL

COMPTOTAL

PMT

COMPTOTAL

BAL

PROC PAY-REC

PROC REPT-LINE*

程序结构程序结构

I1

I2


软件设计第三步：写出程序的过程性表示(1)列出循环结构的终止条件。

I1: EOF-PAY-FILE( 付款文件结束 )

I2: end of CNO GROUP(帐号组结束 )

(2)列出各框的操作和辅助操作。(3)用 Jackson伪代码写出过程性表示。


软件设计


软件设计例：将职工的姓名地址文件和工资文件合并成一个新文件。图 (a)是姓名地址文件和工资文件的结构，这两个文件均由“职工记录”重复组成，“职工记录”又由几个数据项顺序组成。图 (b)为新文件的结构。姓名和地址文件

职工记录 *

工号

姓名

地址

工资文件

职工记录 *

工号

工资

(a)(a)输入数据结构输入数据结构

新文件

职工记录 *

工号

工资

姓名

地址

(b)(b) 输出数据结输出数据结构构


软件设计

姓名和地址文件

职工记录 *

工号

姓名

地址

工资文件

职工记录 *

工号

工资

新文件

职工记录 *

工号

工资

姓名

地址

输入和输出数据结构对应关系输入和输出数据结构对应关系


软件设计

取姓名地址记录*

取工号

取姓名

取地址

取工资记录 *

取工号

取工资

产生新文件

产生新记录 *

产生工号

产生工资

产生姓名

产生地址

程序结构程序结构


软件设计例：仓库中存放了多种零件 (如 P1,P2,P3,…)，每种零件的每次变动 (收到或发出 )都有卡片作出记录。仓库管理系统每月根据这样一叠卡片打印一张月报表，表中的每行列出某种零件本月库存量的净变化。

月报表零件名增加数量P1 20

P2 -10

P3 15

P4 -12

输入文件零件名发收P1 10

P1 30

P2 20

P2 10

处理


软件设计

月报表零件名增加数量P1 20

P2 -10

P3 15

P4 -12

月报表

表头表体

行 *

输入文件零件名发收P1 10

P1 30

P2 20

P2 10

数据结构输入文件

零件组

发收


软件设计

产生月报表

产生表头产生表体

从零件组产生行 *

月报表

表头表体

行 *

输入文件

零件组

发收

处理零件组产生行

处理发处理收

程序结构输入和输出数据结构对应关系


主要内容

5555

6666

33 33

77778888

2222

4444

9999








软件编码编码的目的：使用选定的程序设计语言，把模块的过程性描述翻译为用该语言书写的源程序。

模块过程性描述源程序

( 不可执行 ) (可执行 )

编码


软件编码编码的风格：编码产生的源程序应该正确可靠、简明清晰，而且具有较高的效率是好程序的一个主要标准。为了达到这一点，应该遵循如下规则：程序内部文档。包含适当的标识符、适当的注解和程序的视觉组织等。数据说明：数据说明的次序应该标准化；当多个变量名在同一语句中说明时，应按字母顺序排列这些变量；对于复杂数据结构应该注释说明。


软件编码语句构造：•不要为节省空间将多个语句写在一行；•避免大量使用循环嵌套和条件嵌套；•利用括号使逻辑表达式或算术表达式的运算次序清晰直观。


软件编码输入 /输出•所有输入数据都进行校验；•明确提示交互式输入的请求、详细说明可用的选择或边界数值；•当程序设计语言对格式有严格要求时，应保持输入格式一致。•设计良好的输出报表。


软件编码效率•程序运行时间•存储效率•输入 /输出效率


软件编码编码使用的语言

面向机器的语言

高级语言（第三代）甚高级语言

机器语言

（第一代）

汇编语言

（第二代）

基础语言

结构化语言

面向对象语言

第四代语言


软件编码常用的编码语言基础语言： FORTRAN、 COBOL、 BASIC

结构化语言： Pascal、 C、 Ada

面向对象语言： C++、 Java


软件编码第四代语言4GL应该具有很强的数据管理能力，能对数据库进行有效的存取、查询和其他有关操作。能提供一组高效的、非过程化的命令，组成语言的基本语句。能够满足多功能、一体化的要求。


软件编码编码使用的语言应用领域算法与计算复杂性数据结构的复杂性效率考虑


软件编码年代应用领域主要语言其它语言

以前

商业 COBOL Assembler

科学计算 FORTRAN ALGOL、 BASIC、 APL

系统 Assembler Forth

人工智能 LISP SNOBOL

现在

商业 COBOL、 C++、C#、 ava

C、 PL/1

科学计算 FORTRAN、 C、C++、 Java

BASIC

系统 C、 C++、 Java

Ada、Modula

人工智能 LISP、 Prolog


主要内容

5555

6666

33 33

77778888

2222

4444

9999








软件测试软件测试的基本概念目的与任务测试 (Testing)：测试的目的是发现程序错误；测试的任务是通过在计算机上执行程序，暴露程序中潜在的错误。纠错 (Debugging)：纠错的目的是定位和纠正错误；纠错的任务是软件故障，保证程序的可靠运行。

测试评价纠错

测试数据

程序

期望结果

测试结果错误信息改正信息


软件测试测试的特性挑剔性：测试是对质量的监督与保证，所以“挑短”和“揭短”很自然成为测试人员的奉行的信条。复杂性：设计测试用例是一项需要细致和高度技巧的工作。不彻底性。程序测试只能证明错误存在，但不能证明错误不存在。经济性。选择一些典型的、有代表性的测试用例，进行有限测试。


软件测试测试的分类

静态测试(程序不执行 )

程序测试

动态测试(程序执行 )

静态分析器分析

代码评审

人工方式

代码会审

走查

办工桌检查

黑盒测试 (测试程序功能 )

白盒测试 (测试程序结构 )


软件测试测试的文档测试计划：测试计划的主体是“测试内容说明”，包括测试项目的名称、各项测试的目的、步骤和进度，以及测试用例的设计等。测试报告：测试报告的主体是“测试结果”，它包含测试项目的名称、实际测试结果与期望测试结果比较，发现问题，以及测试达到的效果。

测试用例 ={测试数据 + 期望结果 }

测试结果 ={测试数据 + 期望结果 +实际结果 }


软件测试黑盒测试等价测试把输入数据的可能值划分为若干个等价类，使每类中的任何一个测试用例，都能代表同一等价类中的其它测试用例。采用等价测试注意以下两点：•划分等价类不仅要考虑代表“有效”输入值的有效等价类，还要考虑代表“无效”输入值得无效等价类；


软件测试•每一无效等价类至少要用一个测试用例，不然可能漏掉某一类错误，但允许若干个有效等价类合用一个测试用例，以便进一步减少测试的次数。

例：某工厂公开招工，规定报名者年龄在 16 周岁至 35 周岁 (在 1967 年 2月到 1986 年 3月 )。如果出生年月不在上述范围内，将拒绝接受，并显示“年龄不合格”等出错信息。试用等价分类法设计这一程序功能的测试用例。•第一步：划分等价类


软件测试

输入数据有效等价类无效等价类出生年月 (1)6位数字字符 (2)有非数字字符

(3) 少于 6个数字字符(4) 多于 6个数字字符

对应数值 (5)在 196702-198603之间

(6)<196702

(7)>198603

月份对应数值 (8)在 1-12之间 (9)等于“ 0”

(10)>12


软件测试•第二步：设计有效等价类需要的测试用例测试数据期望结果测试范围

197011 输入有效 (1)、 (5)、 (8)

•第三步：为每一无效等价类设计一个测试用例测试数据期望结果测试范围

MAY,70 输入无效 (2)

19705 输入无效 (3)

1968011 输入无效 (4)

195512 年龄不合格 (6)

196006 年龄不合格 (7)

196200 输入无效 (9)

197222 输入无效 (10)


软件测试边界测试实践表明，程序员在处理边界情况时，很容易因忽略或考虑不周发生编码错误。例如，数组容量、循环次数以及输入数据与输出数据在边界值附近程序出错概率往往较大。采用边界值分析法就是要这样来选择测试用例，使得被测试程序能在边界值及其附近运行，从而更有效地暴露程序中潜在的错误。例如，程序可能设有语句


软件测试

If(196702<=value(birthdate)<=198603)

then read(birthdate)

else write “invalid age”

写成 <

写成 <

以上所有测试都不能发现该错误


软件测试•“出生年月”的测试用例 (边界分析法 )输入等

价类测试用例说明测试数据期望

结果选取理由

出生年月

1个数字字符5个数字字符7个数字字符有 1个非数字字符全是非数字字符6个数字字符

5

197505

1986011

19705A

AUGUST

196702

仅有一个合法字符比有效长度恰少一个字符比有效字符恰多一个字符非法字符最少非法字符最多类型与长度均有效

对应数值

35 周岁16 周岁>35 周岁<16 周岁

196702

198603

196701

198604

最大符合年龄最小符合年龄恰大于合格年龄恰小于合格年龄

输入无效

输入有效合格年龄

不合格年龄


软件测试

输入等价类

测试用例说明

测试数据

期望结果

选取理由

月份对应数值

月份为 1

月份为 12

月份 <1

月份 >12

196801

198512

196800

197413

最小月份最大月份恰小于最小月份恰大于最大月份

输入无效

输入有效


软件测试错误猜测法猜错就是猜测被测程序放在哪些地方容易出错，然后针对可能的薄弱环节来设计测试用例。一般先用等价分类法和边界值分析法设计测试用例，然后用猜错法补充一些例子作为辅助的手段。其它黑盒测试法因果图


软件测试白盒测试逻辑覆盖测试：用流程图来设计测计用例。主要考察的重点是图中的判定框 (选择或循环 )。按照被测试程序所作测试的有效程度，逻辑测试可由弱到强区分 5种覆盖标准：语句覆盖：每条语句至少执行一次。判定覆盖：每一判定的每个分支至少执行一次。


软件测试条件覆盖：每一判定中的每个条件，分别按“真”、“假”至少各执行一次。判定 /条件覆盖：同时满足判定覆盖和条件覆盖的要求。条件组合覆盖：求出判定中所有条件的各种可能组合值，每一可能的条件子和至少执行一次。


软件测试5种测试标准示例覆盖标准程序结构举例测试用例应满足的条件

语句覆盖 AB=.T.

判定覆盖 AB=.T.， AB=.F.

条件覆盖A=.T.， A=.F.

B=.T.， B=.F.

AB

T F

AB

T F

AB

T F


软件测试

覆盖标准程序结构举例测试用例应满足的条件

判定 /条件覆盖

AB=.T.， AB=.F.

A=.T.， A=.F.

B=.T.， B=.F.

条件组合覆盖

A=.T. B=.T.

A=.T. B=.F.

A=.F. B=.T.

A=.F. B=.F.

AB

T F

AB

T F

5种测试标准示例 (续 )


软件测试冒泡排序算法流程图


软件测试语句覆盖：只要送入先大后小的两个数，程序执行时就可以遍历流程图中的所有框。因此，仅需要选择一组测试数据如 {A={8,4}, K=2} 就能够实现语句覆盖。如果将两个“”均写成“ =”，用上述测试数据不能发现。判定覆盖：要实现判定覆盖，还需要在语句覆盖的基础上，增加两个能使程序从非正常出口 (AE 标志 )退出的测试数据。因此，用以下两组数据

{A={8,4,8},K=3} ， {A={8,4,4},K=3}

{A={8,4,8,4},K=4}


软件测试则程序将在满足 (A[I]=A[I-1]) 或 (A[J]=A[J-1])的条件下通过非正常出口，也能实现判定覆盖。

但又可能出现另一种偏向，掩盖把“”误写为“ =”的错误，造成更加严重的测试漏洞。


软件测试语句覆盖的执行路径

执行不到

执行不到

如果将写成 =,则测试数据 {8,4}

不能发现错误

如果将写成 =,则测试数据 {8,4} 不能发现错

误


软件测试判定覆盖的执行路径

如果将写成 =,则测试数据 {8,4,8} 不能发现错误

如果将写成 =,则测试数据 {8,4,4} 不能发现错误


软件测试条件覆盖：使复合条件占的每个条件分别按“真”、“假”出现一次，才能克服前述缺点。因此，可以选择如下测试数据

{A={8,4,9,6},K=4}

{A={8,4,8,4},K=4}

就能对程序实现条件覆盖。此时 A[I]( 或 A[J])大于、等于或小于 A[I-1]( 或 A[J-1])的 3种将分别至少出现一次，无论把“”误写为“ >” 或“ =”，都可用这两组数据检查出来。


软件测试因此，对于本例测试数据可以选择

{A={8,4,9,6},K=4}， {A={8,4,8,4},K=4}

或合成一组

{A={8,4,8,4,9,6},K=6}


软件测试判定覆盖与条件覆盖差别：•判定覆盖把判定看成一个整体，后者则着眼于其中的一个条件。•如果一个判定含有一个以上条件，采用判定覆盖可能出现如下漏洞，即判定中有些条件得到测试，另一些条件却被忽略，从而掩盖程序的错误。•条件覆盖要求对每一条件进行单独的检查，一般来说它的差错能力比判定覆盖强，但也不尽然。


软件测试

A真 A假B真 B假

{A假 ,B真 } {A真 ,B假 }

AB

T F AB

T F

A的逻辑值… …

B的逻辑值… …

可能的测试数据……

用以上数据测试的结果… …

只覆盖左分支只覆盖右分支

只覆盖一个分支的条件覆盖的实例


软件测试路径测试法程序图：是一种简化的流程图。

1 1

1

流程图

程序图


软件测试程序图的说明：•顺序执行的多个节点，在程序图中可以合并画成一个结点。•含有复合条件的判定框，在程序图中常常分解成几个简单的条件判定框，然后再画。


软件测试

AB

P Q

1

A>B

P P

1

A=B

Q

合并节点的程序图

分解为简单条件节点后的程序图


软件测试从流程图导出程序图

(AE)

(AE)


软件测试

1

2

3

4

5

6

7

89

1

2 9

3

4

7

8

5

6

(AE)

(AE)

a

b

c

d

e

f

g

h

i

j

k

l

m

q

n


软件测试路径测试：对程序图中每一条可能的程序执行路径至少测试一次。如果程序中含有循环 (在程序中表现为环 )，则每个循环至少执行一次。路径测试具有如下特征：•满足结构测试的最低要求。语句覆盖加判定覆盖是对白盒测试的最低要求，同时满足这两种标准的覆盖为“完全覆盖”。从对路径测试的要求可见，它本身就包含了语句覆盖和判定覆盖 (在程序图上分别为点覆盖与边覆盖 )。


软件测试

1

2

4

3

a b

c

e

d

测试路径覆盖节点 /边覆盖标准acd (1),(2),(3),(4) 点覆盖acd, be a, b, c, d 边覆盖acd, be

ae, bcd

(1),(2),(3),(4)/

a, b, c, d

路径覆盖


软件测试•有利于安排循环测试。单循环结构的测试包含：

(1)零次循环，即不执行循环体，直接从循环入口跳到出口；

(2)一次循环，循环体仅执行一次，主要检查在循环初始化中可能存在错误；

(3)典型次数的循环；

(4)最大值次循环，如果循环次数存在最大值，应按次最大值进行循环，需要时还可以增加比最大次数少一次或多一次的循环测试。


软件测试多重嵌套循环：可以对某一指定的循环层遍历单循环测试，而在其它各循环层取最小或典型次数进行循环测试。


软件测试选择测试路径的原则•选择具有功能含义的路径；•尽量用短路径代替长路径；•从上一条测试路径到下一条测试路径，应尽量减少变动的部分 ( 包括变动的边和节点 )；•由简入繁，如果可能，应先考虑不含循环的测试路径，然后补充对循环的测试；•除非不得已 (如为了要覆盖某条边 )，不要选取没有明显功能含义的复杂路径。


软件测试

1

2 9

3

4

7

8

5

6

(AE)

(AE)

a

b

c

d

e

f

g

h

k

j

l

m

n>

=

>

=

q1

2 9

3

4

7

8

5

6

(AE)

(AE)

a

b

c

d

e

f

g

h

k

j

l

m

n

>

=

>

=

q 1

2 9

3

4

7

8

5

6

(AE)

(AE)

a

b

c

d

e

f

g

h

k

j

l

m

n

>

=

>

=

q

ii i

(1) (2) (3)


软件测试

1

2 9

3

4

7

8

5

6

(AE)

(AE)

a

b

c

d

e

f

g

h

k

j

l

m

n

>

=

>

=

q

i

1

2 9

3

4

7

8

5

6

(AE)

(AE)

a

b

c

d

e

f

g

h

k

j

l

m

n

>

=

>

=

q

i

1

2 9

3

4

7

8

5

6

(AE)

(AE)

a

b

c

d

e

f

g

h

k

j

l

m

n

>

=

>

=

q

i

(4) (5) (6)


软件测试测试用例设计黑盒测试用例设计测试三角形分类程序，该程序的功能是：读入三角形边长的 3个整数，判断它们能否构成三角形。如果能够，则输出三角形是等边、等腰或任意三角形的分类信息。


软件测试

1

2

3

4

5

8

9

10

11712


软件测试软件的纠错纠错的策略

纠错策略

凑试法

跟踪法

推理法

正向跟踪

反向跟踪( 回溯法 )

归纳推理

演绎推理

适用于小程序

适用于大、小程序


软件测试凑试法：根据在测试中暴露的错误征兆，首先可设置一个可疑区，然后采用一些简单的纠错手段(例如在程序中插入打印语句 )，进一步获取与可疑区有关的信息，借以肯定或者修改原来的设想。跟踪法：让带错的程序“分步执行”，即每执行完一条语句，就暂时停止下来检查执行的结果，确认正常后再继续执行。

正向跟踪反向跟踪


软件测试推理法：分为归纳法和演绎法。归纳法：是从个别到整体的推理过程。它从收集个别故障症状开始，分析各种症状的相互关系后，就有可能将它们归纳为某一假想的错误，如果这一假想错误被证实，就找到了真实的病根。演绎法：是从一般到特殊的推理过程。根据测试获得的错误症状，可以先列出一批可能的病因，接着在这一大范围的设想中，逐一地排队根据不足或其它测试结果有明显矛盾的病因，然后对余下的一种或数种病因作详细的鉴别，确定真正的病因。


软件测试


软件测试常用的纠错技术插入打印语句设置断点掩盖部分程序蛮力纠错技术


软件测试多模块程序的测试策略测试的层次性：单元测试、综合测试、确认测试、系统测试。

模块单元测试

单元测试

单元测试

集成测试

确认测试

系统测试

模块

模块

测试报告

测试报告

软件设计信息

软件需求信息

测试报告测试报告

已组装软件

已确认软件

可运行的系统

系统的其它成分

编码阶段测试阶段验收阶段

…


软件测试程序错误的类型：从层次测试的角度，可以把程序错误划分为语法错误、结构性错误和接口错误。语法错误：刚结束编码的程序，常或多或少地含有语法错误，通过编译工具可以发现编译错误。结构性错误：包括结构异常、结构不全和结构多余等错误，它们是代码评审的主要检查内容，也可以利用专门设计工具的软件工具对代码静态分析发现。


软件测试


软件测试

错误名称举例说明数据引用错误例如使用未赋过值的变量，或变量赋值后从不使用等数据说明错误例如对变量未作说明，变量类型与初始化的值不等数据计算错误例如混合类型运算，用零作除数数据比较错误例如比较运算符和逻辑运算符使用不当，企图在不同

类型的变量间作比较等控制流错误例如多作或少作了一次循环，在循环体中对循环变量

重新定义，有死循环等多余结构例如不可达代码输入输出错误例如忘记打开或关闭文件， I/O 出错处理不正确等

部分常见结构性错误


软件测试功能性错误：指程序功能与用户需求不相符引起的错误，功能性错误主要依靠动态测试来发现。

功能性错误发生原因：•需求分析阶段定的需求说明比较含糊，导致疏忽或遗漏；•设计阶段对软件需求理解有错，或设计考虑不周；•开发过程中有过返工，需要多次修改需求说明或软件设计说明，出现设计走样、偏离用户需求错误。


软件测试接口错误：主要表现在调用子程序或函数时实际参数的类型、个数及顺序与形式参数不相一致；对全局量的引用不当；相关模块对全局性数据的相互矛盾等。接口错误是集成测试检测的重点，也可以通过代码评审来发现。系统错误：系统本身错误和对系统使用不当引起错误。


软件测试单元测试：是层次测试的第一步，也是整体测试的基础。

模块单元测试

单元测试

单元测试

集成测试

确认测试

系统测试

模块

模块

测试报告

测试报告

软件设计信息

软件需求信息


已组装软件

已确认软件

可运行的系统



…


软件测试单元测试的目的：通过对模块的静态分析与动态测试，使其代码达到模块说明的需求。单元测试的任务：•对模块代码进行编译，发现并纠正其语法错误；•进行静态分析，验证模块结构及其内部调用序列是否正确；•确定模块的测试策略，并据此设计出一组测试用例和必要的测试软件；


软件测试•用选定的测试用例对模块进行测试，直至满足测试终止标准为止。•静态分析与动态测试的重点，均应放在模块内部的重要执行路径、出错处理路径和局部数据结构，也要重视模块的对外接口。•编制测试报告。


软件测试单元测试的实施步骤：

编译静态分析器分析代码评审动态测试

检查代码中的语法错误

检查代码中的结构性错

误

重点发现功能性错误

发现程序在结构、功能与编码风格方面的问题和错误。

测试软件：在多模块程序中，每一模块都可能调用其它模块或者被其它模块所调用。所以在单元测试时，需要为被测试模块编制若干测试软件，给它的上级模块或下级模块作替身。代替上级模块的称为测试驱动模块，代替下级模块的称为测试桩模块。


软件测试集成测试：通过单元测试的模块要按照一定的策略组装为完整的程序，在该组装过程中进行的测试称为集成测试或组装测试。

模块单元测试

单元测试

单元测试

集成测试

确认测试

系统测试

模块

模块

测试报告

测试报告

软件设计信息

软件需求信息


已组装软件

已确认软件

可运行的系统



…


软件测试集成测试的原因：•单元测试中使用了测试软件，它们是真实模块的简化，与它们所代替的模块并不完全等效，因此，单元测试本身可能有不充分的地方，存在缺陷。•多模块程序各模块之间，可能有比较复杂的接口，稍有疏忽就易出错。例如，有些数据在穿过接口时会不慎丢失，有些全局性数据在引用中可能出问题等。•有些在单个模块中可以允许的误差，组装后的积累可能达到不能容忍的地步，或者模块的分功能似乎正常，组装后也可能产生不了预期的综合功能。


软件测试集成测试的目的：将经过单元测试的模块逐步组装成具有良好一致性的完整程序。集成测试的任务：•制定集成测试实施策略。根据程序的结构，可以选择自顶向下或由低向上或者二者综合的两头逼近策略。


软件测试•确定集成测试的实施步骤，设计测试用例。二者的选择，应有利于揭露在接口关系、访问全局性数据( 公用文件与数据结构 )、模块调用序列和出错处理等方面存在的隐患。•进行测试，即在已通过单元测试的基础上，逐一地添加模块。每并入一个模块，除进行新的测试项目外，还须重复进行先前已经进行过的测试，后者也称为回归测试。


软件测试集成测试的策略：•自顶向下测试：从顶模块开始，沿被测程序的结构图逐渐向下测试。按照移动路线的差异，又可区分为两种不同的实施策略：

M1

M2 M3 M4

M5 M6 M7

M8

多模块程序

先广度后深度实施步骤。

组装顺序：M1-M2-M3-M4-M

5-M6-M7-M8

先深度后广度实施步骤。

组装顺序：M1-M2-M5-M6-M

8-M3-M4-M7


软件测试

M1

M2 S3 S4

M5 S6

S8

测试M1

M1

S2 S3 S4

M1

M2 S3 S4

S5 S6

先深度后广度的测试时所需的桩模块

测试M1-M2-M5

测试M1-M2

M1

M2 S3 S4

M5 M6

S8

测试M1-M2-M5-M6


软件测试

M1

M2 S3 S4

M5 M6

M8

M1

M2 M3 S4

M5 M6

M8

M1

M2 M3 M4

M5 M6

M8

测试M1-M2-M5-M6-M8

测试M1-M2-M5-M6-M8-M3

测试M1-M2-M5-M6-M8-M3-M4


软件测试•自低向上测试：(1)从下一层模块中找出一个没有下级模块的模块，由下向上地逐加新模块，组成程序中的一个子系统或模块群；

(2)从另一个子系统或群中选出另一个无下级模块的模块，仿照前一步组成又一个子系统；

(3)重复上一步，直至得出所有的子系统，把它们组装为完整的程序。


软件测试

M1

M2 M3 M4

M5 M6 M7

M8

多模块程序

组装顺序：

M8-M5-M6-M2

M7-M4-M3-M1

全部模块 (合并以上两个群 )


软件测试•混合测试方式：

(1)对上层模块采取自顶向下测试；

(2)对关键模块或子系统采取由底向上测试。


软件测试确认测试：其目的在于确认组装完毕的程序是否满足软件需求规格说明书的要求。确认测试通常包括有效性测试和配置复审等内容。

模块单元测试

单元测试

单元测试

集成测试

确认测试

系统测试

模块

模块

测试报告

测试报告

软件设计信息

软件需求信息


已组装软件

已确认软件

可运行的系统



…


软件测试验收测试：如果软件是给一个客户开发的，需要进行一系列验收测试来保证满足客户所有的需求。验收测试主要由用户而不是开发者来进行的。Alpha测试与 Beta测试：如果一个软件是给很多客户使用的，可使用 Alpha测试与 Beta测试。•Alpha测试：是在一个受控的环境下，由用户在开发者的指导下进行测试，由开发者负责记录错误和使用中出现的问题。•Beta测试：由最终用户在自己的场所进行，开发发者通常不在场，也不能控制应用的环境。由用户记录错误和使用中出现的问题，并定期地交给开发者来解决。


软件测试系统测试：其目的是检查把确认测试合格的软件安装到系统中以后，能否与系统的其余部分协调运行，并且完成 SRS对它的要求。系统测试由用户单位实施。

模块单元测试

单元测试

单元测试

集成测试

确认测试

系统测试

模块

模块

测试报告

测试报告

软件设计信息

软件需求信息


已组装软件

已确认软件

可运行的系统



…


软件测试终止测试的标准规定测试策略和应达到目标：白盒测试时一般可规定以完全覆盖为标准，语句覆盖和判定覆盖的覆盖率达 100%。黑盒测试时，可结合程序的实际情况选择一或数种方法来设计测试用例，当把所有测试用例全部用完后测试便可结束。规定至少要检查出的错误数量：如果已经积累了丰富的测试经验，可以把查出的预定数量的错误作为某类应用程序的测试终止标准。


软件测试面向对象系统的测试面向对象测试与传统测试不同面向对象软件中的类 /对象在 OOA阶段就开始定义。面向对象软件是基于类 /对象，而传统测试则基于模块。


软件测试面向对象软件的测试策略面向对象软件的单元测试：最小的可测试单元是封装起来的类和对象。不能孤立地测试单个操作，而应该把操作作为类的一部分来测试。面向对象软件的集成测试•基于线程的测试：用于集成系统中指对一个输入或一个事件作出回应的一组类，多少个线程就对应多个类组，每个线程被集成并分别测试。•基于使用的测试：从相对独立的类开始构造系统，然后集成并测试调用该独立类的类，一直持续到构造完整的系统。


软件测试面向对象软件的确认测试与系统测试：忽略类连接细节，主要采用传统的黑盒法对面向对象分析阶段的用例所描述的用户交互进行测试。同时面向对象分析阶段的对象 -行为模型、事件流图等都可以导出 OO系统测试的测试用例。


软件测试面向对象软件测试用例设计测试类设计

类： Account（帐号）操作： Open(打开 )、 setup( 建立 )、 deposit(存款 )、 withdraw( 取款 )、 balance(计算余额 )、 summarize( 清单 )、 creditLimit(透支限额 )、 close( 关闭 )

1 随机测试


软件测试一个 account类实例的最小行为历史包括操作：

open setup. deposit. withdraw. close

下面序列中可能发生许多其他行为：

open setup. deposit. [withdraw|banlance|summarize|creditLimit]n. withdraw. close

测试用例 1： open setup. deposit. balance 。 summarize. withdraw. close

测试用例 2： open setup. deposit. withdraw. Deposit. balance. creditLimit. withdraw. close


软件测试2 划分测试•基于状态的划分：根据类操作改变类状态的能力来划分类操作。

类： Account（帐号）操作： Open(打开 )、 setup( 建立 )、 deposit(存款 )、 withdraw( 取款 )、 balance(计算余额 )、 summarize( 清单 )、 creditLimit(透支限额 )、 close( 关闭 )

状态操作


软件测试测试用例 1： open setup. deposit. deposit. withdraw. withdraw. close

（改变状态测试用例）

测试用例 2： open setup. deposit. summarize. creditLimit. withdraw. close

（不改变状态测试用例，在最小测试序列中的操作除外）


软件测试•基于属性的划分：根据类操作使用的属性来划分类操作。

例如，对于 account类来说，可以使用属性 balance 来定义划分：

1)使用 balance的操作；

2) 修改 balance的操作；

3) 不使用也不修改 balance的操作


软件测试•基于功能的划分：根据操作所完成的功能来划分操作。

例如，可以把 account类中的操作分为：

1)初始化操作： open， setup

2)计算操作： deposit、 withdraw

3)查询操作： balance、 summarize

4) 终止操作： close


主要内容

5555

6666

33 33

77778888

2222

4444

9999








软件维护软件维护的种类软件维护：满足用户对已开发产品的性能与运行环境不断提高的需要，进而达到延长软件的寿命。软件维护的类型：完善性维护：完善和加强产品的功能与性能，以满足用户日益增长的需要。适用性维护：适应运行环境的改变而进行的维护。

硬件或支撑软件改变引起的变化；将软件移植到新机种上；软件使用对象的较小变更。


软件维护纠错性维护：由于软件测试的不彻底性，任何大型软件交付使用后，都会继续发现潜在的错误，对它们进行诊断和改正，就称为纠错性维护。其他维护 (预防性维护 )：维护人员不要单纯等待用户提出维护的请求，应该选择那些还能使用数年、目前虽然能运行但不久就需做重大修护或加强的软件，进行预先维护。其目的是改善软件的可维护性，减少今后对它们维护时所需要的工作量。


软件维护

1完善性维护2适应性维护3纠错性维护

4 其它维护

1

50%

2

25%

3

21%4

4%

各种维护所占比重


软件维护软件可维护可修护性：可修护性是衡量软件维护容易程度的一种软件属性。影响可以维护性的软件属性可理解性 (Understandability)

可修改性 (Modifiability)

可测试性 (Testability)


软件维护对可维护性的定量计算

(1)问题识别时间

(2)管理延迟时间

(3)收集维护工具时间

(4)问题分析时间

(5) 修改规格说明时间


软件维护对可维护性的定量计算 (续 )

(6) 改正 ( 或修改 )时间；

(7)局部测试时间；

(8) 整体测试时间；

(9)维护复审时间；

(10)分发与恢复时间


软件维护提高可维护性的途径提供完整和一致的文档•帮助维护人员读懂程序•方便被维护软件测试采用现代化的开发方法•在分析阶段，应确定开发时期采用的各种标准和指导原则。提出关于软件质量保证要求。•在设计时期，应坚持设计的模块化和结构化原则，把模块的清晰性、独立性和易修改性发在第一位。


软件维护

区分类型

严重性评

价

优先度评

价

错误分析

软件维护的实施软件维护的工作流程

维护过程

问题分析

复审配置

维护申请

纠错

适应

完善

纠错项目表

严重

不严重

维护人员名单

开发项目表低

高

维护人员名单

已修改的配置

修改报告单

已修改的软件

批准交付用户的配置


软件维护维护申请单：由申请维护的用户填写。纠错性维护的申请单应完整地说明导致错误发生的环境，包括输入数据、输出数据清单和其它有关材料。如果申请适应性或完善性维护，则仅需提出一个简要的需求说明。修改报告单：用户记录在维护时期对软件所作的每一次修改。其内容包括问题来源、错误类型、修改内容、资源耗用以及批准修改的负责人等。


软件维护维护的副作用修改编码的副作用修改数据的副作用修改文档的副作用


软件维护软件维护的管理维护的机构与人员：软件开发单位根据本身规模的大小，可以指定一名高级管理人员担任维护管理员，或建立由高级管理人员和专业管理人员组成的修改控制组，管理本单位的软件维护工作。维护时期的配置管理：软件配置是一个软件在生存周期内，它的各种形式、各种版本的文档与程序的总称。为了方便对多种产品和多种版本进行跟踪和控制，常常借助于自动的配置管理工具。


软件维护维护管理文档维护申请单软件修改报告单维护日志：评价维护工作有效性的主要依据。其主要包括三方面内容： (1)维护前程序情况； (2)维护中对程序修改的情况； (3) 其它重要数据。维护申请摘要报告：定期报告，每周或每月统计一次。其内容包括上次报告以来已经处理了的、正在处理的和新接到的维护申请项数以及处理情况。维护趋势图：在维护申请摘要图的基础上绘制而成不定期报告。


软件维护软件再工程软件再工程：将新技术和新工具应用于老的软件的一种较“彻底”的预防性维护。软件再工程与软件维护差异：软件维护是局部的，以完成纠错或适应需求变化为目的；软件再工程是运用逆向工程、重构等技术，在充分理解原有软件的基础上，进行分解、综合、并重新构建软件，用以提高软件的可理解性、可维护性或演化性。


软件维护软件再工程过程模型

信息库分析

文档重构

逆向工程代码重构

数据重构

正向工程


软件维护逆向工程

重构代码

提取抽象

求精和简化

脏的源代码

干净的源代码

初始设计说明

最终设计说明

处理

界面

数据库


主要内容

5555

6666

33 33

77778888

2222

4444

9999








软件项目计划

需求分析软件设计编码

维护

测试

问题定义

可行性研究计划时期

开发时期

维护时期


软件项目计划问题定义问题定义阶段的目的是弄清楚用户需要计算机解决的问题根本所在，以及项目所需的资源和经费。问题定义阶段的任务是在向用户调查的基础上，编写一个叫做“系统目标与范围的说明”的文档。

系统目标和范围说明书

1. 项目：教材销售系统

2.问题：人工发售教材手续繁琐，且易出错。

3. 项目目标：建立一个高效、无差错的微机教材销售系统。

4. 项目范围：利用现有微型计算机，软件开发费用不超过 5000 元。

5.初步设想：建议在系统中增加对缺书的统计与采购功能。

6.可行性研究：建议进行大约 1天的可行性研究，研究费用不超过 1000元。


软件项目计划可行性研究：弄清楚所定义的项目是不是可能实现和值得进行。研究的内容经济可行性：实现这个系统有没有经济效益？多长时间可以收回成本？技术可行性：现有的技术能否实现这一新系统，有哪些技术难点？建议采用的技术先进程度怎样？运行可行性：为新系统规定的运行方式是否可行？法律可行性：新系统的开发，会不会在社会上或政治上引起侵权、破坏或其它责任问题。


软件项目计划研究的步骤细化和修改“系统目标与范围的说明”，得出新系统的逻辑模型。导出新系统的解决方案。根据新系统的逻辑模型，设想出几种可能的解决方案，以便于用户选择。提出推荐方案。在上一步提出的各种方案分析比较的基础上，提出向用户推荐的方案。


软件项目计划系统流程图：描述系统物理模型的一种工具。

加工输入 /输出

汇合

控制流垮页汇合

系统流程图基本符号


软件项目计划

学生

购书单

审查有效性

学生用书表

售书登记表

开发票教材存量表

打印发票

打印领书单并登记售书

发票

收费盖章

领书单

发书

缺书登记

汇总并统计缺书

缺书单书库保管员

进书

产生补售书单

售书购书

教材购销系统流程图


软件项目计划可行性报告系统概述：包括对当前系统及其存在的问题的简单描述，新的目标系统和它的各个子系统的功能与性能，新系统与当前系统的比较等。可行性分析：这是报告的主体。包括新系统在经济上、技术上和法律行的可行性，以及对建立新系统的主客观条件的分析。结论意见：综合上述分析，说明新系统是否可行。


软件项目计划软件风险分析风险识别：项目风险、技术风险和商业风险。项目风险：在预算、进度、人力、资源、客户需求等方面潜在的问题，它们可以造成软件项目成本高、时间延长等损失。技术风险：指设计、实现、接口和维护等方面的问题，以及由此造成的降低软件开发质量、延长交付时间等后果。商业风险：包括市场、商业策略、推销策略等方面的风险，这些风险会直接影响软件的生存能力。


软件项目计划风险分类产品规模风险：检查与软件总体规模相关的风险。商业影响风险：检查与管理或市场的约束相关的风险。与客户相关风险：检查与客户素质及通信能力相关的风险。过程风险：检查与软件过程被定义和开发相关的风险。技术风险：检查与软件复杂性及系统所包含技术成熟度相关风险。开发环境风险：检查开发工具的可用性及质量相关风险。人员结构和经验风险：检查参与工作的人员的总体技术水平及项目经验相关的风险。


软件项目计划风险检查表商业影响风险建立软件是不是符合市场的需求 (市场风险 )?

建立的软件是不是符合公司的整体商业策略 (市场风险 )？销售部门是否知道如何推销这种软件 (销售风险 )?

有没有因为课题内容或人员的改变，使该项目失去管理层支持 (管理风险 )？项目预算或参加人员有没有保证 (预算风险 )?


软件项目计划风险预测：包括两方面内容：风险发生的可能性和风险发生所产生的后果。由项目计划人员、管理人员和技术人员一起执行两项风险预测活动：建立风险可能性尺度：罕见、普通、可能性或极可能等。估计对产品和项目的影响：风险的驾驭和监控


软件项目计划项目实施计划项目实施计划：软件目标、功能、进度、资源和费用等。质量保证计划：软件开发各个阶段的质量要求和质量保证活动。软件测试计划：规定各种测试活动的任务、方法、进度、资源和人员等。文档编写计划：规定项目开发各个阶段编制的文档种类、标准和内容等。用户培训计划：对用户培训的目标、要求和进度等。综合支持计划：描述软件开发中所需的各个方面的支持，以及如何获得和利用这些支持。软件分发计划：软件产品如何提交到最终用户上。


软件工程管理管理的目的与内容管理的目的：是为了按照预定的时间和费用，成功地完成软件的计划、开发和维护任务。管理的内容：费用管理质量管理人员管理进度管理


软件工程管理软件估算模型资源估算模型：估算软件在开发中花费的资源，如开发时间、开发人数以及工作量等。静态单变量资源模型

资源 =c1( 估计的软件特征 )c2

•资源可以是开发工作量 (E)、开发时间 (T) 或开发人数 (P)等；•估计特征可以是原程序长度 (L)、或软件开发工作量 (E)等；•c1和 c2为依赖于开发环境和软件应用领域的两个经验常数。


软件工程管理多变量资源模型 (Putnam资源模型 )

L=cK1/3T4/3 或

K=L3/(c3T4)

•L(行 )与 T( 年 )分别表示源程序长度和开发时间；•K表示全生存周期所需要的工作量 (人 - 年 )。•c是一个与开发环境有关的常数。


软件工程管理COCOMO模型 (COnstructive COst MOdel)

类别模型方程使用说明组织型 E=3.2L1.05

T=2.5E0.38

高级语言应用，如科学计算、数据处理、企业管理程序等

半独立型 E=3.0L1.12

T=2.5E0.35

大多数实用程序，如编辑程序、连接程序、编辑程序等

嵌入型 E=2.8L1.20

T=2.5E0.32

与硬件关系密切的系统程序，如操作系统、数据库管理系统、实时处理与控制程序等

不同类型软件的 COCOMO模型


软件工程管理

属性模型方程调节范围产品属性

要求的可靠性等级数据库规模产品复杂度

0.75-1.40

0.94-1.16

0.70-1.65

计算机属性

对程序执行时间的约束对程序占用存储量的约束开发环境的变动开发环境的响应时间

1.00-1.66

1.00-1.56

0.87-1.30

0.87-1.15

调节因子和它的值范围


软件工程管理

属性模型方程调节范围人员属性

分析员水平程序员水平对应用领域的熟悉程度对开发环境的熟悉程度对所用语言的熟悉程度

1.46-0.71

1.42-0.70

1.29-0.82

1.21-0.90

1.14-0.95

项目属性

开发方法的现代化软件工具的数质量完成时间的限制

1.24-0.82

1.24-0.83

1.23-1.10

调节因子和它的值范围


软件工程管理

软件成本估计


软件工程管理人员的分配与组织人员分配的指导原则：Rayleigh-Norden曲线人员 -时间权衡定律Brooks定律人员组织民主开发小组主程序开发小组


软件工程管理项目进度安排计划评审技术 (PERT)

建立 PERT图

起点

分析3

设计4

编码4

产品测试

4测试计划

2

测试软件

6

测试数据

2

终点

文档2

某软件开发项目的 PERT图


软件工程管理

起点

分析3

设计4

编码4

产品测试

4测试计划

2

测试软件

6

测试数据

2

终点

文档2

找出关键路径

某软件开发项目的关键路径

(0,0)

(0,3)

(3,7) (7,9)

(7,11)

(13,15)

(15,15)

(3,9)

(0,2) (2,8)


软件工程管理

起点

分析3

设计4

编码4

产品测试

4测试计划

2

测试软件

6

测试数据

2

终点

文档2

标出最迟开始时间

标有最迟时间的 PERT图

(0,0)

(0,3)

(3,7)(7,9)

(7,11)

(13,15)

(15,15)

(3,9)

(0,2) (2,8)(0,0)

(0,3)

(3,7)

(7,11)

(11,15)(5,11)(3,5)

(9,11)(15,15

)

(13,15)


软件工程管理

起点

分析3

设计3

编码2

产品测试

4测试计划

2

测试软件

6

测试数据

2

终点

文档2

原关键路径缩短后，出现两条关键路径

(0,0)

(0,3)

(3,6)(7,9)

(6,8)

(8,12)

(12,12)

(3,9)

(0,2) (2,8)

(3,7)

PERT图使用


软件工程管理Gantt图


主要内容

5555

6666

33 33

77778888

2222

4444

9999








软件质量管理从质量保证到质量认证质量保证：着眼于每一个软件，保证提供给用户的产品都达到规定的质量水平。质量认证：注重软件企业的整体资质，目的在于全面考察企业的质量体系，判断它是否具备设计、开发和生产符合质量要求的软件产品的能力。质量管理经历 3个阶段质量检验 (Quality Inspection)阶段全面质量管理 (Total Quality Control, TQC)阶段质量认证 (Quality Certification)阶段


软件质量管理从质量保证到质量认证质量保证与质量认证：质量保证着眼于每一个软件，保证提供给用户的产品都达到规定的质量水平；质量认证注重软件企业的整体资质，目的在于全面考察企业的质量体系，判断它是否具备设计、开发和生产符合质量要求的软件产品的能力。质量管理经历 3个阶段质量检验 (Quality Inspection)阶段全面质量管理 (Total Quality Control, TQC)阶段质量认证 (Quality Certification)阶段


软件质量管理质量保证质量保证：是指在软件开发过程中，为了保证产品满足指定标准而进行的各种活动。软件的质量属性运行性能：可靠性、效率、正确性、使用性、完整性。维护性能：可维护性、可测试性、可适应性。移植性能：可移植性、可重用性、交互操作性。


软件质量管理质量保证的活动内容质量保证：是指在软件开发过程中，为了保证产品满足指定标准而进行的各种活动。

软件测试控制：软件配置

方法：设计、编码、…复审：计划与开发

质量保证活动内容


软件质量管理软件可靠性可靠性：在给定时间内，程序按照规定的条件成功地运行的概率。 R(t)=P{在时间 [0,t]内按规定条件运行成功 }计算方法 1： R(t)=e-λt，其中， t为程序运行时间， λ为故障率，即单位时间内程序运行失败的次数。

λ3

λ2

λ1

λ1<λ2 <λ3

t

R（ t）

可靠性随 t、 λ的变化


软件质量管理计算方法 2：平均故障时间MTTF=1/λ，其中， λ为故障率，即单位时间内程序运行失败的次数。系统的可靠性：是软件、硬件和操作人员的操作三种可靠性的综合反映。 RSYS=RSRH ROP

ttttSYS

OPHSOPHS eeeeR )( 系统的可靠性 (方法 2)

OPHS

SYS

MTTFMTTFMTTF

MTTF111

1

系统的可靠性 (方法 1)


软件质量管理可靠性等级

分级故障的后果开发工作量比例因子甚低工作略有不便 0.75

低有损失，但容易弥补 0.88

正常弥补损失比较困难 1.00

高重大的经济损失 1.15

甚高危机人的生命 1.40


软件质量管理可靠性模型

正比于遗留故障的宏观模型

：程序的调试时间；

ET：调试的错误总数；

EC()：在时间 0- 期间纠正的错误数；

Er()：在时间时的遗留错误数量， Er()= ET- EC

() ；

IT：程序的长度或指令总数。


软件质量管理

)()( C

T

Tr I

EKK

软件故障率与遗留错误的数量成正比

)(

)( C

T

TI

EKt eetR

T

CC

T

rr

CT

Tr

IE

IE

IE

)()(,)()(

)()(

其中，

错误规格化值：

软件可靠性


软件质量管理平均故障时间模型

)(

11

CT

TI

EKMTTF

平均故障时间

T

T

T

TE

II

EK

MTTF

0,

11

设在时间 0至期间的纠错率为常数，等

于 0


软件质量管理软件容错技术容错：当软件在运行中出现错误，将它的影响限制到可容许的范围之内。容错软件：具有抗故障功能的软件。屏蔽错误：把软件的错误屏蔽掉，使之不致于为害；修复错误：在一定程度上使软件从错误状态恢复到正常状态。减少错误：能在一定程度上使软件完成预定义功能。


软件质量管理冗余技术结构冗余

M1

M2

M3

VIU=(u1u2)(u2u3)(u3u

1)

u1

u2

u3

静态冗余


软件质量管理

M1

M2

M3

I

主模块

动态冗余

U备用

备用

时间冗余：设置一个错误检测程序，当它检测到程序运行出错时，能够发出一个错误恢复信号，使程序返回重新执行。信息冗余：用于检测和纠正信息在传输或运算中发生的错误。常用的方法有奇偶校验、循环校验等误差校正。


软件质量管理容错软件设计

建立需求说明，设计软件的非容错结构

分析错误类型，确定容错范围

确定采用的冗余技术，修改结构

评估容错效果

完成


软件质量管理CMM软件能力成熟度模型软件过程：一个软件企业在计划、开发和维护一个软件时所执行的一系列活动。软件过程能力：软件企业遵循其软件过程能够实现的预期结果 .

软件过程性能：软件企业遵循其软件过程能够得到的实际结果 .

软件过程成熟度：软件过程被明确和有效地定义、管理、测量和控制的程度。


软件质量管理

软件生存周期过程

基本过程

支持过程

组织过程

获取过程

供应过程

开发过程

运行过程

维护过程

文档编制过程

配置管理过程质量保证过程验证过程确认过程联合评审过程审核过程问题解决过程

管理过程

基础设施过程

改进过程

培训过程


软件质量管理过程域：相互关联的若干软件实践活动和有关基础设施的一个集合。关键过程域：为了确保不同等级的软件过程能力成熟度分别达到各自的目标，需要注意对于实现该等级的目标起关键性作用的过程域，即关键过程域。


软件质量管理关键实践：对实施关键过程域起关键作用的措施、活动、规程以及相关基础设施，称为关键实践。CMM模型：用来确定一个软件过程的成熟度以及指明如何提高过程成熟度的参考模型。 CMM模型把成熟度等级分成 5级，共包括 18个关键过程域， 52个过程目标， 316种关键实践，从而为软件企业的过程能力提供了一个阶梯式的进化框架。


软件质量管理

等级 1：初始级

等级 2：可重复级

等级 3：定义级

等级 4：管理级

等级 5：优化级

软件能力成熟度等级

过程制度

过程定义

过程控制

持续过程改进

项目管理

工程化管理

量化管理

变更管理


软件质量管理初始级：对软件过程缺乏明确的定义，质量管理处于消防式的、要等出了问题再处理的状态。可重复级：解决质量管理体系从无到有的问题，重点是建立一套基本制度，使软件项目的基本管理可以重复实施。已定义级：质量管理从特殊到一般，并进一步实现标准化和文档化的过程。


软件质量管理已定量管理级：质量管理从定性管理提升到定量管理的过程，并通过定量控制，使质量管理的结果达到可以预测。优化级：从静态管理到动态管理的过程，通过开发技术和过程的不断更新，使质量管理体系持续改进和提高。


软件质量管理CMM的应用：能力评估和过程改善。CMM 评估的实施遵循卡内 -梅隆基大学软件工程研究院 (CMU/SEI)的 CFA(CMM Assessment Frame-work)规范，由 CMU/SEI授权的主任评估师领导一个评审小组进行。


软件质量管理评估方法有两种：•CBA-SCE:主要用于 CMM对机构的软件能力进行评估，由机构外部的评估小组对该机构的软件能力实施评估。•CBA-IPI：主要用于 CMM对内部过程改进实施评估，由机构内部和外部人员联合组成评估小组，针对软件机构本身进行评估。


软件质量管理软件过程评估的 SPICE 国际标准国际化标准组织 ISO于 1995 年制定了软件过程评估试用标准1996 年 ISO 公布了软件过程评估 (Software Process Assessment, SPA) 标准 1.0版1998 年 ISO发表了 ISO/IEC TR 15504 SPICE


软件质量管理软件度量项目度量：度量规模、工作量、时间、质量、成本。面向代码行的项目度量面向功能的项目度量过程度量：对整个企业中全体项目组开发能力的衡量。

软件工程2010

Education