第 5 章 应用系统规划 5.2 主要内容 应用系统规划设计包括对相关应用系统进行分级分类，并根据分级分类的结果，对 应用系统进行生命周期选择、体系结构定义、接口定义、数据定义、构件定义等。 接口规划设计有三个重要元素：1）用户界面；2）和其他系统、设备、网络或其他 信息生产者或使用者的外部接口；3）各种构件之间的内部接口。 1． 生命周期选择 应用系统的生命周期是指从规划设计该系统的构想开始，到系统需求的确定、系统 设计、系统实现、产品测试与验收、投入使用以及应用系统版本的不断更新，到最终该 应用系统退役的全过程。 生命周期模型把应用系统生命周期细分为几个阶段，这些阶段需要包含识别用户需 求、开发、测试、安装、运行以及退役这几个步骤。 （1）瀑布模型 20 世纪 80 年代之前瀑布模型是一个被广泛采用的生命周期模型，其特点如下： l 阶段间具有顺序性和依赖性。其中包含两种含义：必须等前一阶段的工作完成后， 才能开始后一阶段的工作；前一阶段的输出成果就是后一阶段的输入内容。 l 推迟实现的观点。瀑布模型在编码之前设置了系统分析和系统设计的各个阶段。分 析与设计阶段的基本任务规定，在这两个阶段主要考虑目标系统的逻辑模型，不涉 及物理实现。清楚地区分逻辑设计与物理设计，尽可能推迟程序的物理实现，是按 照瀑布模型开发应用系统的一条重要的指导思想。 l 质量保证的观点。每个阶段都必须完成规定的内容，没有交出合格的成果就是没有 完成该阶段的任务。每个阶段结束前都要对所完成的成果进行评审，以便尽早发现 问题，改正错误。 （2）V 模型 ① V 模型是瀑布模型的变种，它主要描述了测试活动是如何与分析和设计活动相关 联的。 ② 编码是 V 模型的顶点，分析和设计在模型的左侧，测试和维护在右侧。 ③ 单元测试和集成测试关注程序的正确性。V 模型说明单元测试和集成测试也可以 用来验证程序设计。 也就是说，在单元测试和集成测试期间，编码人员和测试团队成员应确保编码正确 地实现了程序设计的意图。类似地， 系统测试应能验证系统设计，确保系统设计得到正 确实现。由用户而不是开发人员主导的验收测试，通过把测试和需求规格说明的每一个 元素相关联，进行需求的确认，验收测试主要检查在系统交付之前所有的需求是否都被 实现了。 （3）迭代模型 ① 迭代模型分为两种： 一种是演化建设，即开始交付的就是一个完整的应用系统 ，然后在后续迭代中不断完善 系统的功能和质量； 另一种是增量建设，即将应用系统作为 一系列的增量构件来规划设计、编码集成和测试， 刚开始交付的是一个实现了部分功能的子系统，然后在后续迭代中不断增加新的功能。 ② 迭代模型的优点是： l 逐步增加应用系统的功能可以使用户有较充裕的时间学习和适应新产品，从而减少 全新的应用系统可能给用户带来的冲击。 l 建设失败的风险较低，虽然在某些增量构件中可能遇到一些问题，但其他增量构件 将能够成功地交付给客户。 l 优先级最高的服务首先交付，然后再将其他增量构件逐次集成进来。这样带来一个 必然的事实是，最重要的系统服务将接受最多的测试。这意味着系统最重要的部分 一般不会遭遇失败。 ③ 采用迭代模型需注意的问题是： 1）在把每个新的增量构件集成到现有的应用系 统体系架构中时必须不破坏原来已经部署的应用系统内容；2）应用系统体系架构必须是 开放的，即向现有应用系统中加入新构件的过程必须简单、方便。 （4）敏捷方法 ① 敏捷宣言的 4 种核心价值是：1）个体和互动高于流程和工具。2） 工作的软件高 于详尽的文档。3）客户合作高于合同谈判。4）响应变化高于遵循计划。 ② 敏捷宣言的 12 条原则包括： l 最高优先级的是，通过尽早和持续交付有高价值的软件，满足客户。 l 欣然面对需求变化， 即使是在开发阶段的后期，敏捷流程就是用变化来为客户获得 竞争优势。 l 频繁交付可工作的软件，从数周到数月，交付周期越短越好。 l 在项目过程中，业务人员、开发人员必须每天在一起工作。 l 以受到激励的个体为核心构造项目，为他们提供所需的环境和支持，信任他们可以 把工作做好。 l 最有效的、最高效的沟通方法是面对面的交谈。 l 可工作的软件是衡量进度的首要标准。 l 敏捷流程倡导可持续开发，客户、开发人员、用户要能够共同、长期维持步调（节 奏）、稳定向前。 l 持续地追求技术卓越和良好的设计，以此增强敏捷的能力。 l 简单，尽最大可能减少不必要的工作，简单是敏捷流程的根本。 l 最佳架构、需求和设计，来自自组织型的团队。 l 团队定期反思如何提升效率，并调节和调整自己的工作方式。 （5）生命周期模型选择 从前面所介绍的几种不同的生命周期模型中可以看到每个生命周期模型都会包含下 面这些通用的活动： ① 和用户达成一致的需求。 ② 基于需求的规划设计。 ③ 基于规划设计的构造。 ④ 基于所有优先级步骤的测试流程的构建。 ⑤ 每一阶段的出口和入口标准。活动的某些部分会重叠，但基本上是顺序关系。 2． 体系结构定义 在对应用系统进行体系结构定义时，首先从系统的功能入手，按照工程标准和严格 的规范将目标系统划分为若干功能模块。 （1）面向数据流的定义方法 ① 面向数据流的定义方法是常用的结构化规划设计方法，多在概要阶段使用。它主 要是指依据一定的映射规则，将需求分析阶段得到的数据描述从系统的输入端到输出端 所经历的一系列变换或处理的数据流图转换为目标系统的结构描述。 ② 在数据流图中，数据流分为变换型数据流和事务型数据流两种。 所谓变换，是指把输入的数据处理后转变成另外的输出数据。 所谓事务，是指非数据变换的处理，它将输入的数据流分散成许多数据流，形成若 干个加工，然后选择其中一个路径来执行。 （2）针对变换型数据流的规划设计可以分为以下三个步骤： ① 区分变换型数据流中的输入数据、变换中心和输出数据， 并在数据流图上用虚线 标明分界线； ② 分析得到系统的初始结构图； ③ 对系统结构图进行优化。 （3）针对事务型数据流的规划设计可以分为以下三个步骤： ① 确定以事务为中心的结构，找出事务中心、接收数据、处理路径三个部分； ② 将数据流图转换为初始的系统结构图； ③ 分解和细化接收分支和处理分支。 （2）面向数据结构的定义方法 面向数据结构的定义方法就是根据数据结构规划设计程序处理过程的方法。使用面 向数据结构的定义方法时，分析目标系统的数据结构是关键。 面向数据结构的定义方法通常在详细设计阶段使用。 比较流行的面向数据结构的定义方法包括 Jackson 方法和 Warnier 方法。Warnier 方 法仅考虑输入数据结构，而 Jackson 方法不仅考虑输入数据结构，还考虑输出数据结构。 Jackson 方法把数据结构分为三种基本类型：顺序型结构、 选择型结构和循环型结构。 （3）表示应用系统体系结构的图形工具 ① 层次图：通常使用层次图描绘应用系统的层次结构。在层次图中， 一个矩形框代 表一个模块，框间的连线表示调用关系（位于上方的矩形框所代表的模块调用位于下方 的矩形框所代表的模块）。每个方框可以带编号，像这样带编号的层次图也称为 HIPO 图。 ② 结构图：结构图和层次图类似，也是描绘体系结构的图形工具，图中一个方框代 表一个模块，框内注明它们的名字或主要功能，方框之间的箭头（或直线）表示它们间 的调用关系。在结构图中通常还用带注释的箭头表示模块调用过程中来回传递的信息。 如果希望进一步标明传递的信息是数据还是控制信息，则可以利用注释箭头尾部的形状 来区分，尾部是空心圆表示传递的是数据，尾部是实心圆表示传递的是控制信息。 3． 接口定义 （1）接口定义的内容应包括 功能描述、接口的输入/输出定义、错误处理等。接口 定义通常需要包括以下几个方面： ① 用户接口。用来说明将向用户提供的命令和它们的语法结构以及应用系统回答信 息。 ② 外部接口。用来说明本系统同外界的所有接口的安排， 包括软件与硬件之间的接 口、本系统与各支持系统之间的接口关系。 ③ 内部接口。用来说明本系统之内的各个系统元素之间的接口的安排。 (2) 界面定义是接口定义中的重要组成部分 。指导用户界面定义活动的基本原则如 下： ① 置用户于控制之下。1）以不强迫用户进入不必要的或不希望的动作的方式来定 义交互模式；2）提供灵活的交互；3）允许用户交互被中断和撤销；4）当技能级别增长 时可以使交互流水化并允许定制交互；5）使用户隔离内部技术细节；6）应允许用户和 出现在屏幕上的对象直接交互。 ② 减少用户的记忆负担。1）减少用户对短期记忆的要求； 2）建立有意义的默认设 置；3）定义直觉性的捷径；4）界面的视觉布局应该基于真实世界的隐喻；5）以不断进 展的方式揭示信息。 ③ 保持界面一致。1）允许用户将当前任务放入有意义的语境，在应用系统内保持 一致性； 2）如果过去的交互模式已经建立起了用户期望，则不要改变它，除非有不得 已的理由。 （3）明确系统界面是一个迭代的过程，其核心活动包括：1）创建系统功能的外部 模型；2）确定为完成此系统功能，人和计算机应分别完成的任务；3）考虑界面定义中 的典型问题；4）借助 CASE 工具构造界面原型；5）评估界面质量。 （4）在界面定义中，应该考虑以下 4 个问题： 1）系统响应时间。指当用户执行了 某个控制动作（如单击鼠标等）后，系统做出反应的时间。 2）用户求助机制。用户都 希望得到联机帮助，联机帮助系统有两类：集成式和叠加式。3） 出错信息。应选用用户 明了、含义准确的术语描述， 同时还应尽可能提供一些有关错误恢复的建议。4）命令方 式。键盘命令虽不再是唯一的交互形式，但许多有经验的熟练的软件人员仍喜爱这一方 式，更多的情形是菜单与键盘命令并存，供用户自由选用。 4． 数据定义 数据定义就是将需求分析阶段定义的数据对象转换为数据结构和数据库的过程，注 意要对程序级的数据结构和应用级的数据库两个方面进行定义。数据库的定义过程大致 可分为需求分析、定义概念模型、定义逻辑模型、定义物理数据库、验证 5 个步骤： ① 需求分析。调查和分析用户的业务活动和数据的使用情况，弄清所用数据的种类、 范围、数量以及它们在业务活动中交流的情况，确定用户对数据库系统的使用要求和各 种约束条件等，形成用户需求规约。 ② 定义概念模型。对用户要求描述的现实世界， 通过对其中信息的分类、聚集和概 括，建立抽象的概念数据模型。 ③ 定义逻辑模型。主要工作是将现实世界的概念数据模型转成数据库的一种逻辑模 式，即某种特定数据库管理系统所支持的逻辑数据模式。 ④ 定义物理数据库。根据特定数据库管理系统所提供的多种存储结构和存取方法等 依赖于具体计算机结构的各项物理设计措施，对具体的应用任务选定最合适的物理存储 结构、存取方法和存取路径等。 ⑤ 验证。在上述信息的基础上， 收集数据并具体建立一个数据库，运行一些典型的 应用任务来验证数据库定义的正确性和合理性。 5． 构件定义 对应用系统构件进行定义，将需求模型和架构模型中的信息转化为构件表示，这种 表示提供了用来指导构件（编码和测试）活动的充分信息。进行构件定义的典型任务包 括： l 标识出所有与问题域对应的类。 l 确定所有与基础设施域对应的类。 l 细化所有不需要作为可复用构件的类。 l 说明持久数据源（数据库和文件）并确定管理数据源所需要的类。 l 开发并且细化类或构件的行为表示。 l 细化部署图以提供额外的实现细节。 l 考虑每个构件级定义表示，并且时刻考虑其他可选方案。 6.小结和思考 (1）生命周期选择 - 瀑布模型：顺序依赖，强调质量保证。 - V 模型：测试与分析设计关联，验证程序设计。 - 迭代模型：演化（完整系统逐步完善）与增量（分构件交付），降低风险。 - 敏捷方法：4 大核心价值（个体互动、可工作软件等）+12 条原则（持续交付、 响应变化等）。 （2）体系结构定义 - 面向数据流：变换型（输入→变换→输出）与事务型（事务中心→处理路径） 数据流设计。 - 面向数据结构：Jackson（顺序/选择/循环结构）与 Warnier 方法。 - 图形工具：层次图与结构图描述模块调用关系。 （3）接口定义 - 用户/外部/内部接口，需定义功能、输入/输出及错误处理。 - 界面设计原则：用户控制、减少记忆负担、一致性。 （4）数据定义 - 5 步骤：需求分析→概念/逻辑/物理模型→验证。 （5）构件定义 - 关键任务：标识问题域类、细化行为表示、优化部署图。