第3章 需求工程与需求分析.ppt

1、1,第3章 需求工程与需求分析,2,3.1 基本的软件需求,3,基本的软件需求,软件项目中百分之四十至百分之六十的问题都是在需求分析阶段埋下的“祸根” 。可许多组织仍在那些基本的项目功能上采用一些不合规范的方法，这样导致的后果便是一条鸿沟（期望差异）开发者开发的与用户所想得到的软件存在着巨大期望差异。,4,基本的软件需求,在软件工程中，所有的风险承担者(stakeholder)都感兴趣的就是需求分析阶段。这些风险承担者包括客户、用户、业务或需求分析员(负责收集客户需求并编写文档，以及负责客户与开发机构之间联系沟通的人)、开发人员、测试人员、用户文档编写者、项目管理者和客户管理者。这部分工作若处

2、理好了，能开发出很出色的产品，同时会使客户感到满意，开发者也倍感满足、充实。若处理不好，则会导致误解、挫折、障碍以及潜在质量和业务价值上的威胁。因为需求分析奠定了软件工程和项目管理的基础。,5,3.1.1 软件需求的定义, 用户解决问题或达到目标所需的条件或权能（Capability）。 系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。 一种反映上面或所描述的条件或权能的文档说明。,6,3.1.1 软件需求的定义,1. 一些关于“需求”的解释 需求的关键的问题是一定要编写需求文档。 如果只有一堆邮件、贴条、会谈过几次或一些零碎的对话，你就确信你已明白用户的需求，那完

3、全是自欺欺人。 许多的需求分析专家给出了不同形式的需求定义，但从这些不同形式的定义不难发现：并没有一个清晰、毫无二义性的“需求”术语存在，真正的“需求”实际上在人们的脑海中。任何文档形式的需求（例如：需求规格说明）仅是一个模型，一种叙述（Lawrence 1998）。我们需要确保所有项目风险承担者在描述需求的那些名词的理解上务必达成共识。,7,3.1.1 软件需求的定义,2需求的层次 下面这些定义是需求工程领域中常见术语的定义说明。 软件需求包括三个不同的层次业务需求、用户需求和功能需求（包括非功能需求）。 业务需求（business requirement）反映了组织机构或客户对系统、产品高

4、层次的目标要求，它们在项目视图与范围文档中予以说明。 用户需求（user requirement）文档描述了用户使用产品必须要完成的任务，这在使用实例（use case）文档或方案脚本（scenario）说明中予以说明。 功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。所谓特性（feature）是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。,8,3.1.1 软件需求的定义,9,3.1.2 需求的开发和管理,需求中名词术语的混淆将导致对科目（规范，discipline）叫法的不一致。一些作

5、者把整个需求范围称之为“需求工程”，另一些则称之为“需求管理”。 软件专家认为可把整个软件需求工程研究领域划分为需求开发和需求管理两部分更合适：,10,3.1.2 需求的开发和管理,需求开发可进一步分为：需求获取(elicitation)、分析(analysis)、编写规格说明(specification)和验证(verification)四个阶段。 需求开发活动包括以下几个方面： 确定产品所期望的用户类。 获取每个用户类的需求。 了解实际用户任务和目标以及这些任务所支持的业务需求。 分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息。,11,3.1.2

6、 需求的开发和管理, 将系统级的需求分为几个子系统，并将需求中的一部份分配给软件组件。 了解相关质量属性的重要性。 商讨实施优先级的划分。 将所收集的用户需求编写成规格说明和模型。 评审需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组接受说明之前将问题都弄清楚。,12,3.1.2 需求的开发和管理,需求管理需要“建立并维护在软件工程中同客户达成的契约”(CMU/SEI 1995)。这种契约都包含在编写的需求规格说明与模型中。 通常的需求管理活动包括： 定义需求基线（迅速制定需求文档的主体）。 评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它。 以一种可控制的方式将

7、需求变更融入到项目中。 使当前的项目计划与需求一致。 估计变更需求所产生影响并在此基础上协商新的承诺(约定)。 让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪。 在整个项目过程中跟踪需求状态及其变更情况。,13,3.1.2 需求的开发和管理,需求开发和需求管理之间的区别,14,3.1.3 需求工程的作用,1支持项目的开发。 需求工程过程是软件开发阶段的前提和基础。 2支持测试和验证 需求规格说明书将为项目测试和验证提供基准，可以用来检查设计和验证系统。 3支持维护 维护阶段的工作同以下几个方面紧密联系： 修改在测试阶段中尚未检查出来的少量残留编码错误。 软件运行一段时间后，因

8、环境因素的改变而产生的软件的适应性维护。 用户在软件交付使用后又重新提出扩充功能的需求时的软件维护。 4支持项目承包商 需求的证实过程为拟构造系统的正确性提供了进一步的根据。 5支持管理 为了保证项目的顺利进行，项目管理者必须有一个完备的项目计划，包括开销、交付日期、可用资源、交付条件等等。,15,3.2 需求获取,16,3.2.1 需求获取过程,需求获取时期的主要工作： 归纳和整理用户提出的各种问题和要求； 弄清用户企图通过软件达到的目的； 借助各种工具和方法，陈述用户提出的实际需求，并标定软件的作用范围。,17,3.2.2 需求获取方法,需求获取方法包括两个方面： 指导开发小组获取用户需求

9、的方法框架。 支持控制此项活动进展的过程控制机制。,18,3.2.3 当前状况, 误解：由于分析员并非该应用领域的专家，使得在需求获取时，误解了用户潜在的隐含假设。 交流障碍：领域专家同一个新手交谈时的用词往往并不足以解决问题。 缺乏共同语言：由于需求分析员和系统用户的经历和教育背景不同，他们之间通常缺乏足够的沟通。 “完整性”问题：软件工程师希望提出系统需求的用户领域专家能清晰、简明和完备地描述出确实可行的系统需求，然而，所要的需求知识在其最初阶段可能是模糊、不完备甚至是不正确的。 需求永远不会稳定：用户对软件的需求常常会发生变化，并且是不可预测的。 用户意见不统一：大系统往往有各种不同的用

10、户，他们往往有互相冲突的需求和不同的需求优先次序，寻求折衷是不容易的。 错误的要求：系统的定购者（付钱的人）和系统的使用者经常不是一个人，定购者由于受到组织或经费的限制，提出的需求会与最终用户的需求相冲突。 认识混淆：有时系统的目标和系统的需求会发生混淆。目标是系统应达到的更为一般的特征，而需求应是可测试的。,19,解决问题的建议,1. 了解系统需求 2. 市场调查 3. 访问用户和用户领域专家 4. 考察现场,20,调查的方式,1. 调查提纲或调查表 2. 小型调查会议 3. 个别访问 4. 现场调查 5. 资料 6. 调查工具,21,调查中应注意的事项,1. 不要用计算机专业术语与用户或用

11、户领域专家交谈 2. 不要使用“你应该”这样的字眼 3. 始终记住自己最近一段工作中要达到的目标，引导用户说出你需要的信息 4. 要善于把用户中职位高的人和职位低的人的谈话结合起来分析,22,3.3 需求分析任务,23,3.3 需求分析任务,需求分析所要做的工作是深入描述软件的 功能和性能，确定软件设计的限制和软件同 其它系统元素的接口细节，定义软件的其它 有效性需求。 分析员通过需求分析，逐步细化对软件的 要求，描述软件要处理的数据域，并给软件 开发提供一种可转化为数据设计、结构设计 和过程设计的数据和功能表示。在软件完成 后，制定的软件规格说明还要为评价软件质 量提供依据。,24,3.3

12、需求分析任务, 正确地确定对系统综合要求，充分理解和表达用户的需求。 也就是详细定义开发软件的功能、性能、外部接口、设计限制、数据库需求、确定硬件和软件支持环境、辅助软件以及将来可能提出的要求。 通过结构分析的方法对系统进行分解，以确定软件系统的主要成分或软件系统的构成。,25,3.3 需求分析任务, 是对以上已进行的两项工作进行描述，以形成需求文档，也就是编制“需求规格说明书”。它应明确地定义要开发软件的需求；系统的构成及有关接口。 需求规格说明书的作用在于： 提供一个用户和开发者对开发软件的共同的理解； 相当于用户和开发单位之间的一份技术合同； 是今后各阶段设计的基本依据； 是今后验收测试

13、阶段对软件进行确认和验收的基准。,26,3.3 需求分析任务, 编写用户手册概要，迫使分析员从用户的角度看待软件，及早考虑用户界面工作，此时编写的重点在系统输入和输出。 把整个软件系统分解为若干个子系统或软件成分(如软件包)，把整个软件的外部功能分配给软件系统的各功能成分，并详细地定义每个软件成分的外部功能以及它们间的接口。 编写验收计划，作为今后验收测试的依据。 修正可行性研究阶段所制订的软件项目开发计划。由于在需求分析过程中对将要开发的系统有了更深入的了解，所以可以更准确地估计开发成本、进度和资源需求。有必要对原计划作出适当修正。,27,3.4 需求分析过程,28,3.4.1 功能性需求,

14、功能性需求包括： 1功能需求 例举出开发软件在职能上应做什么，这是最主要的需求。 2性能需求 给出所开发软件的技术性能指标，包括存储容量限制、运行时间限制、安全保密性等。 3环境需求 软件系统运行时多所处的环境要求。 4可靠性需求 各种软件在运行时，失败的影响各不相同，在需求分析时，应对所开发的软件在投入运行后不发生故障的概率，按实际的运行环境提出的要求。,29,3.4.1 功能性需求,5安全保密要求 把软件运行的安全需求恰当地做出规定，以便对所开发的软件给予特殊的设计，使其在运行中其安全保密方面的性能得到必要的保证。 6用户界面需求 软件与用户界面的友好性是用户能够方便有效、愉快地使用该软件

15、的关键之一。 7资源使用需求 开发软件运行时所需的数据、软件、内存空间等各项资源。 8软件成本消耗与开发进度需求 软件项目立项后，要根据合同规定，对软件开发的进度和各项步骤的费用提出要求，作为开发管理的依据。 9预先估计系统可能达到的目标 在开发过程中可对系统将来可能的扩充与修改做准备。,30,【例1】假设需要制造一个带有四个按钮和两个灯泡的盒子并具有以下功能： 有四个按钮输入，分别称为B1，B2，B3和B4； 有两个灯泡作为输出，分别称为L1和L2； B1是打开电源的按钮； B4是关闭电源的按钮； B2和B3 是操作按钮； 在B1被按下后及B4被按下前，系统应称为电源打开状态； 在B4被按下

16、后及B1被按下前，系统应称为电源关闭状态； 在电源关闭状态下，B2和B3按钮不起作用； 在电源关闭状态下，灯应不亮； 从最近一次电源打开状态算起，如果B2被按下的次数比B3被按下的次数多，L1亮，否则L2亮。 任何时候都不能有一个以上的灯泡亮； 如果其中的一个灯泡出现故障，另一个灯泡应以2秒钟的间隔闪烁，而不管B2和B3的操作过程。当B4按下时，闪烁停止；当B1被按下时，闪烁重新开始。当故障被排除后闪烁停止，系统恢复正常状态。,31,疑问？,1. 对于在灯泡出现故障时是否要记录下B2和B3的操作过程 2. 系统记录或不记录B2和B3的操作，对于故障排除后系统的反应如何,32,3.4.2 非功能

17、性需求,非功能性需求即为软件的“约束”:,非功能性需求,过程需求,产品需求,外部需求,交付需求,实现方法需求,标准需求,可用性需求,效用需求,可靠性需求,可移植性需求,可重复需求,安全保密性需求,性能需求,应用需求,法规需求,费用需求,互操作需求,33,3.4.3 需求分析文档,1需求规格说明书的作用 为用户、分析人员和软件设计人员之间的理解和交流提供了方便； 支持目标软件系统的确认； 起到控制系统演进的作用。 2什么样人阅读需求规格说明书 必须阅读需求规格说明书的是各种背景和技术能力都不同的人：客户和使用者，分析人，设计师和工程师，项目管理者等。,34,3.4.3 需求分析文档,3需求规格说

18、明书编写分类 按方法分类：形式化方法和非形式化方法 非形式化的需求规格说明书是用自然语言写的，可以用图表和其 他符号帮助理解，也可以用标准化的格式来编制。 形式化的需求规格说明书是用完全精确的语法和语义来表达。 半形式化的需求规格说明书也很有用。它采用了一些符号，但对这些符号并没有给予精确的定义。 按文档内容的性质分类：操作性和说明性 操作性的需求规格说明书通过说明所要求的行为来描述要求哪种系统，通常提供一个系统模型作为模拟系统行为的抽象装置。 说明性的需求规格说明书用纯粹的说明方式来描述系统的特性。,35,3.4.3 需求分析文档,4需求规格说明书主要内容： 概述。从系统的角度描述软件的目标

19、和任务。 数据描述 数据流图 数据字典 系统接口说明 内部接口说明 功能描述 功能 处理 设计的限制,36,3.4.3 需求分析文档, 性能描述 性能指标 测试种类 预期的软件响应性能 其它 参考文献目录 附录,37,3.5 验证,38,3.5.1 需求说明的特征,1. 完整性 每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。 2. 正确性 每一项需求都必须准确地陈述其要开发的功能。做出正确判断的参考是需求的来源，如用户或高层的系统需求规格说明。若软件需求与对应的系统需求相抵触则是不正确的。只有用户代表才能确定用户需求的正确性，这就是一定要有用户

20、的积极参与的原因。没有用户参与的需求评审将导致此类说法：“那些毫无意义，这些才很可能是他们所要想的。”其实这完全是评审者凭空猜测。,39,3.5.1 需求说明的特征,3. 可行性 每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。为避免不可行的需求，最好在获取（elicitation）需求(收集需求)过程中始终有一位软件工程小组的组员与需求分析人员或考虑市场的人员在一起工作，由他负责检查技术可行性。 4. 必要性 每一项需求都应把客户真正所需要的和最终系统所需遵从的标准记录下来。“必要性”也可以理解为每项需求都是用来授权你编写文档的“根源”。要使每项需求都能回溯至某项客户的输入，

21、如使用实例或别的来源。,40,3.5.1 需求说明的特征,5. 可修改性 在必要时或为维护每一需求变更历史记录时，应该修订SRS。这就要求每项需求要独立标出，并与别的需求区别开来，从而无二义性。每项需求只应在SRS中出现一次。这样更改时易于保持一致性。另外，使用目录表、索引和相互参照列表方法将使软件需求规格说明更容易修改。 6. 可跟踪性 应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这种可跟踪性要求每项需求以一种结构化的，粒度好（fine-grained）的方式编写并单独标明，而不是大段大段的叙述。,41,3.5.1 需求说明的特征,7. 划分优先级 给每项需求、

22、特性或使用实例分配一个实施优先级以指明它在特定产品中所占的分量。如果把所有的需求都看作同样重要，那么项目管理者在开发或节省预算或调度中就丧失控制自由度。 8. 无二义性 对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语言表达出来。避免二义性的有效方法包括对需 求文档的正规审查，编写测试用例，开发原型以及设计特定的方案脚本。 9. 可验证性 检查一下每项需求是否能通过设计测试用例或其它的验证方法，如用演示、检测等来确定产品是否确实按需求实现了。如果需求不可验证，则确定其实施是否正确就成为主观臆断，而非客观分析了。一份前后矛盾，不

23、可行或有二义性的需求也是不可验证的。,42,3.6 软件原型系统开发,43,传统模型的工作特点,传统软件生存期模型的典型代表是“瀑布模型”。这种模型将软件生存期划分为若干阶段，根据不同阶段的工作特点，运用不同的方法、技术和工具来完成该阶段的任务。 传统思想之所以强调每一阶段的严格性，尤其是开发初期要有良好的软件说明，主要是源于过去软件开发的经验教训，即在开发的后期或运行维护期间，修改不完善的规格说明要付出巨大的代价。,44,什么是原型系统开发,建立系统模型以后，还要进行检查。除了静态检查外，系统描述可以部分地模拟执行，将执行情况与对外部现实世界系统观察得到的系统跟踪信息进行对照，检查模型是否符

24、合要求。这种建立系统模型并模拟执行和检查的办法叫做系统原型开发。,45,软件系统的快速原型的概念的形成,在实际工作中，特别是对于一些大型的软件项目，在开发的早期用户往往对系统只有一个模糊的想法，很难完全准确地表达对系统的全面要求，软件人员对于要解决的应用问题认识更是模糊不清。 随着开发工作向前推进，用户可能产生新的要求，或因环境变化，要求系统也随之变化；开发者又可能在设计与实现的过程中遇到一些没有预料到的困难，需要以改变需求来解脱困境。,46,3.6.1 软件原型化方法概述,通常，原型是指模拟某种产品的原始模型。在软件开发过程中，原型是软件一个早期可运行的版本，它反映最终系统的部分重要特性。

25、系统原型是软件系统的初始版本，它可用来展示一些概念，给出设计选择、发现问题和可能的解决方案。其目的就是为了有效的控制开发成本，使开发人员可以较早地在原型系统上验证自己的设计。,47,软件原型支持需求工程过程的活动,1.需求的导出 系统原型允许用户在上面实验，以便了解系统如何支持他们的工作的。在这个过程中，用户可能产生有关需求的许多新的想法，同时发现系统的优点和不足，进而提出新的系统需求。 2.需求的有效性验证 原型系统可以暴露出错误和遗漏的东西。一个经过描述的功能可能是很有用且已经是定义了的，但是，当这个功能模块与其他模块一起工作时，用户可能发现他们最初的想法是错误的或是不完善的，必须修改系统

26、描述以反映对需求的新的理解。,48,系统原型开发的优点,1.开发人员和用户之间的理解偏差在功能展示显露出来。 2.开发小组可能会在原型设计中发现需求的不完善和不一致。 3.可以迅速展示一个应用系统对管理的可行性和作用。 4.原型可以用作书写产量-质量系统描述的基础。 5.原型可支持用户的训练和系统的测试。,49,原型开发的过程模型,50,研究发现系统原型开发的其它优点,Gordon和Bieman经过研究发现，在软件过程中使用原型还具有如下的优点： 1.提高了系统的实用性。 2.使系统与用户需求更贴近。 3.提高了系统的设计质量。 4.提高了系统的可维护性。 5.减少了开发的投入。 研究发现，用

27、原型法来提高系统的实用性和更好地满足用户需求并不一定意味着开发成本提高。,51,3.6.2 软件过程中的原型开发,原型开发的种类有两种： 1.进化式原型 采用进化式的系统开发方法，就是在系统尚未完善的时候就呈现给用户，边修改边完善，在完善过程中逐渐地把需求弄明白。 2.抛弃式原型 采用原型开发方法进行需求分析和有效性验证，评估一结束，就抛弃掉原型，重建一个完整的系统。,52,两点重要区别,1.进化式原型的目标是给用户一个实用的系统。原型开发必须从对用户需求把握最准的部分做起，最优处理这部分。而对用户需求把握程度较差的部分和模糊的需求安排得稍后一些，可以在用户明确要求后再处理。 2.抛弃式原型开

28、发的目标是验证和导出需求。此时应从理解得不够好的那部分需求开始实现，因为要从目标中发现问题，对明确的需求就没必要去做原型。,53,进化式原型开发,进化式原型开发的思路是：先给出一个系统的最初实现，让用户去使用和评论，再不断进行细化和完善，经过多个这样的反复过程后形成最后完善的应用系统。 进化式开发已经成为快速应用开发(RAD)和联合应用开发(JAD)技术中的一部分,已成为一个软件开发的主流技术。,54,进化式原型开发,55,进化式原型开发方法的优势,1.加快系统交付的进度 现在的商业节奏加快意味着软件支持能否快速到位是最根本的。在某些情况下，快速交货就比提供完备功能或保证长期可维护性更为重要。

29、 2.用户的参与 用户在软件开发过程中的介入不仅仅意味着系统可以更好地理解软件需求，还意味着可以使用户逐渐喜欢系统，在工作中依赖它。,56,进化式原型开法与快速开发方法的共同基本性质,1.描述、设计和实现三个过程是交叉进行的 ，没有详细的系统描述，设计文档一般都依赖于开发系统所使用的工具，用户需求文档只描述系统的最重要的特征。 2.系统是逐渐增进的。在每一次增进过程中，最终用户和其他系统项目的相关人员都参与到设计和评估中来。他们可能提出对系统改进的意见。新的需求又会在随后的版本中被实现。 3.采用了快速开发技术。 4.系统用户界面都是交互式开发系统来实现的。,57,进化式原型开发方法应注意的问

30、题,1.管理问题 大型系统软件管理机构建立起来以处理软件过程模型。软件过程模型定期产生可交付的文档来评估项目进展的情况。原型的开发太快，以致产生大量的系统文档。 专业技术技能不可能应用到每个开发的团队。 2.维护问题 连续不断地对原型的修改很可能导致系统的崩溃。 如果快速原型开发中使用了某项专门的技术，有可能在以后寻找具有相关知识的人来维护系统变得十分困难。 3.契约问题 客户和软件开发商之间正规的契约模型是基于系统描述的。,58,增量开发方法,该开发方法避免了进化式原型开发中的经常性变更问题。即首先建立一个总的框架，以后就以该框架结构为基础进行开发。 在增量开发方法中，必须给出每一部分的需求

31、和文档。使得用户的意见能及时地反馈，以减少错误的出现。,59,增量开发方法,60,抛弃式原型开发,抛弃式原型开发的根本作用是弄清楚需求和为管理人员评估过程风险提供额外的信息。 在抛弃式原型开发中，我们只注重其功能，而忽略其质量标准和性能指标，使这些功能经过原型设计而得到深刻理解。 经过评估，原型被抛弃，不再作为系统开发的基础。其原型开发和最终系统开发使用的语言也往往不一样。,61,抛弃式原型开发,62,抛弃式原型方法存在以下问题,1. 为了尽快拿出原型，系统可能做了许多简化，因而不可避免要遗漏一些重要特性。 2.在客户和承包商之间没有一个能写进合同的对于原型实现的合法规定。 3.非功能需求，若

32、可靠性、安全性，在原型实现中不会得到充分反映。,63,3.6.3 快速原型技术,快速原型技术强调的是交付的速度，而非系统的性能、可维护性和可靠性。 目前，有三种较实用的快速原型技术： 1.动态高级语言开发。 2.数据库编程。 3.组件和应用集成。,64,快速原型技术,65,使用动态高级语言的开发,动态高级语言开发是一种包含运行时数据管理强大功能的编程语言。 每当选择一种语言时，需回答以下问题： 1.问题的应用领域是什么？ 2.需要什么样的用户交互？ 3.语言提供的支撑环境如何？ 动态的高级语言可以混合使用以构件系统原型。,66,数据库程序设计,1.交互式表格定义 开发者定义要显示的各个域及其位

33、置。 2.表格之间的关联 开发者定义某个特定的输入将导致后续的表格显示。 3.域验证 开发者定义每个域输入值的允许范围。,67,组件和应用集成,如果系统中许多部分都可以复用而且不需重新进行设计和实现，那么系统开发的时间就会缩短。 利用可复用组件在系统描述中说明哪些可复用组件是可再利用的。,68,原型开发的两个层次实现,1. 应用层 整个应用系统与原型结合在一起，功能模块可以共享。 2. 组件层 单个组件集成进标准的框架从而完成系统的构造。,69,组件和应用集成优势,许多原型中的功能模块可以以极低的成本来实现，如果原型用户对这些较熟悉，就不需花费额外的时间去学习这些功能。,70,3.6.4 软件

34、复用,可复用的软件与快速构造原型关系很密切。一堆可复用的模块单独看可能是无用的，但快速构造的原型系统就是靠它们连接起来而得到的。 对建立软件目标系统而言，复用就是利用早先开发的对建立新系统有用的信息来生产新系统。它是一项活动，而不是一个对象。,71,软件复用的条件,必须有简单而清晰的界面； 它们应当有高自包含性，即尽量不依赖其他模块或数据结构； 它们应具有一些通用的功能。当然，还应有好的文档，所有模块的接口、功能和错误条件描述应遵守一定的规范。,72,软件复用的范围,1) 复用数据：指程序不做任何修改，甚至输入输出数据的格式也无需改动，就可以从一个环境移到另一个环境中使用。 2) 复用模块：早

35、期可复用模块的概念是指单个函数，它们不需要逐行编码就可以连接到一个程序中去 。 3) 复用结构：有效的复用应有一个结构上的考虑，而不仅是将模块连接在一起。 4) 复用设计：软件设计与实现是两个不同的阶段。若对于同一个设计，可以采用不同的实现方法，则这样的设计就是可复用的。 5) 复用规格说明：在基本需求不改变，或某一新问题与过去的某一软件在某个抽象层次上属于同一类的情况下，原规格说明仍可使用或参照使用。,73,软件复用技术,软件复用技术可分为两大类：合成技术和生成技术。 1) 合成技术：在合成技术中，构件(Building Blocks)是复用的基石。构件方法以抽象数据类型为理论基础，借用了硬

36、件中集成电路芯片的思想：即将功能细节与数据结构隐藏封装在构件内部，有着精心设计的接口。构件在开发中像芯片那样使用，它们可以组装成更大的构件。构件可以是某一函数、过程、子程序、数据类型、算法等可复用软件成份的抽象，利用构件来构造软件系统，有较高的生产率和较短的开发周期。,74,三种方式将构件合成更大的构件, 连接。通常，标准函数库中的标准函数是靠编译和连接程序与其他模块一起合成系统的 消息传递和继承。例如smalltalk面向对象的程序设计体系结构，就是通过消息传递和继承机制把对象类与其相关的其他对象类联系起来合成一个系统的。 管道机制。例如，UNIX中用管道(pipe)连接shell命令，使前

37、一命令的输出成为后一命令的输入，用管道机制把多个shell命令连接在一起完成一个更复杂的功能。,75,软件复用技术,2) 生成技术：生成技术利用可复用的模式(Patterns)，通过生成程序产生一个新的程序或程序段，产生的程序可以看成是模式的实例。可复用的模式有两种不同的形式：代码模式和规则模式。前者的例子是应用生成器，可复用的代码模式就存在于生成器自身。通过特定的参数替换，生成抽象软件模块的具体实体。后者的例子是变换系统，它利用变换规则集合。其变换方法中通常采用超高级的规格说明语言，形式化地给出软件的需求规格说明，利用程序变换系统(有时要经过一系列变换)，把用超高级规格说明语言编写的程序转化

38、成某种可执行语言的程序。这种超高级语言抽象能力高，逻辑性强，形式化好，便于使用软件者维护。,76,两种复用技术比较,构件方法支持自底向上的软件开发方法，应当具有硬软件独立性、可读性、可理解性、正确性和可修改性。 变换方法侧重于程序的推导方式、推理规则，支持自顶向下的软件开发技术。由于它的形式化程度高，抽象性强，一般软件开发者不易掌握，在描述某些实际问题时也有困难。另外，经过多次变换得到的可执行程序的效率较低，在时间和存储空间方面的需求较高，这都是需要解决的问题。 可以将这两种方法结合起来使用，取长补短，再吸收人工智能的研究成果，以知识库为辅助工具，可促进复用技术的成熟。,77,3.7 结构化分

39、析方法,78,结构化分析方法(Strutured Analisys),结构化分析是面向数据流进行分析的方法，结构化分析方法适用与数据处理类型软件的需求分析。 结构化分析方法是利用抽象模型的概念，按照软件内部数据传递，变换的关系，自顶向下，逐步分解，直到找到满足功能要求的所有可实现的软件为止。 结构化方法使用以下几个工具：数据流图，数据字典，结构化语言，判定树和判定表等。,79,3.7.1 系统流程图,1 符号 当以概括的方式抽象地描绘一个物理系统时，仅仅使用图3.7.1中列出的基本符号就够了，其中每个符号表示系统中的一个部件。 当需要更具体地描绘一个物理系统时还需要使用图3.7.2中列出的系统

40、符号，利用这些符号可以把一个广义的输入输出操作具体化为读写存储在特殊设备上的文件（或数据库），把一般的处理具体化为特定的程序或手工操作等等。,80,例子,某装配厂有一座存放零件的仓库，仓库中现有的各种零件的数量以及每种零件的库存量临界值等数据记录在库存清单主文件中。当仓库中零件数量有变化时，应该及时修改库存清单主文件，如果那种零件的库存量少于它的库存量临界值，则应该报告给采购部门以便订货，规定每天向采购部门送一次订货报告。 该装配厂使用一台小型计算机处理更新库存清单主文件和产生订货报告的任务。零件库存量的每一次变化称为一个事务，由放在仓库中的CRT终端输入到计算机中；系统中的库存清单程序对事务

41、进行处理，更新存储在磁盘上的库存清单主文件，并且把必要的订货信息写在磁带上。最后，每天由报告生成程序读一次磁带，并且打印出订货报告。,81,例子,82,3.7.2 数据流图(DFD,Data Flow Diagram),数据流图描绘系统的逻辑模型，图中没有任何具体的物理元素，只是描绘信息在系统中流动和处理的情况。因为数据流图是逻辑系统的图形表示，即使不是专业的计算机技术人员也容易理解，所以是极好的通信工具。,83,3.7.2 数据流图(DFD,Data Flow Diagram),1. 符号 数据流图有四种基本符号：正方形（或立方体）表示数据的源点或终点；圆角矩形（或圆形）代表变换数据的处理；

42、开口矩形（或两条平行横线）代表数据存储；箭头表示数据流，即特定数据的流动方向。注意，数据流与程序流程图中用箭头表示的控制流有本质不同，千万不要混淆。熟悉程序流程图的初学者在画数据流图时，往往试图在数据流图中表现分支条件或循环，殊不知这样做将造成混乱，画不出正确的数据流图。在数据流图中应该描绘所有可能的数据流向，而不应该描绘出现某个数据流的条件。(图示),84,数据流图性质, 数据流图中的箭头仅能表示在系统中流动的数据； 与程序流程图不同，DFD不能表示程序的控制结构； DFD表现的范围具有很大的灵活性。,85,例1,假设一家工厂的采购部每天需要一张订货报表，报表按零件编号排序，表中列出所有需要

43、再次订货的零件。对于每个需要再次订货的零件应该列出下述数据：零件编号，零件名称，订货数量，目前价格，主要供应者，次要供应者。零件入库或出库称为事务，通过放在仓库中的CRT终端把事务报告给订货系统。当某种零件的库存数量少于库存量临界值时就应该再次订货。 (勾画分析表),86,例2,以到银行取款为例。某年某日储户到银行把存折和取款单一并交给银行出纳员检验。出纳员核对账目，一旦发现存折有效性问题、取款单填写问题或是存折、帐卡与取款单不符等问题时均应报告储户。在检验通过后，出纳员将取款信息登录在存折和帐卡上，并通知付款。根据付款通知给储户付款。到此，整个取款过程完成。 首先从问题描述中提取数据流图的四

44、种成分。 数据的源点：储户、日历（隐含）。 数据的终点：储户 处理有：检验、登录、付款。 数据存储：存折、帐卡 数据流：储户提交的存折和取款单、帐卡提供的帐卡信息，检验通不过时出纳员告知的检查出的问题、通过检验后的取款信息、付款通知、付给储户的现款以及日历提供的提款时间信息,87,例2,88,3.7.2 数据流图(DFD,Data Flow Diagram),2. 命名 数据流图中每个成分的命名是否恰当，直接影响数据流图的可理解性。因此，给这些成分起名字时应该仔细推敲。下面讲述在命名时应注意的问题： 为数据流（或数据存储）命名 名字应代表整个数据流（或数据存储）的内容，而不是仅仅反映它的某些成

45、分。 不要使用空洞的、缺乏具体含义的名字（如“数据”、“信息”、“输入”之类）。 如果在为某个数据流（或数据存储）起名字时遇到了困难，则很可能是因为对数据流图分解不恰当造成的，应该试试重新分解，看是否能克服这个困难。,89,3.7.2 数据流图(DFD,Data Flow Diagram), 为处理命名 通常先为数据流命名，然后再为与之相关联的处理命名。这样命名比较容易，而且体现了人类习惯的“由表及里”的思考过程。 名字应该反映整个处理的功能，而不是它的一部分功能。 名字最好由一个具体的及物动词，加上一个具体的宾语组成。应该尽量避免使用“加工”、“处理”等空洞笼统的动词作名字。 通常名字中仅包

46、括一个动词，如果必须用两个动词才能描述整个处理的功能，则把这个处理再分解成两个处理可能更恰当些。 如果在为某个处理命名时遇到困难，则很可能是发现了分解不当的迹象，应考虑重新分解。,90,3.7.2 数据流图(DFD,Data Flow Diagram),3. 用途 画数据流图的基本目的是利用它作为交流信息的工具。分析员把他对现有系统的认识或对目标系统的设想用数据流图描绘出来，供有关人员审查确认。由于在数据流图中通常仅仅使用四种基本符号，而且不包含任何有关物理实现的细节，因此，绝大多数用户都可以理解和评价它。 从数据流图的基本目标出发，可以考虑在一张数据流图中包含多少个元素合适的问题。一些调查研

47、究表明，如果一张数据流图中包含的处理多于59个，人们就难于领会它的含义了。因此数据流图应该分层，并且在把功能级数据流图细化后得到的处理超过9个时，应该采用画分图的办法，也就是把每个主要功能都细化为一张数据流分图，而原有的功能级数据流图用来描绘系统的整体逻辑概貌。,91,分层数据流图,1. 概念 为有效控制复杂度，在产生数据流图时采用分层技术。 2. 组成 把一个系统分为顶层DFD、中间层DFD和底层DFD。,92,分层数据流图,93,分层数据流图,3. 分层原则 父图与子图关系 编号 平衡规则 文件局部性 分解程度,94,3.7.3 数据字典(DD,Data Dictionary),数据字典是

48、关于数据的信息的集合，也就是对数据流图中包含的所有元素的定义的集合。 任何字典最主要的用途都是供人查阅对不了解的条目的解释，数据字典的作用也正是在软件分析和设计的过程中给人提供关于数据的描述信息。 数据流图和数据字典共同构成系统的逻辑模型，没有数据字典数，数据流图就不严格，然而没有数据流因数据字典也难于发挥作用。只有数据流图和对数据流图中每个元素的精确定义放在一起，才能共同构成系统的规格说明。 数据字典中所有的定义应是严密的、精确的，不可有半点含混，不可有二义性。,95,3.7.3 数据字典(DD,Data Dictionary),1. 数据字典的定义 对在数据流图中每一个命名的图形元素均给予

49、定义，其内容有图形元素的名字、别名或编号、分类、描述、定义、位置等。 数据流词条描述 数据流是数据结构在系统内传播的路径。一个数据流词条有以下几项内容。 数据元素词条描述 图中的每一个数据结构都是由数据元素构成的，数据元素是数据处理中最小的，不可再分的单位，它直接反映事物的某一特征。 数据文件词条描述 数据文件是数据结构保存的地方。一个数据文件词条有以下几项内容 加工逻辑词条描述 加工比较复杂，它到后来就是一段程序，加工的表达方式有判定表，判定树如何结构化语言等等，它们要全部写在一个词条中是有困难的。,96,3.7.3 数据字典(DD,Data Dictionary),2. 定义数据的方法 定

50、义绝大多数复杂事物的方法，都是用被定义的事物的成分的某种组合表示这个事物，这些组成成分又由更低层的成分的组合来定义。从这个意义上说，定义就是自顶向下的分解，所以数据字典中的定义就是对数据自顶向下的分解。那么，应该把数据分解到什么程度呢？一般说来，当分解到不需要进一步定义，每个和工程有关的人也都清楚其含义的元素时，这种分解过程就完成了。 由数据元素组成数据的方式只有下述三种基本类型： 顺序 即以确定次序连接两个或多个分量； 选择 即从两个或多个可能的元素中选取一个； 重复 即把指定的分量重复零次或多次。 可选 即一个分量是可有可无的（重复零次或一次）。,97,3.7.3 数据字典(DD,Data

51、 Dictionary),98,例,例：数据文件的存折格式的数据字典中的定义格式为： 存折=户名+所号+帐号+开户日+性质+(密印)+1存取行50 户名=2字母24 所号=“000”“999” 注：储蓄所编码，规定三位数字 帐号=“00000001”.“99999999” 注：帐号规定由八位数字组成 开户日=年+月+日 性质=“1”.“6” 注：“1”表示普通用户，“5”表示工资户等 印密=”0” 注：“1”表示普通用户，“5”表示工资户等 存取行=日期+ (摘要)+支出+存入+余额+操作+复核 日期=年+月+日 年=“00”.“99” 月=“01”.“12” 日=“01”.“31” 摘要=1

52、字母4 注：表明该存取是存？是取？还是换？ 支出=金额 注：金额规定不超过9999999.99元 金额=“0000000.01”.“9999999.99” 操作=“00001”.“50000”,99,3.7.3 数据字典(DD,Data Dictionary),3. 数据字典的用途 数据字典最重要的用途是作为分析阶段的工具。在数据字典中建立的一组严密一致的定义有助于改进分析员和用户之间的通信，因此将消除许多可能的误解。对数据的这一系列严密一致的定义也有助于改进在不同的开发人员或不同的开发小组之间的通信。如果要求所有开发人员都根据公共的数据字典描述数据和设计模块，则能避免许多麻烦的接口问题。 数

53、据字典中包含的每个数据元素的控制信息是很有价值的。因为列出了使用一个给定的数据元素的所有程序（或模块），所以很容易估计改变一个数据将产生的影响，并且能对所有受影响的程序或模块作出相应的改变。 最后，数据字典是开发数据库的第一步，而且是很有价值的一步。,100,3.7.3 数据字典(DD,Data Dictionary),4. 数据字典的实现 目前实现数据字典有三种常见的途径：全人工过程，全自动化过程（利用数据字典处理程序）和混合过程（用正文编辑程序，报告生成程序等已有的实用程序帮助人工过程）。不论使用哪种途径实现的数据字典都应该具有下述特点： 通过名字能方便地查阅数据的定义； 没有冗余； 尽量

54、不重复在规格说明的其他组成部分中已经出现的信息； 容易更新和修改； 能单独处理描述每个数据元索的信息； 定义的书写方法简单方便而且严格。 此外，如果再带有产生交叉参照表、错误检测、一致性校验等功能则更好。,101,3.7.3 数据字典(DD,Data Dictionary),如果暂时还没有自动的数据字典处理程序，建议采用卡片形式书写数据字典，每张卡片上保存描述一个数据元素的信息。这种做法较好地实现了上述要求，特别是更新和修改起来很方便，能够单独处理每个数据元素的信息。每张卡片上主要应该包含下述这样一些信息： 名字、别名描述、定义、位置。 当开发过程进展到能够知道数据元素的控制信息和使用特点时，

55、把这些信息记录在卡片的背面。,102,卡片字典的例子,103,3.7.4 加工逻辑说明,在数据流图中，每个加工框中只简单地写上了一个加工名，这显然不能表达加工的全部内容。随着自顶向下逐步细化，功能越来越具体，加工逻辑也越来越精细。到最底一层，加工逻辑详细到可以实现的程度，因此称为“原子加工”或“基本加工”。如果能够写出每一个基本加工的全部详细逻辑功能，再自底向上综合，就能完成全部逻辑加工。,104,3.7.4 加工逻辑说明,在写基本加工逻辑的说明时，应满足如下要求： 对数据流图的每一个基本加工，必须有一个加工逻辑说明； 加工逻辑说明必须描述基本加工如何把输入数据流变换为输出数据流的加工规则；

56、加工逻辑说明必须描述实现加工的策略而不是实现加工的细节； 目前用于写加工逻辑说明的工具有结构化语言、判定表和判定树。,105,3.7.4 加工逻辑说明,1. 结构化语言 所谓结构化语言是一种介于自然语言和形式化语言之间的半形式化语言。它是在自然语言基础上加了一些限制而得到的语言，是使用有限的词汇和有限的语句来描述加工逻辑。结构化英语的词汇表由英语命令动词、数据字典中定义的名字、有限的自定义词和控制结构关键词IF-THEN-ELSE、WHILE-DO、REPEAT-UNTIL、CASE-OF等组成。其动词的含义要具体，尽可能少用或不用形容词和副词。,106,3.7.4 加工逻辑说明,下面是商店业务处理系统中“检查发货单”的例子。 IF the invoice exceeds $500 THEN (发货单金额超过$500) IF the account has any invoice more than 60 days overdue T