第11章 系统设计
第11章 系统设计 2 11.1 介绍 2 11.2 用户需求调查 3 11.2.1 目的 3 11.2.2 角色与职责 3 11.2.3 启动准则 3 11.2.4 输入 3 11.2.5 主要步骤 3 [Step1] 设计准备 3 [Step2] 确定影响系统设计的约束因素 4 [Step3] 确定设计策略 4 [Step4] 系统分解与设计 4 [Step5] 撰写体系结构设计文档 4 [Step6] 体系结构设计评审 5 [后续活动] 5 11.2.6 输出 5 11.2.7 结束准则 5 11.2.8 度量 5 11.3 用户界面设计 5 11.3.1 目的 5 11.3.2 角色与职责 5 11.3.3 启动准则 6 11.3.4 输入 6 11.3.5 主要步骤 6 [Step1] 设计准备 6 [Step2] 用户界面设计 7 [Step3] 撰写用户界面设计文档 7 [Step4] 用户界面设计评审 7 [后续活动] 8 11.3.6 输出 8 11.3.7 结束准则 8 11.3.8 度量 8 11.4 数据库设计 8 11.4.1 目的 8 11.4.2 角色与职责 8 11.4.3 启动准则 8 11.4.4 输入 9 11.4.5 主要步骤 9 [Step1] 设计准备 9 [Step2] 数据库设计 9 [Step3] 撰写数据库设计文档 10 [Step4] 数据库设计评审 11 [后续活动] 11 11.4.6 输出 11 11.4.7 结束准则 11 11.4.8 度量 11 11.5 模块设计 12 11.5.1 目的 12 11.5.2 角色与职责 12 11.5.3 启动准则 12 11.5.4 输入 12 11.5.5 主要步骤 12 [Step1] 设计准备 13 [Step2] 模块设计 13 [Step3] 撰写模块设计文档 13 [Step4] 模块设计评审 13 [后续活动] 14 11.5.6 输出 14 11.5.7 结束准则 14 11.5.8 度量 14 11.6 实施建议 14 第11章 系统设计 系统设计（System Design, SD）是指设计软件系统的体系结构、用户界面、数据库、模块等，从而在需求与代码之 间建立桥梁，指导开发人员去实现能满足用户需求的软件产品。 系统设计过程域是SPP模型的重要组成部分。本规范阐述了系统设计过程域的四个主 要规程： ← 体系结构设计 [SPP-PROC-SD-ARCHITECTURE] ← 用户界面设计 [SPP-PROC-RM-UI] ← 数据库设计 [SPP-PROC-RM-DATABASE] ← 模块设计 [SPP-PROC-RM-MODULE] 上述每个规程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出 ”、“完成准则”和“度量”均已定义。 本规范适用于国内IT企业的软件研发项目。建议用户根据自身情况（如商业目标、研 发实力等）适当地修改本规范，然后推广使用。 11.1 介绍 系统设计过程域分为两个阶段：高层设计阶段和详细设计阶段。 高层设计阶段的重点是软件系统的体系结构设计。详细设计阶段的重点是用户界面设 计、数据库设计和模块设计，如图11-1所示。 图11-1 系统设计过程域示意图 系统设计过程域产生的主要文档有： ← 《体系结构设计报告》，模板见 [SPP-TEMP-SD-ARCHITECTURE]。 ← 《用户界面设计报告》，模板见 [SPP-TEMP-SD-UI]。 ← 《数据库设计报告》，模板见 [SPP-TEMP-SD-DATABASE]。 ← 《模块设计报告》，模板见 [SPP-TEMP-SD-MODULE]。 11.2 体系结构设计 11.2.1 目的 o 分析与设计软件的体系结构。通过系统分解，确定子系统的功能和子系统之间的关系， 以及模块的功能和模块之间的关系，产生《体系结构设计报告》。 11.2.2 角色与职责 o 项目经理指定若干名开发人员从事体系结构设计（以下称为体系结构设计人员）。 11.2.3 启动准则 o 体系结构设计人员已经确定。 11.2.4 输入 o 需求文档如《产品需求规格说明书》 11.2.5 主要步骤 体系结构设计流程如图11-2所示。 图11-2 体系结构设计流程 [Step1] 设计准备 o 项目经理或者技术负责人分配系统设计任务，包括体系结构设计、模块设计、用户界面 设计、数据库设计等。本活动可能产生一份阶段性的开发计划，如《系统设计计划》， 视工作量而定。 o 体系结构设计人员阅读需求文档，明确设计任务。 o 体系结构设计人员准备相关的设计工具（如Rational Rose）和资料。 [Step2] 确定影响系统设计的约束因素 o 需求约束。体系结构设计人员从需求文档如《软件需求规格说明书》中提取需求约束，例 如： ← 本系统应当遵循的标准或规范 ← 软件、硬件环境（包括运行环境和开发环境）的约束 ← 接口/协议的约束 ← 用户界面的约束 ← 软件质量的约束，如正确性、健壮性、可靠性、效率（性能）、易用性、清晰性 、安全性、可扩展性、兼容性、可移植性等等。 o 隐含约束。有一些假设或依赖并没有在需求文档中明确指出，但可能会对系统设计产生 影响，设计人员应当尽可能地在此处说明。例如对用户教育程度、计算机技能的一些 假设或依赖，对支撑本系统的软件硬件的假设或依赖等。 [Step3] 确定设计策略 o 体系结构设计人员根据产品的需求与发展战略，确定设计策略（Design Strategy）。例如： ← 扩展策略。说明为了方便本系统在将来扩展功能，现在有什么措施。 ← 复用策略。说明本系统在当前以及将来的复用策略。 ← 折衷策略。说明当两个目标难以同时优化时如何折衷，例如“时－空”效率折衷， 复杂性与实用性折衷。 [Step4] 系统分解与设计 o 体系结构设计人员： ← 将系统分解为若干子系统，确定每个子系统的功能以及子系统之间的关系。 ← 将子系统分解为若干模块，确定每个模块的功能以及模块之间的关系。 ← 确定系统开发、测试、运行所需的软硬件环境。 [Step5] 撰写体系结构设计文档 o 体系结构设计人员根据指定的模板撰写《体系结构设计报告》，主要内容包括： ← 软件系统概述 ← 影响设计的约束因素 ← 设计策略 ← 系统总体结构 ← 子系统的结构与模块功能 ← 开发、测试、运行所需的软硬件环境 [Step6] 体系结构设计评审 o 体系结构设计人员邀请同行专家、开发人员对体系结构进行正式技术评审，评审流程请 参考 [SPP-PROC-TR-FTR]。 o 体系结构评审的重点不是“对还是错”，而是“好还是差”。主要评审要素包括： ← 合适性。考察该体系结构是否适合于产品需求，是否可在预定计划内实现。 ← 系统的综合能力（Capability）。例如“时－空”效率（性能，容量等），可扩展 性，可管理性（可维护性），可复用性，安全性等等，视产品特征而定。 [后续活动] o 体系结构设计完成后进入详细设计阶段（用户界面设计、数据库设计、模块设计等）。 11.2.6 输出 o 《体系结构设计报告》 11.2.7 结束准则 o 《体系结构设计报告》已经完成，并且通过了技术评审。 11.2.8 度量 o 体系结构设计人员统计工作量以及文档的规模，汇报给项目经理。 11.3 用户界面设计 11.3.1 目的 o 设计软件的用户界面，产生《用户界面设计报告》。 o 制作用户界面的资源如图像、图标或者界面专用组件等。 11.3.2 角色与职责 o 项目经理指定若干名开发人员从事用户界面设计（以下称为界面设计人员）。 o 如果可能的话，邀请用户或美工人员协助设计用户界面。 11.3.3 启动准则 o 需求文档已经完成。 o 体系结构设计已经完成。 11.3.4 输入 o 需求文档 o 体系结构设计文档 11.3.5 主要步骤 用户界面设计流程如图11-3所示。 图11-3 体系结构设计流程 [Step1] 设计准备 o 界面设计人员阅读需求文档和体系结构设计文档，明确界面设计任务。 o 界面设计人员与用户交流，了解用户的工作习惯和他们对界面的看法。 o 界面设计人员准备相关的设计工具和资料，收集或创作基本的界面资源如图像、图标以 及通用的组件。 o 界面设计人员确定本软件的用户界面设计规则（或指南），主要包括： ← 优秀界面的特征或通用的设计原则； ← 软件主界面（如主窗口、主页面）的设计规则； ← 软件子界面（如子窗口、子页面）的设计规则； ← 标准控件的使用规则； ← 美学设计规则。 [Step2] 用户界面设计 用户界面设计一般要经历“原型创作—>原型评估－>细化”等步骤，通常迭代进行。 o [Step2.1] 原型创作 界面设计人员创作界面原型： ← 先徒手画，或者用Visio 等工具绘制界面的视图； ← 再用软件开发工具实现可以运行的原型。 o [Step2.2] 原型评估 ← 界面设计人员邀请用户和同行们评估界面的原型，汇集意见，及时改进。 o [Step2.3] 细化 ← 界面设计人员细化界面原型，例如美工处理，添加细节等。 补充说明：开发人员在本阶段不必关心界面原型的代码质量，因为界面原型可能不断地 被修改甚至被抛弃。 [Step3] 撰写用户界面设计文档 o 用户界面定型之后，界面设计人员根据指定的模板撰写《用户界面设计报告》，主要内容 包括： ← 应当遵循的界面设计规范； ← 界面的关系图和工作流程图； ← 主界面的视图、功能说明、操作方式； ← 子界面的视图、功能说明、操作方式； ← 美学设计说明。 [Step4] 用户界面设计评审 o 界面设计人员邀请用户和同行们对定型后的界面进行正式技术评审，尽最大努力使界面 变得更加美观、易用。评审流程请参考 [SPP-PROC-TR-FTR]。 o 用户界面的主要评审要素包括： ← 合适性 ← 简洁易用 ← 一致性 ← 美观 ← 动态反馈 ← 功能屏蔽和出错处理 ← 用户控制 ← 国际化（兼容性和可移植性） ← 适应性（针对各种用户） [后续活动] o 在系统设计工作结束之后，开发人员编写界面的代码，并和用户一起通过各种途径测试 界面，从而不断地完善用户界面。（请参考有关测试的文档） o 界面设计人员总结经验教训，不断地完善适用于本机构的“用户界面设计指南”。 11.3.6 输出 o 《用户界面设计报告》 11.3.7 结束准则 o 《用户界面设计报告》已经完成，界面原型已经通过评审。 11.3.8 度量 o 界面设计人员统计工作量以及文档的规模，汇报给项目经理。 11.4 数据库设计 11.4.1 目的 o 设计软件的数据库，产生《数据库设计报告》。 11.4.2 角色与职责 o 项目经理指定若干名开发人员从事数据库设计（以下称为数据库设计人员）。 11.4.3 启动准则 o 需求文档已经完成。 o 体系结构设计已经完成。 11.4.4 输入 o 需求文档 o 体系结构设计文档 11.4.5 主要步骤 数据库设计流程如图11-4所示。 图11-4 数据库设计流程 [Step1] 设计准备 o 数据库设计人员阅读需求文档和体系结构设计文档，明确数据库设计任务。 o 数据库设计人员准备相关的设计工具和资料。 o 数据库设计人员确定本软件的数据库设计规则（或指南），主要包括： ← 数据库命名规则 ← 逻辑设计规则（或指南） ← 物理设计规则（或指南） ← 安全性设计规则（或指南） ← 优化规则（或指南） ← 数据库管理与维护规则（或指南） [Step2] 数据库设计 数据库设计一般要经历“逻辑设计—>物理设计－>安全性设计－>优化”等步骤，通常要迭 代进行。 o [Step2.1] 逻辑设计 ← 数据库设计人员根据需求文档，创建与数据库相关的那部分实体关系图（ERD）。 如果采用面向对象方法（OOAD），这里实体相当于类（class）。 o [Step2.2] 物理设计 ← 设计表结构。一般地，实体对应于表，实体的属性对应于表的列，实体之间的关 系成为表的约束。逻辑设计中的实体大部分可以转换成物理设计中的表，但是它 们并不一定是一一对应的。数据库表的参考格式如表11-1所示。 ← 对表结构进行规范化处理（第三范式）。 |表名 | | |功能说明 | | |列名 |数据类型（精度范围|空/非空 |约束条件 | | |） | | | | | | | | | | | | | | | | | | |补充说明 | | 表11-1 数据库表的参考格式 o [Step2.3] 安全性设计 提高软件系统的安全性应当从“管理”和“设计”两方面着手。这里仅考虑数据库的安全 性设计。 ← 用户只能用帐号登陆到应用软件，通过应用软件访问数据库，而没有其它途径可 以操作数据库。 ← 对用户帐号的密码进行加密处理，确保在任何地方都不会出现密码的明文。 ← 确定每个角色对数据库表的操作权限，如创建、检索、更新、删除等。每个角色 拥有刚好能够完成任务的权限，不多也不少。在应用时再为用户分配角色，则每 个用户的权限等于他所兼角色的权限之和。 o [Step2.4] 优化 分析并优化数据库的“时－空”效率，尽可能地“提高处理速度”并且“降低数据占用的 空间”。 ← 分析“时－空”效率的瓶颈，找出优化对象（目标），并确定优先级。 ← 当优化对象（目标）之间存在对抗时，给出折衷方案。 ←...
第11章 系统设计