南京理工大学软件工程专业复习提纲与习题

南京理工大学软件工程专业复习提纲与习题内容摘要：

组基本需求说明后，通过快速分析构造出一个小型的软件系统，满足用户的基本要求。 使得用户可在试用原型系统的过程中得到亲身感受和受到启发，做出反应和评价。 然后开发者根据用户的意见对原型加以改进。 随着不断试验、纠错、使用、评价和修改，获得新的原型版本，如 此周而复始，逐步减少分析和通信中的误解，弥补不足之处，进一步确定各种需求细节，适应需求的变更，从而提高了最终产品的质量。 (1) 原型的分类 由于运用原型的目的和方式不同，原型可分为以下两种不同的类型： ① 废弃型：先构造一个功能简单而且质量要求不高的模型系统，针对这个模型系统反复进行分析修改，形成比较好的设计思想，据此设计出更加完整、准确、一致、可靠的最终系统。 系统构造完成后，原来的模型系统就被废弃不用。 ② 追加型或演化型：先构造一个功能简单而且质量要求不高的模型系统，作为最终系 12 统的核心，然后通过不断地 扩充修改，逐步追加新要求，最后发展成为最终系统。 有人把废弃型原型又细分为探索型和实验型。 探索型原型的目的是要弄清对目标系统的要求，确定所希望的特性，并探讨多种方案的可行性。 它主要针对开发目标模糊，用户和开发者对项目都缺乏经验的情况。 而实验型原型用于大规模开发和实现之前，考核方案是否合适，规格说明是否可靠。 (2) 原型类型的选择 1984 年 Boar 提出一系列选择原型化方法的因素。 如果是在需求分析阶段要使用原型化方法，必须从系统结构、逻辑结构、用户特征、应用约束、项目管理和项目环境等多方面来考虑，以决定是否 采用原型化方法。 系统结构：联机事务处理系统，相互关联的应用系统适合于用原型化方法，而批处理、批修改等结构不适宜用原型化方法。 逻辑结构：有结构的系统，如操作支持系统、管理信息系统、记录管理系统等适合于用原型化方法，而基于大量算法的系统不适宜用原型化方法。 用户特征：不满足于预先做系统定义说明，愿意为定义和修改原型投资，不易肯定详细需求，愿意承担决策的责任，准备积极参与的用户是适合于使用原型的用户。 应用约束：对已经运行系统的补充，不能用原型化方法。 项目管理：只有项目负责人愿意使用原型化方法，才 适合于用原型化的方法。 项目环境：需求说明技术应当根据每个项目的实际环境来选择。 当系统规模很大、要求复杂、系统服务不清晰时，在需求分析阶段先开发一个系统原型是很值得的。 特别是当性能要求比较高时，在系统原型上先做一些试验也是很必要的。 1992 年 Andriole 给出 6 个问题，用来帮助选择原型方法。 表 指明了对这些问题的典型答案和对使用原型方法的建议。 表 选择适当的原型方法 问 题 废弃型原型法 演化型原型法 其它预备工作 目标系统要解决的问题弄清楚了吗。 是 是 否 问题可以被建模吗。 是 是 否 客户能够确定基本需求吗。 是 ∕ 否 是 ∕ 否 否 需求已经被建立而且比较稳定了吗。 否 是 是 有模糊不清的需求吗。 是 否 是 需求中有矛盾吗。 是 否 是 (3) 原型生存期 原型的开发和使用过程叫做原型生存期。 图 （ a）是原型生存期的模型，图 （ b）是模型 的细化。 13 图 原型生存期 ① 快速分析 ：在分析者和用户的紧密配合下，快速确定软件系统的基本要求。 ② 构造原型 ：在快速分析基础上，根据基本需求，尽快实现一个可运行的系统。 ③ 运行和评价原型 ：用户在开发者指导下试用原型，在试用的过程中考核评价原型的特性，分析其运行结果是否满足规格说明的要求，以及规格说明描述是否满足用户愿望。 ④ 修正和改进 ：根据修改意见进行修改。 如果用修改原型的过程代替快速分析，就形成了原型开发的迭代过程。 开发者和用户在一 次次的迭代过程中不断将原型完善，以接近系统的最终要求。 ⑤ 判定原型完成 ：经过修改或改进的原型，达到参与者一致认可，则原型开发的迭代过程可以结束。 为此，应判断有关应用的实质是否已经掌握，迭代周期是否可以结束等。 判定的结果有两个不同的转向，一是继续迭代验证，一是进行详细说明。 ⑥ 判断原型细部是否说明 ：判断组成原型的细部是否需要严格地加以说明。 原型化方法允许对系统必要成分或不能通过模型进行说明的成分进行严格的详细的说明。 ⑦ 原型细部的说明 ：对于那些不能通过原型说明的所有项目，仍需通过文件加以说明。 严 格说明的成分要作为原型化方法的模型编入词典。 ⑧ 判定原型效果 ：考察用户新加入的需求信息和细部说明信息，看其对模型效果有什么影响 ? 是否会影响模块的有效性 ? 如果模型效果受到影响，甚至导致模型失效，则要进行修正和改进。 ⑨ 整理原型和提供文档。 总之，利用原型化技术，可为软件的开发提供一种完整的、灵活的、近似动态的规格说明方法。 (4) 原型开发技术 通常用于构造原型的一些技术包括可执行规格说明、基于场景的设计、自动程序设计、专用语言、可复用的软件构件和简化假设等等。 其中前三种还适用于用户界面的设计。  可执行规格说明 ：可执行规格说明是用于需求规格说明的一种自动化技术。 可执行规格说明语言可描述系统要“做什么”，但它并不描述系统要“怎样做”。 使用这种方法，人们可以直接观察他们用语言规定的任何系统性行为。 可执行规格说明包括形式化规格说明、有限状态模型和可执行的数据流图。  基于场景的设计 ：一个场景可模拟在系统运行期间用户经历的事件。 它提供了输入─处理─输出的屏幕格式和有关对话的模型。 因此，场景能够给用户显示系统的逼真的视图， 14 使用户得以判断是否符合他的意图。  自动程序设计 ：自动程序设计是可执行规格说 明的替身，主要是指在程序自动生成环境的支持下，利用计算机实现软件的开发。 它可以自动地或半自动地把用户的非过程性问题规格说明转换为某种高级语言程序，主要手段有以下 4 种：  专用语言 ：专用语言是应用领域的模型化语言。 在原型开发中使用专用语言，可方便用户和软件开发者在计划中的系统特性方面的交流。  软件复用技术 ：软件复用技术可分为两大类：合成技术和生成技术。 ① 合成技术：可复用的软件构件可以是对某一函数、过程、子程序、数据类型、算法等可复用软件成份的抽象，利用这些构件来构造软件系统。 用构件合成较大的构件 有三种方式：一是连接；二是消息传递和继承；三是管道 (pipe)机制。 ② 生成技术：利用可复用的模式，通过生成程序产生一个新的程序或程序段，产生的程序可以看做是模式的实例。 可复用的模式有两种不同的形式：代码模式和规则模式。 前者的例子是应用生成器，可复用的代码模式就存在于生成器自身。 通过特定的参数替换，生成抽象软件模块的具体实体。 后者的例子是变换系统，它通常采用超高级的规格说明语言，形式化地给出软件的需求规格说明，利用程序变换系统（有时要经过一系列的变换），把用超高级规格说明语言编写的程序转化成某种可执行语言 的程序。  简化假设 ：简化假设是在开发过程中使设计者迅速得到一个简化的系统所做的假设。 尽管这些假设可能实际上并不能成立，但它们在原型开发过程中可以使开发者的注意力集中在一些主要的方面。 6. 软件需求规格说明和需求评审 (1) 制定软件需求规格说明的原则 1979 年由 Balzer 和 Goldman 提出了做出良好规格说明的 8 条原则。 原则 1：功能与实现分离，即描述要“做什么”而不是“怎样实现” 原则 2：要求使用面向处理的规格说明语言，讨论来自环境的各种刺激可能导致系统做出什么样的功能性反应，来定义一个行为模 型，从而得到“做什么”的规格说明。 原则 3：如果目标软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中。 描述该目标软件与系统的其它系统元素交互的方式。 原则 4：规格说明必须包括系统运行的环境。 原则 5：系统规格说明必须是一个认识的模型，而不是设计或实现的模型。 原则 6：规格说明必须是可操作的。 规格说明必须是充分完全和形式的，以便能够利用它决定对于任意给定的测试用例，已提出的实现方案是否都能满足规格说明。 原则 7：规格说明必须容许不完备性并允许扩充。 原则 8：规格说明必须局部化和松散的耦 合。 它所包括的信息必须局部化，这样当信息被修改时，只要修改某个单个的段落（理想情况）。 同时，规格说明应被松散地构造（即耦合），以便能够很容易地加入和删去一些段落。 尽管 Balzer和 Goldman提出的这 8条原则主要用于基于形式化规格说明语言之上的需求定义的完备性，但这些原则对于其它各种形式的规格说明都适用。 当然要结合实际来应用上述的原则。 (2) 软件需求规格说明 软件需求规格说明是分析任务的最终产物，通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的 各种需求。 表 给出简化的大纲作为软件需求规格说明的框架。 15 表 软件需求规格说明的框架 Ⅰ . 引言 Ⅱ . 信息描述 ⅰ数据流 ⅱ控制流 Ⅲ . 功能描述 ⅰ处理说明 ⅱ限制∕局限 ⅲ 性能需求 ⅳ 设计约束 ⅴ 支撑图 ⅰ控制规格说明 ⅱ 设计约束 Ⅳ . 行为描述 Ⅴ . 检验标 准 Ⅵ . 参考书目 Ⅶ . 附录 (3) 需求规格说明评审 作为需求分析阶段工作的复查手段，在需求分析的最后一步，应该对功能的正确性、完整性和清晰性，以及其它需求给予评价。 评审的主要内容是： 系统定义的目标是否与用户的要求一致； 系统需求分析阶段提供的文档资料是否齐全； 文档中的所有描述是否完整、清晰、准确反映用户要求； 与所有其它系统成分的重要接口是否都已经描述； 被开发项目的数据流与数据结构是否足够，确定； 所有图表是否清楚，在不补充说明时能否理解； 主要功能是否已包括在规定的软件范围之内，是否都已充分说明； 软件的行为和它必须处理的信息、必须完成的功能是否一致； 设计的约束条件或限制条件是否符合实际； 是否考虑了开发的技术风险； 是否考虑过软件需求的其它方案； 是否考虑过将来可能会提出的软件需求； 是否详细制定了检验标准，它们能否对系统定义是否成功进行确认； 有没有遗漏，重复或不一致的地方； 用户是否审查了初步的用户手册或原型； 软件开发计划中的估算是否受到了影响。 为保证软件需求定义的 质量，评审应以专门指定的人员负责，并按规程严格进行。 评审结束应有评审负责人的结论意见及签字。 除分析员之外，用户／需求者，开发部门的管理者，软件设计、实现、测试的人员都应当参加评审工作。 一般，评审的结果都包括了一些修改意见，待修改完成后再经评审通过，才可进入设计阶段。 三、 习题 【 21】软件需求分析阶段的工作，可以分为以下 4个方面：对问题的识别、分析与综合、编写需求分析文档以及 ( )。 供选择的答案： A. 总结 B. 阶段性报告 C. 需求分析评审 D. 以上答案都不正确 【 22】各种需求方法都有它们共同适用的 ( )。 供选择的答案： A．说明方法 B．描述方式 C. 准则 D．基本原则 【 23】 软件需求分析的任务不应包括 ( A )。 进行需求分析可使用多种工具，但 ( B ) 16 是不适用的。 在需求分析中，分析员要从用户那里解决的最重要的问题是 ( C )。 需求规格说明书的内容不应当包括 ( D )。 该文档在软件开发中具有重要的作用，但其作用不应当包括 ( E )。 供选择的答案： A. ① 问题分析 ② 信息域分析 ③ 结构化程序设计 ④ 确定逻辑模型 B. ① 数据流图 ② 判定表 ③ PAD 图 ④ 数据词典 C. ① 要让软件做什么 ② 要给该软件提供哪些信息 ③ 要求软件工作效率如何 ④ 要让软件具有什么样的结构 D. ① 对重要功能的描述 ② 对算法的详细过程性描述 ③ 软件确认准则 ④ 软件的性能 E. ① 软件设计的依据 ② 用户和开发人员对软件要“做什么”的共同理解 ③ 软件验收的依据 ④ 软件可行性分析的依据 【 24】原型化方法是用户和软件开发人员之间进行的一种交互过程，适用于 ( A )系统。 它从用户界面的开发入手，首先形成 ( B )，用户 ( C )，并就 ( D )提出意见，它是一种 ( E )型的设计过程。 供选择的答案： A. ① 需求不确定性高的 ② 需求确定的 ③ 管理信息 ④ 决策支持 B. ① 用户界面使用手册。