常规应用系统设计要点（转贴）...

1. 前言 系统设计就是程序人员把用户的需求设计成系统可以明白的任务描述，使程序人员编写出相应的计算机系统。 本文从个人经验上讲述一下系统设计中的要点及注意事项。 系统设计有四个重点分别是：体系设计、功能模块设计、数据库及算法设计和界面设计。 以下就针对这四个重点分别进行讲述。 2. 体系设计 体系设计一般是明确用户的需求，经过调研分析后进行最终决定的，但现在很多体系设计是采用在社会上广泛的公布需求（以标书的形式），由开发商拟定竟相投标的，正式中标后，再进行认定形式的调研分析。这种情况下，开发商要特别注意的是：在投标时就要根据其标书的内容及性质明确其系统的设计体系及技术类型。 2.1. 系统体系 2.1.1. 选取体系 根据用户的需求我们要选取一种合适的系统体系，一种适用的系统体系决定了系统的框架，对于用户来讲：如何具体实现是并不关心的，用户关心的只是使用的方便及其实用，但对于系统设计人员及程序人员来说，却要知道系统到底是什么样的系统，所以系统的选取是系统设计第一步。 体系的选取的有如下几点关键问题： 1. 是单机还是客户机/服务器系统？ 2. 是常规应用开发还是底层开发（是否有单片机系统）？ 3. 客户机最大点数是多少？ 4. 是否提供给第三方API接口？ 5. 网络（或数据通信）是什么连接方式？ 6. 客户机是胖客机还是瘦客户机？ 7. 数据文件的保存方式（文本、本地数据库、大型数据库）？ 我们必须针对以上的问题来进行具体的描述，以下是常有体系描述： 2.1.2. 常用系统体系 2.1.2.1. 层次体系 所谓层次的慨念就是一层一层分割一目了然的处理方式。层次体系就是利用分层的方式来处理复杂的功能，层次系统要求上层子系统可以使用下层子系统的功能，而下层子系统不能够使用上层子系统的功能。一般下层每个程序接口执行当前的一个简单的功能，而上层通过调用不同的下层程序，并按不同的顺序来执行这些下层程序，层次体系就是以这种方式来完成多个复杂的业务功能的。 这种层次结构的典型就是计算机网络的OSI参考模型，如图所示：

又比如某一系统为了快速开发程序界面，界面编写语言是Microsoft Visual Basic 6.0 中文版，而为了实现某些特定的功能又采用了Microsoft Visual C++ 6.0编写COM，调用SDK进行具体实现，这种方式就是层次体系的结构。 层次体系结构多应用单机系统。 2.1.2.2. 客户机/服务器结构 客户机/服务器结构简称C/S结构，由服务器提供应用（数据）服务，多台客户机进行连接。如下图所示：

客户/服务器应用模式的特点是大都基于“肥客户机”结构下的两层结构应用软件。客户端软件一般由应用程序及相应的数据库连接程序组成。服务器端软件一般是某种数据库系统。 当前的实际应用中多数服务器就是一台数据库服务器（如DB2数据库），而客户端就是用Microsoft Visual Basic 6.0编写的客户软件，通过ODBC或ADO同数据库服务器通信。组成一个应用系统。 客户/服务器应用模式的缺点是系统客户方软件安装维护困难、数据库系统的无法满足对于成百上千的终端同时联机的需求、由于客户/服务器间的大量数据通信不适合远程连接，使其只能适合于局域网应用。 2.1.2.3. 浏览器/服务器结构 在当前Internet/Intranet领域，目前“浏览器/服务器” 结构是当前非常流行的客户机/服务器结构，简称B/S结构。如下图所示。

这种结构最大的优点是：客户机统一采用浏览器，这不仅让用户使用方便，而且使得客户机不存在及安装维护的问题。当然软件开发布和维护的工作不是自动消失了，而是转移到了Web 服务器端。在Web 服务器端，程序员使用脚本语言编写响应页面。 当前主要的浏览器是 Netscape Navigator和Internet Explorer，Internet Explorer和windows捆绑销售，而Netscape Navigator是可以免费下载的。国内大部分客户机基于Internet Explorer，而服务器使用ASP、JSP或PHP编写。 客户机同WEB服务器之间的通信采用HTTP协议，由于HTTP协议是一种无连接的协议，通信原理如下：浏览器只有在接受到请求后才和WEB服务器进行连接，WEB服务器马上与数据库通信并取得结果，WEB服务器再把数据库返回的结果转发给浏览器，浏览器接收到返回信息后马上断开连接。由于正真的连接时间很短，这样WEB服务器可以共享系统资源，为更多用户提供服务，达到可以支持几千、几万甚至于更多用户的能力。 2.1.2.4. 三层次客户机/服务器结构 三层次客户机/服务器结构是在常规客户机/服务器结构上提出的，系统在客户机和数据库服务器间添加一个应用服务器。

应用服务器分为下两类： 1） 基于中间件的应用服务器。代表为IBM的cics和BEA 的tuxedo。 2） 基于WEB的应用服务器。代表为IBM的WebSphere和BEA的weblogic 基本原理类似于B/S结构。 2.2. 技术选型 明确系统体系后就要明确期技术选型，技术选型要从可以实现的系统体系和用户软件的购买能力上来综合进行考虑/ 一般技术选型要明确以下信息 主要硬件环境，如：数据库服务器和应用服务器采用IBM的RS/6000系列的S85。 操作系统，如：数据库服务器和应用服务器采用IBM的AIX，客户机采用WIN2000。 应用系统内的各种服务器软件，如：应用服务器采用Web Sphere，数据库服务器采用DB2。 开发语言及开发工具，如：开发语言是Microsoft Visual C++ 6.0. CASE（计算机辅助设计）软件，如：Power Designer，Visio 通过以上信息开发人员可以明确使用什么方法什么工具来完成某任务，也为开发人员的选择提供了依据。 3. 功能模块设计 功能模块设计的流程是先完成处理流程图（分析过程），再生成功能模块结构图（设计过程），再根据功能模块结构图细化功能模块。 3.1. 处理流程图的画法 为了表示业务的处理流程，可以由以下符号来表示：

具体例子如下（摘自《系统分析员车间》站点）： 3.2. 侧重点不同的框架图 功能模块的框图架的画法相对简单，要求遵循高内聚低藕合的原则，但由于个人的考虑问题的角度不同，会产生以下两种类型的的框架图：

从模块流程考虑划分 完全模块角度的划分 功能模块划分中一般存在这种现象，说不好那个最好，因侧重点不同。完全模块角度明确了系统内部的关系。但不能表明实际的调用关系，使界面设计人员错误理解界面调用关系；后者明确了实际的调用关系，但程序员可能会误解模块上下级关系。 为了不同的对象（界面设计人员和程序员）了解关系，推荐两个图都要画出，对于界面设计使用从模块流程划分的框架图，而程序人员使用完全模块角度划分的框架图。

3.3. 功能模块结构图（框架图）的现实应用 功能模块结构图是为了表明程序的结构，分树状结构和网状结构两种。从实现的应用情况下看，在保证模块独立性的前提下，先按树状结构进行分析划分。在树状结构已经表示明确关系的基础上进行优化，提取出公用模块，形成网状结构。 对于软件实际开发的情况下尽量不要先进行公用模块的划分，而是应从树状图中抽取。（当然需求时已经很明确的公用模块不在本范畴）。不然公共模块的变化会影响很多相关模块。 功能模块结构图理认上是用于模块化（相于C中的函数）划分的。如果回到C时代，划分的问题会少一些，但现在实际编码大部分所用是面向过程和面向对象的混合编程，这时就有很多问题。 当前的最低层模块的划分有两种情况 l 面向过程最低层模块只有一个接口（函数）程序 l 面向对象最低层模块（组件）有多个接口（方法和属性）程序 结果由于不同的人的个人实际分析方法不同，结果会产生不同的划分方法。在实际工作中要明确是划分到一个接口函数（方法），还是到功能模块（组件）。 无论怎样，一个最低层模块要明确其模块标识符（函数或组件名称），功能描述，输入，输出，内部算法等信息。 3.4. 功能模块细化 明确系统框架图，就要以进行程序功能模块的细化了，细化过程中首先要明确以下的问题。 3.4.1. 模块运行所在的程序说明 3.4.1.1. 程序的总体功能 说明程序要具体实际的功能及目的。 3.4.1.2. 程序的运行的前提条件 硬件要求：如：PII400以上CPU， 128M以上内存， 500M以上硬盘空间，100M以上网卡，键盘必须，鼠标必须，显示卡支持1024X7687 软件要求：如：中文操作系统WINDOWS 2000，安装TCP/IP协议，安装ORACEL ODBC、ACCESS ODBC。 3.4.1.3. 外部引用系统及公用模块的引用 说明本系统对于外部组件（不属开发工具标配）、公用模块的引用。如第三方加密组件，打印控件等的说明。 3.4.1.4. 全局变量定义 系统全部变量（可以是组件类型）定义 3.4.1.5. 程序初始化 明确算法，最好是写出相应源码 3.4.1.6. 程序关闭 明确算法，最好是写出相应源码 3.5. 功能模块描述 对于各个功能模块的描述可以从以下方面进行。 注意：对于组件设计，可以认为一个功能模块是一个组件，而接口程序是其组件的“方法”。 功能说明：给出对该程序的简要描述，主要说明安排设计本程序的目的意义。 性能：说明对该程序的全部性能要求，包括对精度、灵活性和时间特性的要求。 流程逻辑：用图表（例如流程图、判定表等）辅以必要的说明来表示本功能模块的逻辑流程。 模块代码：功能模块在框架图中的代号或名称 3.5.1.1. 接口程序描述接口程序 一般情况下功能模块是逻辑功能整体，进行具体编码由接口程序（函数、存储过程、方法等）进行具体实现。 一个功能模块一般有最少一个或多个接口程序，所以每个功能模块下有最少一个或多个接口程序描述，而多个接口程序的关系通过功能模块中的流程逻辑进行说明。 一般接口程序通过以下几点进行说明： 接口代码：函数、存储过程、方法等的名称 接口功能说明： 说明本接口程序的功能 接口输入参数：给出对每一个输入项的特性，包括名称、标识、数据的类型和格式、数据值的有效范围、输入的方式。 接口返回数据：给出对每一个输出项的特性，包括名称、标识、数据的类型和格式，数据值的有效范围，输出的形式。 实际实现定义：进行实际实现函数（接口、方法）定义，可以在具体编码时定义的更标准 例： function FunThisTest(UserName as String,Year as int) as String 算法：详细说明本程序所选用的算法原理，具体的计算公式，数据库操作和计算步骤等。 其他额外要求：根据需要，说明本接口程序的额外要还求。 4. 数据库及算法设计 4.1. 数据库设计过程 当前越来越多的系统涉及到了数据库，那么数据库设计也变成其中必需的一部分。 数据库的设计是一般是通过实际联系表示法简称E-R方法(Entity-Relationship Approach)来表明其逻辑，具体也就是通过所谓的ER图来表示实体及其联系；再通过ER图生成具体的数据模式（物理数据库）。 具体有代表性的case工具有Power Designer，它具在逻辑设计模式下设计完成具有实体、实体属性、实体联系、域等信息的ER图后，直接生成其目标数据模式（物理数据库）及相应的SQL语句(Visio 2000有类似的功能但没有Power Designer强大)的功能。 4.2. 数据库设计中的问题 4.2.1. 通过评审的方式明确实体及关系 由于CASE工具的辅助，实体关系图可以说就是关系数据库设计。在多人共同设计的情况下，实体关系是非常关键的问题。一般情况在进行模块设计前，首先要明确实体及关系，对于实体的属性等可以在完成模块设计后再添加。明确实体及关系使用SA（或专家）人员集体评审的方式进行，第一是保证实体关系正确性，第二是通过评审使相应的SA清楚了解进行功能模块设计时的实体依据。 4.2.2. 数据库设计先开工后收工 对于数据库设计来说有时在需求阶段时，由于用户某些特定的需求，就需要进行额外的数据库设计考虑。在设计阶段的数据库设计中的实体关系设计一般也要早在模块设计和界面设计前，所以一般数据库设计是比功能模块设计先开始的设计。 在进行模块设计及界面设计过程全部有可能会产生使用内部数据的要求，那么就要更改或添加相应的数据库设计，只有模块及界面设计完毕后，才能保证数据库设计真正结束。 4.2.3. 约束关系的强、弱度要适度 对于数据库设计中的实体（表）关系、主键定义及属性中值的域范围，要着重分析。理论上是越严格越好，但实际的数据库设计中要考虑一定的可扩展性、性能及实用性。因为数据库设计不是做数学论证，而是做应用。 4.2.4. 数据库程序设计是功能模块的一部分 数据库中存储过程、触发器、序列（ORACEL中的特性）等是相当于功能模块设计的一部分，而不是数据库设计。 4.3. 关于算法 设计者应该充分地了解一些常用的数据结构与算法，避免不必要的重复设计工作。在一般的应用程序中来讲不会用什么创新的算法，大量合理复用才是真正的解决之道。应用系统开发是有资源和时间的限制的，不能为了一小部分的创新而丢失大部分任务。 4.4. Power Designer简单使用方法 下面额外讲一下Power Designer的使用方法 1、首先设计完毕Power Designer中的ER图

2、通过菜单tools中的Generate new Physical Date Model

3、生成相应的数据模式（物理数据库） 4、再通过菜单Database中的Database Generation 生成相应的脚本crebas.sql 5、在DB2通过执行crebas.sql就可以生成相应的物理数据库结构 5. 界面设计

5.1. 明确界面的风格

首先要明确系统界面的风格，最好的方式是先做一个系统原型由用户审核，明确界面色调、每个位置文字的字体和字号，窗口是有模还是无模，屏幕是1024X768 24位色还是其他。这部分最好在需求调研时就明确，如果需求调研没有明确，那么进行界面设计时先做几屏，由用户进行签字确认，确认后再向下做。不然如果界面全部做完，再改字体、字号和色调工作量是很大的。

5.2. 根据流程图及功能框架图完成界面

界面设计的风格、色调一般是由专业的美工或UI明确完成，而以下内容要求设计人员完成 5.2.1. 窗体层次图及窗体列表 在完成功能模块设计后，就要进行具体的界面设计了。进行界面设计首先要完成窗体层次图，用来表示功能模块在程序界面中的层次关系，功能模块的关系和窗体关系有时是相同的，但大部分还是有部分差别的，所以要额外进行窗体层次图的划分。 注意：如果是用原型法，那就是界面设计在前，功能模块设计在后了，本文讲述一般情况下的设计过程。 在窗口中有时会把多个模块放在一个窗体中完成，或者多个窗口调用一个共用模块（如：出错信息处理，连接HELP系统），一般要在注解中进行说明 例：以下是窗体层次图

注：1.3 出错信息处理在1.2.2/1.2.1/1.2.2.1/1.2.2.2/1.1.1被调用，而下面模块层次图

注：4出错信息处理在所用的模块中的调用返回将使用到上可以看出模块层次图和窗体层次还是有一定的区别的。通过层次图再生成窗体列表 例： 窗体名称（Caption） 窗体代码 窗体层次编号 窗体类型（MIDChild） 说明 名片管理系统 FrmMain MDI窗体 最顶级窗口 用户登录 FrmLogin 1 子窗体 名片管理 FrmCardManager 1,2 子窗体 …………… 5.2.2. 窗体设计 完成窗体列表后再明确每个窗体内地控件，事件及属性，将要完成什么功能及调用那些功能模块。注意功能模块的输入输出和界面的输入输出是有所不同的。

5.2.3. 完成界面设计 使用对应的编程工具(如：VB)将界面“画”出来，完成界面设计对于用户和程序员来讲他们看到了系统的样子，后面事情就是完成相应的功能模块及调用代码，使系统真正的跑起来。完成界面设计也可以使用户明确他需求的东西和设计出来的东西是否相同有无偏差，以便提早发现问题进行更正。 6. 其他 6.1. 应用系统运行环境要求 硬件要求：如：PIII500以上CPU， 128M以上内存， 500M以上硬盘空间，100M网卡，键盘必须，鼠标必须，显示卡支持1024X768及24位色。 软件要求：中文操作系统WINDOWS 2000，DB2 客户端，安装TCP/IP协议。 6.2. 代码表 代码表的信息一般是在数据库设计中属性值的域范围中进行体现。 如果一个银行账户的状态分正常、挂失、冻结三种情况，那么数据库设计中可以设计一个状态字段，类型为数字型，用0表示正常、1为挂失、2为冻结。 那么这些信息要以代码表或在数据库中用域值的形式表现出来。 6.3. 出错信息表 对于有大量出错信息情况推荐使用出错信息表的方式，系统返回“返回代码”由专用的处错处理模块处理。 例：XXX系统信息表

6.4. 系统性能保障措施 系统还应分别考虑以下问题 可靠性 系统安全 易使用性 （如：界面的输入框明确是否必须，及提示输入值的范围） 高效性 可维护性 可移植性。