工作文件
文件名称：软件设计规范
文件编号：版号：A
编制：日期：
审核：日期：
批准：日期：
受控状态：
生效日期：
分发号：
1目的
本规范是对项目软件设计的一份规范性文件，对软件设计过程中的活动进行总体规范，以有效保证软件产品的质量。
2范围
本规范适用于公司研制的全部软件产品。
3设计流程
软件设计流程按照《软件设计和开发控制程序》中规定执行，软件开发过程可包括以下活动：
a)需求分析；
b)软件开发；
c)软件测试；
d)项目验收；
e)客服支持。
4前期准备
软件开发人员对系统开发前期进行充分的用户调研、需求分析和系统体系结构的设计准备工作。软件开发人员以及业务需求人员共同组建项目组，一名或两名项目经理负责监控项目的整体实施，共同参与系统的全面设计、开发，并针对业务提出进一步开发需求，开展软件用户化工作，制定二次开发方案，参与设计业务系统与其它软件的接口。5实施过程
整个开发过程将经历获取需求、需求分析、系统设计、编码、测试等阶段。
5.1 获取需求
软件在进入正式开发之前，提供准确的书面《需求规格说明书》其中包括：
a)对现有系统的分析。
b)待开发系统的详细需求。
c)功能需求，使用范围，业务流程，用户界面，输出要求，故障处理。
d)网络环境，硬件环境，软件环境，与其他系统的关系，安全与保密。
e)技术可行性分析，经济可行性分析，人员可行性分析，影响待开发系统的主要
因素。
软件项目分为专用软件和通用软件两大类。
对于专用软件，在进入开发之前必须与用户进行比较具体的交流和讨论，了解清楚用户理想的产品究竟是什么样子，这里最好就采用原型化的方法作出一个简单的框架给用户看。
对于通用软件，在开发之前必须做一定的市场调查工作，一方面是从经济效益考虑，调查产品的潜在市场有多大，一方面是从技术的角度，了解清楚潜在用户对软件的各种技术上的要求，另一方面是确定软件的定位，即我们软件具体是为哪一些用户群体服务的。然后对该群体用户现有硬件配置，软件配置，网络使用情况，数据库使用情况，计算机熟悉程度做一定的调研，根据调查的统计结果决定即将开发的软件的一些技术指标。
5.2 需求分析
开发人员构思、确立系统目标、划分业务领域、现行业务分析、建立业务模型、信息需求分析、用户视图规范化、数据元素标准化与一致性控制等。
在项目组和用户充分交互、理解的基础上，提出系统的技术构架，对系统功能、性能等主要指标作描述，对实现方法项目实施人员应有一个比较清晰的轮廓及整体设计思路，对有疑问的地方及时与业务需求人员进行沟通交流，最终达成共识。
综合对该用户群体现有硬件配置，软件配置，网络使用情况，数据库使用情况，计算机熟悉程度做一定的调研，根据调查的统计结果决定即将开发的一些软件适用指标。这个阶段需要出三样东西，用户视图，数据词典和用户操作手册。
用户视图是该软件用户（包括终端用户和管理用户）所能看到的页面样式，这里面包含了很多操作方面的流程和条件。
数据词典是指明数据逻辑关系并加以整理，完成了数据词典，数据库的设计就完成了一半多。
用户操作手册是指明了操作流程的说明书。
5.3 软件开发
5.3.1系统结构建立
确定软件服务器的硬件配置及用户硬件资源配置。
确定用户软件平台的统一协调。
5.3.2软件设计
软件设计阶段的工作包括对模块进行必要的修改，同时可能需要对某些结构做一些修改，确定界面定义、用户服务层、业务逻辑层、数据库服务层和具体数据库，确定软件开发工具。这一阶段还将完成更详细的功能和业务需求调研，制作系统中最符合用户需要的文档。
根据应用系统对安全的要求，同步进行安全保密设计。
5.3.3软件编码
确定软件的界面风格、使用功能、编程语言、数据库结构和具体数据等工作，并开始进入程序编写阶段。
开发人员进入设置和编码工作之后，应先确定编码的风格在开发过程中保持一致，工作过程中如发现前面分析或设计阶段的某些错误，应返回到前面的阶段进行必要的修改，同时主要开发人员之间应相互紧密配合。编码语言除用户特别要求外应尽量使用常用语言，详细语言编码规范参考《C++编码规范》（附件A）和《C#编码规范》（附件B）。
5.3.3.1代码规范
有些不易理解的变量或函数应作注释，难懂的代码要有注解，在文件的开始处有该文件的用途描述。一定要保持注释的一致性。
代码组织要清晰，{,},(,),if,else,do,while,for,case等要对应整齐，少用空格，缩进全部用Tab键。变量的定义要集中，函数间要有空行分开，一个程序中的空行数目最好占8%-16%。多态函数和功能相近的函数集中放在一起。
代码应该简洁、清楚并讲述了所发生的一切。某些公用代码要注意多平台易移植，最好使用标准C。
代码的重用要仔细，要将相关的代码也拷贝过来，注意那段代码是否适合需求的应用场合。
删掉从来没有用过的函数或变量，大篇幅注释掉的代码行也应删除，以免使程序混乱难读。
5.3.3.2工程文件组织规范
一个工程往往包含很多很多文件（*.h,*.cpp,*.inc,*.lib,资源文件等），向工程中加入文件或删除工程中的文件要慎重，避免把工程损坏。工程中不起作用的文件或类应删除，工程目录下的非工程文件也应该移走，保持工程的清洁，避免混淆难于管理。工程文件如果很多，应归类。
在VC环境下，建议将常用的头文件全部放入stdafx.h中，而在每个cpp开始处嵌入stdafx.h。避免头文件的交叉引用，如果有严重的交叉引用，适当使用类的声明。
将独立性比较强的模块抽出来，做成DLL，控件或COM组件，该模块可单独编写和测试，也增强了其可重用性。
一个比较大的工程应留有一定的消息接口或插件接口等。
工程的版本控制要严格，版本格式为xx.xx.xx，必要时使用Build次数或日期。高版本尽量兼容低版本的用法、数据或协议。
工程的编译宏定义和工程参数设置应正确，每作一个新工程时应检查工程参数是否正确。
建议字节对齐方式为1字节对齐。
工程文件应经常备份，备份时注明备份日期和主要增加的功能。
5.3.3.3类组织规范
类一般有两个文件，一个头文件，一个实现体CPP。
类力求封装好，严格区分public,private,protect等作用域，如果一个函数与本类有莫大的关系，可以作为该类的静态成员函数，不用或少用友元函数等破坏类封装性的方法和技巧。如果一些结构或宏仅与本类有关，可在类头文件中定义。
类的成员变量在构造函数或初始化函数中应赋初值。指针在构造函数中赋NULL,析构时DEL_EMPTY它，以免内存泄露。
5.3.3.4用户界面规范
有四大类型的用户界面：对话框、单文档界面、多文档界面、其它界面。
对话框要易用且简洁，字体和控件的组织搭配要得体，能简单不复杂，各控件的焦点、Tab顺序等要讲究，视应用场合要适当支持键盘。在简洁易用的前提下，力求个性
化，设计得更加友好。程序各对话框的风格要保持一致。
单文档和多文档界面的程序功能强，也便于扩充和管理。其中菜单、工具栏、状态栏等设计要有特色。菜单按一定的分类弹出，必要时设计成多套菜单，在重要的窗口或区域应能弹出右键，实现常见操作。工具栏上放最常用的操作按钮，必要时动态更换按钮。状态栏显示足够多的有用信息。
消息主控在Mainframe中，单文档的主控也可在View中，所有的对话框的弹出或非模态对话框的控制都在主控窗口中完成，具体的数据处理放在单独的文件中或设计成类。在App类中实现Ini读写，各数据对象的定义和析构，全局变量的赋值和初始计算，存盘退出等。各视图的OnDraw和GDI画图尽量使用内存位图的方式，以免闪烁。
其它还有ATL，控制台，嵌入式程序界面等，也有作为其它容器如IE中的插件等，此类程序可能不用MFC，而采用COM组件等方法实现。
5.4 软件测试
测试时系统投入使用前最关键的一个步骤，由开发人员之间、业务需求人员交叉测试或由软件测试工程师测试。开发人员将对在测试过程中发现的问题提出可行建议进行改进。测试方法、测试类型及测试结果判断规范参考《软件测试规范》。
5.5 项目验收
建设工程包括多个方面的工作和任务，每一项任务的完成、每一个文档的提交、每一个设备、软件或应用系统的交付，都有相应的完成标志和测试、评估和验收标准。对于系统、网络和应用这种重大的工作里程碑事件，测试验收工作更为严谨和充分，计划更为周密。
按照系统集成服务的程序和行业惯例，整个项目实施过程中要对不同的交付项目进行如下各类测试和验收中的一种或几种，具体进行哪种或哪些测试验收工作依交付项目的性质不同而不同。
5.5.1审议确认
这是一种采用对交付件内容进行阅读、讲解、评议、问题与回答的形式进行评审，并作出接受或拒绝决定的方法。对于交付的项目管理文档、设计文档、测试报告、技术资料等交付项目，通常采用这种方法。
5.5.2安装测试
采用标准的测试程序(如硬件设备开机自检)和操作方法，对交付件进行测试的方法。通常用于对硬件设备和系统软件的验收。
5.5.3初始安装测试
类似于安装测试，通常用于对最终提交结果进行安装测试。典型的情况是系统软件的初始安装测试，此时安装的是用于进行设计开发的平台或工具，而不是直接提交客户作生产目的。
5.5.4用户验收测试
用户验收测试是用户根据自己的业务处理要求，在实际系统上进行的类似于系统集成测试的过程。这种测试的目的是检验交付系统是否达到设计要求，是否可以投入业务运行。与系统集成测试的不同在于，用户验收测试更加着重从业务功能方面的测试，时间也相对短。
验收测试计划确立了对系统进行测试验收的方式和标准。公司将指导用户制订验收测试计划(在验收测试开始前两周)。
测试计划将包括：
a)测试目标
b)角色和职责
c)测试环境
d)要测试的功能和外观特征
e)测试手段
f)测试案例及预期结果
当所有功能和外观特征经测试达到验收测试计划所说明的完成标志，客户将接收该系统。在测试过程中，任一项没有达到完成标志，开发商将负责修正然后再进行测试。某些测试失败可能由于对项目实施目标的误解而导致，对这些误解进行分析。如果是开发商的责任，将做必要的修正并再进行测试。
5.5.5人员培训
对用户人员进行技术培训是工程成功的重要因素，是整个项目能否顺利实施的重要
保证。针对设备或软件系统的业务和技术特点及要求，我们将提供必要的技术培训，并可就客户的其它具体要求提供其它方面的培训。
5.5.6资料文档
为保证系统的建设和正常运行，我们可以提供如下设计类、计划类、测试类资料和文档，各项目根据自身情况进行剪切。
a)软件需求规格说明
b)系统设计文档
c)数据库设计文档
d)软件开发计划
e)开发计划
f)软件配置项测试计划
g)测试大纲
h)测试报告
i)验收报告
j)用户手册
5.6 客服支持
5.6.1培训目标
在实施项目的过程中，使相关操作人员理解软件的基本原理和实际运用，使他们对整套业务软件的具体性能，操作步骤以及具体要求，有一个更深层次的认识，并能在计算机管理下对其业务软件流程熟练操作使用。
再开发人员共同接受软件开发方全面、系统的培训，保证能够在后期推广中独挡一面完成推广及软件升级任务。
5.6.2培训计划
项目组有义务对用户提供及时、有效、全面的培训，并在项目实施过程中充分重视对用户方的技术转移，并提前制订有效可行的培训计划。
5.6.3考核标准
以实际操作方式测试用户对软件系统流程的操作使用能力。
附录A C++编码规范
1 文件结构
1.1 文件头注释
所有C++的源文件均必须包含一个规范的文件头，文件头包含了该文件的名称、功能概述、作者、版权和版本历史信息等内容。标准文件头的格式为：
/*! @file
********************************************************************************
模块名: <文件所属的模块名称>
文件名: <文件名>
相关文件: <与此文件相关的其它文件>
文件实现功能: <描述该文件实现的主要功能>
作者: <作者部门和姓名>
版本: <当前版本号>
--------------------------------------------------------------------------------
多线程安全性: <是/否>[，说明]
异常时安全性: <是/否>[，说明]
--------------------------------------------------------------------------------
备注: <其它说明>
--------------------------------------------------------------------------------
修改记录:
日期版本修改人修改内容
YYYY/MM/DD X.Y <作者或修改者名> <修改内容>
*******************************************************************************/ 如果该文件有其它需要说明的地方，还可以专门为此扩展一节，节与节之间用长度为80的“=”带分割：
/*! @file
********************************************************************************
模块名: <文件所属的模块名称>
文件名: <文件名>
相关文件: <与此文件相关的其它文件>
文件实现功能: <描述该文件实现的主要功能>
作者: <作者部门和姓名>
版本: <当前版本号>
--------------------------------------------------------------------------------
多线程安全性: <是/否>[，说明]
异常时安全性: <是/否>[，说明]
--------------------------------------------------------------------------------
备注: <其它说明>
--------------------------------------------------------------------------------
修改记录:
日期版本修改人修改内容
YYYY/MM/DD X.Y <作者或修改者名> <修改内容>
********************************************************************************
* 项目1
- 项目1.1
- 项目1.2
============================================================================ ====
* 项目2
- 项目2.1
- 项目2.2
....
*******************************************************************************/ 每行注释的长度都不应该超过80个半角字符。还要注意缩进和对齐，以利阅读。注意：将多线程和异常时安全性描述放在文件头，而不是类或者函数注释中，是为了体现以下设计思想：同一个模块中的界面，其各方面的操作方式和使用风格应该尽量保持一致。
1.2 头文件
头文件通常由以下几部分组成：
a)文件头注释
每个头文件，无论是内部的还是外部的，都应该由一个规范的文件头注释作为开始。
b)预处理块
为了防止头文件被重复引用，应当用ifndef/define/endif结构产生预处理块。
c)函数和类/结构的声明等
声明模块的接口。
d)需要包含的内联函数定义文件（如果有的话）
如果类中的内联函数较多，或者一个头文件中包含多个类的定义（不推荐），可以将所有内联函数定义放入一个单独的内联函数定义文件中，并在类声明之后用“#include”指令把它包含进来。
头文件的编码规则：
a)引用文件的格式
用#include
用#include "filename.h" 格式来引用当前工程中的头文件（编译器将从该文件所在目录开始搜索）。
b)分割多组接口（如果有的话）
如果在一个头件中定义了多个类或者多组接口（不推荐），为了便于浏览，应该在每个类/每组接口间使用分割带把它们相互分开。
关于头文件的完整例子，请参见：头文件例子
1.3 内联函数定义文件
如上所述，在内联函数较多的情况下，为了避免头文件过长、版面混乱，可以将所有的内联函数定义移到一个单独的文件中去，然后再用#include指令将它包含到类声明的后面。这样的文件称为一个内联函数定义文件。
按照惯例，应该将这个文件命名为“filename.inl”，其中“filename”与相应的头文件和实现文件相同。
内联函数定义文件由以下几部分组成：
a)文件头注释
每内联函数定义文件都应该由一个规范的文件头注释作为开始。
b)内联函数定义
内联函数的实现体。
内联函数定义文件的编码规则：
a)分割多组接口（如果有的话）
如果在一个内联函数定义文件中定义了多个类或者多组接口的内联函数（不推荐），
必须在每个类/每组接口间使用分割带把它们相互分开。
b)文件组成中为什么没有预处理块？
与头文件不同，内联函数定义文件通常不需要定义预处理块，这是因为他们总是被包含在与其相应的头文件预处理块内。
1.4 实现文件
实现文件包含所有数据和代码的实现体。实现文件的格式为：
a)文件头注释
每个实现文件都应该由一个规范的文件头注释作为开始
b)对配套头文件的引用
引用声明了此文件实现的类、函数及数据的头文件
c)对一些仅用于实现的头文件的引用（如果有的话）
将仅与实现相关的接口包含在实现文件里（而不是头文件中）是一个非常好的编程习惯。这样可以有效地屏蔽不应该暴露的实现细节，将实现改变对其它模块的影响降低到最少。
d)程序的实现体
数据和函数的定义
实现文件的编码规则：
分割每个部分：在本地（静态）定义和外部定义间，以及不同接口或不同类的实现之间，应使用分割带相互分开。
1.5 文件的组织结构
由于项目性质、规模上存在着差异，不同项目间的文件组织形式差别很大。但文件、目录组织的基本原则应当是一致的：使外部接口与内部实现尽量分离；尽可能清晰地表达软件的层次结构。
为此提供两组典型项目的文件组织结构范例作为参考：
1.5.1 功能模块/库的文件组织形式
显而易见，编写功能模块和库的主要目的是为其它模块提供一套完成特定功能的API，这类项目的文件组织结构通常如下图所示：
软件设计规范版号/修改状态：A/0
其中：
Contrib：当前项目所依赖的所有第三方软件，可以按类别分设子目录。
Doc：项目文档
Include：声明外部接口的所有头文件和内联定义文件。
Lib：编译好的二进制库文件，可以按编译器、平台分设子目录。
Makefile：用于编译项目的makefile文件和project文件等。可以按编译器、平台分设子目录。
Src：所有实现文件和声明内部接口的头文件、内联定义文件。可按功能划分；支持编译器、平台等类别分设子目录。
Test：存放测试用代码的目录。
1.5.2 应用程序的文件组织形式
与功能模块不同，应用程序是一个交付给最终用于使用的、可以独立运行并提供完整功能的软件产品，它通常不提供编程接口，应用程序的典型文件组织形式如下图所示：
Contrib：当前项目所依赖的所有第三方软件，可以按类别分设子目录。
Doc：项目文档
Makefile：用于编译项目的makefile文件和project文件等。可以按编译器、平台分设子目录。
Setup：安装程序，以及制作安装程序所需要的项目文件和角本。
Src：所有源文件。可按功能划分；支持编译器、平台等类别分设子目录。
Test：存放测试用代码的目录。
2 命名规则
如果想要有效的管理一个稍微复杂一点的体系，针对其中事物的一套统一、带层次结构、清晰明了的命名准则就是必不可少而且非常好用的工具。
活跃在生物学、化学、军队、监狱、黑社会、恐怖组织等各个领域内的大量有识先辈们都曾经无数次地以实际行动证明了以上公理的正确性。除了上帝（设它可以改变世间万物的秩序）以外，相信没人有实力对它不屑一顾。
在软件开发这一高度抽象而且十分复杂的活动中，命名规则的重要性更显得尤为突出。一套定义良好并且完整的、在整个项目中统一使用的命名规范将大大提升源代码的可读性和软件的可维护性。
在引入细节之前，先说明一下命名规范的整体原则：
a)同一性
在编写一个子模块或派生类的时候，要遵循其基类或整体模块的命名风格，保持命名风格在整个模块中的同一性。
b)标识符组成
标识符采用英文单词或其组合，应当直观且可以拼读，可望文知意，用词应当准确。
c)最小化长度&& 最大化信息量原则
在保持一个标识符意思明确的同时，应当尽量缩短其长度。
d)避免过于相似
不要出现仅靠大小写区分的相似的标识符，例如“i”与“I”，“function”与“Function”等等。
e)避免在不同级别的作用域中重名
程序中不要出现名字完全相同的局部变量和全局变量，尽管两者的作用域不同而不会发生语法错误，但容易使人误解。
f)正确命名具有互斥意义的标识符
用正确的反义词组命名具有互斥意义的标识符，如："nMinValue" 和"nMaxValue"，"GetName()" 和"SetName()" ....
g)避免名字中出现数字编号
尽量避免名字中出现数字编号，如Value1,Value2等，除非逻辑上的确需要编号。这是为了防止程序员偷懒，不肯为命名动脑筋而导致产生无意义的名字（因为用数字编号最省事）。
2.1 类/结构
除了异常类等个别情况（不希望被用户看作一个普通的、正常的类之情况）外，C++类/结构的命名应该遵循以下准则：
a)C++类/结构的命名
类的名称都要以大写字母“C”开头，后跟一个或多个单词。为便于界定，每个单词的首字母要大写。
特别地，由于界面与其它类概念上的巨大差别，规定界面类要以大写字母“I”开头。界面类描述一个服务（一组被命名的操作集合），在C＋＋中，界面与其它类间的最大区别在于，界面类中不包含任何数据结构（属性），也不包括任何具体的操作和实现，界面类通常仅包含一组纯虚函数的声明而不包含任何实现和数据。在一些其它语言中，一个界面也被称作一个接口及其实现契约。
另一个与接口相似的概念是类型，类型与接口的不同点在于，类型可以包含部分接口的实现或包含一些接口默认的或不完整的实现，一个类型也可以包含一些属性。规定类型类要以大写字母“T”开头。例如：轿车类型"TCar"、线程类型"TThread" 等等。在C＋＋种，类型类也叫做结点类。
在现实世界中，类型和界面的区别往往比较微妙。在真实代码中，有些类除了包含纯虚函数以外，也可能同时包含几个带简单默认实现的普通虚函数。例如：某个类中可能包含一个（非纯虚）虚方法IsLoadable，并定义了该方法的默认实现：return false;。我们不难找出很多类似的例子。
以下是一些类型和界面的界定策略：
如果一个类中包含静态成员，则一定不是界面
如果一个类中包含属性，则一定不是界面
如果一个类中包含非虚方法，则一定不是界面
如果一个类中包含非公有成员，则一定不是界面
如果一个类中包含模板方法，则一定不是界面。
这里的模板方法是指那些调用了该类中其它虚函数的成员，这样的方法通常用于实现针对某种应用的算法框架，这显然超出了界面的范畴。
在C＋＋中，模板方法的另一个意思通常指使用函数模板的成员，由于C＋＋函数模板只能是非虚的，所以包含这种方法的类也一定不是界面。
通常定义那些不十分明确的接口时，先将其指定为一个界面，必要时再把它提升为一个类型。
模板类的命名规范与实体类相同。
为了更好地表示代码段之间的相关性和增加程序的可读性。我们经常会把一段仅在某个函数内反复使用的代码片段封装为一个函数对象，并定义在这个函数体内。对于这类实现功能简单，并且主要通过operator() 来使用的类/结构，其名称应当以大写字母“FO”开头，如："FONameChecker" 等。
b)推荐的组成形式
类的命名推荐用"名词"或"形容词＋名词"的形式，例如："CAnalyzer", "CFastVector", "IUnknown", "IDBWriter", "TTimer", "TThread" ....
不同于C++类的概念，传统的C结构体只是一种将一组数据捆绑在一起的方式。传统C结构体的命名规则为：
a)传统C结构体的命名
传统C结构体的名称全部由大写字母组成，单词间使用下划线界定，例如："SERVICE_STATUS", "DRIVER_INFO" ....
2.2 函数
2.2.1 函数的命名
函数的名称由一个或多个单词组成。为便于界定，每个单词的首字母要大写。
2.2.2 推荐的组成形式
函数名应当使用"动词"或者"动词＋名词"（动宾词组）的形式。例如："GetName()", "SetValue()", "Erase()", "Reserve()" ....
2.2.3 保护成员函数
保护成员函数的开头应当加上一个下划线“_”以示区别，例如："_SetState()" ....
2.2.4 私有成员函数
类似地，私有成员函数的开头应当加上两个下划线“__”，例如："__DestroyImp()" ....
2.2.5 私有成员函数的层次结构表示
通常来说，在一个类中，公有方法、保护方法和私有方法所完成的任务总是呈现一种逐级依次细化的层次结构（意即：保护方法所实现的功能通常比该类中的公有方法更为细小琐碎；类似地，私有方法的功能也比其保护方法更具原子性）。
因此，对于遵循以上规则，并且功能较为复杂的类，在按照“公有、保护、私有”的三级形式划分以后，如果其私有成员中仍然存在明显不同的功能粒度，则可以通过追加更多下划线前缀的形式予以表示。
例如：由三个下划线开头的私有方法“___PushCdr”就要比同一类中，仅由两个下划线开头的私有方法“__MergeConCall”所完成的功能粒度更细小、更琐碎；而四个下划线开头的“____CalcCompensate”则比“___PushCdr”完成的功能更具原子性。
如果发现类中的功能层数太多（从公有方法到最“原子”的私有方法间，一般不应该超过7 层），那通常反应一个不良的设计。此时请检查这个类的功能是否过于臃肿，已使接口显得不太清晰。另外一个常见的问题是将无需访问该类中私有或保护成员的功能定义成了方法。第一个问题可以通过重新划分类层次结构或将一个类分裂为多个类等方法解决。对于第二个问题，由于这些方法无需访问受限成员，大多数时候都可以把它们转变成局部函数（放在无名空间或使用“static”前缀定义）。
2.2.6 成员函数的下划线后缀命名
对一些本应该作为保护或私有成员的函数，由于设计方面的其它考虑（例如：灵活性、功能等方面）将其提升为公有成员的，应该在其后面添加与其原本访问控制级别相应的下划线后缀。
另外，对于其它不推荐直接使用的成员函数（例如：会引起兼容性或可移植性方面问题的函数），也应当在其后面加相应下划线提示。
例如："ioctl_()", "SetSysOpt_()", "GetSysOpt_()", "PreParser__()" ....
2.2.7 回调和事件处理函数
回调和事件处理函数习惯以单词“On”开头。例如："_OnTimer()", "OnExit()" .... 2.2.8 虚函数
回调函数以外的虚函数习惯以“Do”开头，如："DoRefresh()", "_DoEncryption()" ....
2.3 变量
变量应该是程序中使用最多的标识符了，变量的命名规范可能是一套C++命名准则中最重要的部分：
a)变量的命名
变量名由作用域前缀＋类型前缀＋一个或多个单词组成。为便于界定，每个单词的首字母要大写。
对于某些用途简单明了的局部变量，也可以使用简化的方式，如：i, j, k, x, y, z ....
b)作用域前缀
作用域前缀标明一个变量的可见范围。作用域可以有如下几种：
除非不得已，否则应该尽可能少使用全局变量。
关于全局变量和局部静态变量的依赖性问题和初始化时的线程安全性问题
c)类型前缀
类型前缀标明一个变量的类型，可以有如下几种：
类型前缀可以组合使用，例如"gc"表示字符数组，"ppn"表示指向整型的指针的指针等等。
d)数值前缀的特别记法
以“n”作为所有整形前缀是由于大多数情况下，编写程序时不需要过多考虑整形的宽度，但在某些场合中，整形宽度是需要特别注意并且仔细加以区分的，这时可使用如下记法代替“n”前缀：
对浮点型变量也有类似记法如下：
e)推荐的组成形式
变量的名字应当使用"名词"或者"形容词＋名词"。例如："nCode", "m_nState"，"nMaxWidth" ....
2.4 常量
C++中引入了对常量的支持，常量的命名规则如下：
a)常量的命名
常量名由类型前缀＋全大写字母组成，单词间通过下划线来界定，如：cDELIMITER, nMAX_BUFFER。
类型前缀的定义与变量命名规则中的相同。
2.5 枚举、联合、typedef
枚举、联合及typedef语句都是定义新类型的简单手段，它们的命名规则为：
a)枚举、联合的命名
由枚举、联合语句定义的类型名由全大写字母组成，单词间通过下划线来界定，如：FAR_PROC, ERROR_TYPE ....
b)typedef的命名
通常情况下，typedef语句定义的类型名，其命名规范与枚举及联合语句相同，也采用大写字母加下划线的原则。但是在定义一个模板类实例的别名时，为清晰起见，可以考虑酌情使用类的命名原则，例如：
typedef CWriter< CSysFile > CSysFileWriter;
typedef std::vector< int > VINT;
2.6 宏、枚举值
a)宏、枚举值的命名
宏和枚举值由全大写字母组成，单词间通过下划线来界定，如：ERROR_UNKNOWN, OP_STOP。
2.7 名空间
C++名空间是“类”概念的一种退化（大体相当于只包含静态成员且不能实例化的
UI设计(流程/界面)规范 一：UI设计基本概念与流程 目的 规范公司UI设计流程，使UI设计师参与到产品设计整个环节中来，对产品的易用性进行全流程负责，使UI设计的流程规范化，保证UI设计流程的可操作性。 范围 l 界面设计 l 此文档用于界面设计,本文档的读者对象是项目管理人员、售前服务人员、UI界面设计人员、界面评审人员和配置测试人员。 概述 UI设计包括交互设计，用户研究，与界面设计三个部分。基于这三部分的UI设计流程是从一个产品立项开始，UI设计师就应根据流程规范，参与需求阶段、分析设计阶段、调研验证阶段、方案改进阶段、用户验证反馈阶段等环节，履行相应的岗位职责。UI设计师应全面负责产品以用户体验为中心的UI设计，并根据客户（市场）要求不断提升产品可用性。本规范明确规定了UI设计在各个环节的职责和要求，以保证每个环节的工作质量。 基本介绍 A、需求阶段 软件产品依然属于工业产品的范畴。依然离不开3W的考虑（Who,where,why.）也就是使用者，使用环境，使用方式的需求分析。所以在设计一个软件产品之前我们应该明确什么人用(用户的年龄，性别，爱好，收入，教育程度等)。什么地方用（在办公室/家庭/厂房车间/公共场所）。如何用（鼠标键盘/遥控器/触摸屏）。上面的任何一个元素改变结果都会有相应的改变。 除此之外在需求阶段同类竞争产品也是我们必须了解的。同类产品比我们提前问世，我们要比他作的更好才有存在的价值。那么单纯的从界面美学考虑说哪个好哪个不好是没有一个很
客观的评价标准的。我们只能说哪个更合适，更合适于我们的最终用户的就是最好的。 B、分析设计阶段 通过分析上面的需求，我们进入设计阶段。也就是方案形成阶段。我们设计出几套不同风格的界面用于被选。 C、调研验证阶段 几套风格必须保证在同等的设计制作水平上，不能明显看出差异，这样才能得到用户客观真实的反馈。 测试阶段开始前我们应该对测试的具体细节进行清楚的分析描述。 调研阶段需要从以下几个问题出发： 用户对各套方案的第一印象 用户对各套方案的综合印象 用户对各套方案的单独评价 选出最喜欢的 选出其次喜欢的 对各方案的色彩，文字，图形等分别打分。 结论出来以后请所有用户说出最受欢迎方案的优缺点。 所有这些都需要用图形表达出来，直观科学。 D、方案改进阶段 经过用户调研，我们得到目标用户最喜欢的方案。而且了解到用户为什么喜欢，还有什么遗憾等，这样我们就可以进行下一步修改了。这时候我们可以把精力投入到一个方案上，将方案做到细致精美。 E、用户验证阶段 改正以后的方案，我们可以将他推向市场。但是设计并没有结束。我们还需要用户反馈，好的设计师应该在产品上市以后去站柜台。零距离接触最终用户，看看用户真正使用时的感想。为以后的升级版本积累经验资料。 经过上面设计过程的描述，大家可以清楚的发现，界面UI设计是一个非常科学的推导公式，他有设计师对艺术的理解感悟，但绝对不是仅仅表现设计师个人的绘画。所以我们一再强调
B/S 系统界面设计规范 1.引言 界面美观、操作易用性、维护成本低是评价B/S系统的关键。本规范参考了一些成熟产品科学的开发方法，将开发过程中的方式、规则等强行的约束。希望藉此来提高用户操作感受，提升B/S产品的质量。 1.1. 编写目的 广义的界面概念包含了除页面布局设计之外，交互性的设计，及人体工程学方面的研究。本规范制订的依据从广义概念出发，总结以往项目的成败经验，目的是从整体上提升公司B/S类产品的质量、开发效率。从以技术为中心发展为以客户为中心，将类似项目成功的经验继承和积累下来，将B/S系统与C/S系统开发过程上的区别降低到仅显示控制的极小的层面。新的开发方式强调分层，规范出界面设计人员做什么，服务器编程人员做什么，这样就把页面和控制代码两个层面清晰的分开。 1.2. 背景 B/S模式系统以其易部署、易扩展、能够高度集成各种技术的特点，在公司产品线中占越来越大的比重，.Net、J2ee等技术的发展更是将B/S系统的开发和桌面应用程序开发的工程方法统一起来，突出服务器端技术，这些变革要求界面设计人员和服务器端编程人员可以应用更加科学的方法合作，团队的合作方式甚至决定了一个系统开发的成败。目前公司较多的服务器端编程人员仍然处于“后ASP 时代”的开发方式，表现为前台页面仍然与服务器代码高度的关联，带来的后果是重复建设、高昂的维护成本或失去控制的项目，没有充分的发挥出集成开发工具的优势。在以往的开发方式下界面设计侧重在静态页面的建设上，每个页面作为一个独立的模块来处理，在页面交互中则是程序员根据自己的习惯来控制，程序对个人的编程风格的依赖很强，这些在以往开发WEB站点的方式扩展到B/S系统有时是不正确的，甚至是背道而弛的，当然也不利于规模化的团队合作。 1.3. 定义 术语定义： 效果图：由界面设计人员设计的页面效果图，综合了概要设计的业务需要和整个站点的风格，它规定了页面布局上的每个细节。 容器：即HTML 标记的嵌套结构，如在表格->行->单元格内放置图片，那么可以认为单元格是放置图片的容器。 样式表：即级联式样式表CSS，它是W3C机构在HTML标记语言上扩展的格式语言。 非标准交互控件：是通过标准控件组合、扩展等方法以提高特定业务执行效率而进行封装的控件，或概括为用户根据以往的操作经验不能够直接领会出操作方式的交互控件。 2. 界面设计规范细则 总体目标 以规范作为基本原则，在此框架内进行合理的扩展和变化，将站点内的每个模块服从于整个站点，模块页面与“高内聚”的控制代码紧密的结合在一起，同时对应于应用程序基于系统的架构分析。 2.1. 通用原则 1 界面色彩要求：计算机屏幕的发光成像和普通视觉成像有很大的不同，应该注意这种
系统开发规范 1、数据库使用规范 1.1服务器上有关数据库的一切操作只能由服务器管理人员进行。 1.2程序中访问数据库时使用统一的用户、统一的连接文件访问数据库。 1.3原则上每一个频道只能建一个库，库名与各频道的英文名称相一致，库中再包含若干表。比较大的、重点的栏目可以考虑单独建库，库名与栏目的英文名称相一致。 1.4命名： （1）数据库、表、字段、索引、视图等一系列与数据库相关的名称必须全部使用与内容相关的英文单词命名（尽量避免使用汉语拼音），对于一个单词难以表达的，可以考虑用多个单词加下划线（_）连接（不能超过四个单词）命名。 （2）所有的名称必须统一使用英文小写字母。 （3）所有的名称起始和结尾不能使用下划线（_）。 （4）所有的名称不能包含26个英文小写字母和下划线（_）以外的其他字符。 1.5不再使用的数据库、表应删除，在删除之前必须备份（包括结构和内容）。 2、文档规范 所有的项目必须有相关的文档说明（可以是电子文档）。文档应包含如下内容： （1）项目名称。 （2）项目小组名单，项目负责人。 （3）项目开发起始时间和结束时间。 （4）项目内容描述。 （5）项目位置。（在哪个频道、哪个栏目） （6）与项目有关的程序文件名（含路径名），文件内容及实现的功能描述。 （7）完整的程序流程图。
（8）数据库、表、视图、索引的名称，用途。字段的名称、类型、长度、用途，必须附上相关的SQL语句。 3、源代码与页面嵌套规范 3.1源代码： （1）使用自定义变量（包括全局变量、局部变量）之前必须先声明变量，并用注释语句标明变量的类型、用途。 （2）自定义函数必须用注释语句标明函数的用途、参数的数据类型、意义，返回值的类型。 （3）程序中重要的过程或代码较长的过程应使用注释语句标明该过程的起始行和结束行，并注明该过程的功能。 （5）所有的注释文字一律使用简体中文。 3.2 HTML页面嵌套： （1）网页设计部设计的HTML页面以嵌套的方式确定用于动态显示程序执行结果的位置、宽度、行数（或高度）等，并在相应位置予以文字说明。页面中与程序无关的图片、文字、联结等必须使用完整的URL。 （2）软件开发人员和编辑人员可以根据情况协商，将页面文件及图片与程序独立存放在各自的服务器上，页面改版和修改程序独立进行。 （3）使用include技术将分割开的HTML页面分别嵌入程序代码中，要求做到修改HTML页面时无须改写程序，而修改程序时不会影响HTML页面效果，将页面改版和修改程序两项工作分别独立。 （4）页面和程序嵌套以后不能破坏原HTML页面的整体显示效果，字体、字号、颜色等应尽量保持原HTML页面的风格。 （5）动态生成的页面的各项指标（如图片大小、页面宽度、高度、页面文件的字节数等）应符合本公司网页设计方面的要求。 4、测试规范（软件部分） 对于较大的项目应成立相应的测试小组，小组成员由软件开发人员、网页设计人员、技术人员、
软件设计文档国家标准GB8567-88 一、文档编写标准化 在整个项目开发及使用过程中，应该有完备的文档支持，文档编制要求具有针对性、精确性、清晰性、完整性、灵活性和可追溯性。 完备的文档对软件的开发及使用起了很大的作用。一般要求编写好十三种文档。 1、可行性分析报告 说明该软件开发项目的实现在技术上、经济上和社会因素上的可行性，评述为了合理地达到开发目标可供选择的各种可能实施方案，说明并论证所选定实施方案的理由。 2、项目开发计划 为软件项目实施方案制订出具体计划，应该包括各部分工作的负责人员、开发的进度、开发经费的预算、所需的硬件及软件资源等。 3、软件需求说明书（软件规格说明书） 对所开发软件的功能、性能、用户界面及运行环境等作出详细的说明。它是在用户与开发人员双方对软件需求取得共同理解并达成协议的条件下编写的，也是实施开发工作的基础。该说明书应给出数据逻辑和数据采集的各项要求，为生成和维护系统数据文件做好准备。 4、概要设计说明书 是概要设计阶段的工作总结。主要包括功能分配、模块划分、程序总体结构、输入输出以及接口设计、运行设计、数据结构设计和出错处理等，为详细设计作好准备。 5、详细设计说明书 着重描述每一模块是怎样实现的，包括实现算法、逻辑流程等。 6、用户操作手册 详细描述了该软件的功能、性能和用户界面，使用该软件的具体方法等。 7、测试计划 包括测试内容、进度、条件、人员、测试用例的选取原则、测试结果允许的偏差范围等。8、测试分析报告 测试计划的执行情况，对测试结果的分析，提出测试结论。 9、开发进度月报 按月提交的项目进展情况报告。包括计划与实际执行情况的对比、阶段成果、遇到的问题、解决的方法以及下一步的打算。 10、项目开发总结报告 项目完成以后，总结实际执行情况。如进度、成果、资源利用、成本和投入的人力，对项目开发作出评价，总结经验与教训。 11、软件维护手册 主要包括软件系统说明、程序模块说明、操作环境、支持软件说明、维护过程说明等。12、软件问题报告 记录软件出现问题的日期、发现人、状态、问题所属模块等，为软件修改提供准备文档。13、软件修改报告 软件产品投入使用后，发现了需修改、更正的问题，要将出现的问题、修改意见、修改可能出现影响作出详细描述，提交审批。 二、可行性分析报告的撰写要求 可行性研究报告的编写内容要求如下： 1 引言
第1.0节： 简介 微软的Surface使开发人员和设计人员，为他们的客户提供惊人的，社交的，具有很强的互动体验。来自四面八方的人们可以使用360°接口面对面的协作，合作和建立信任。 开发引人注目的Serface体验需要不同的方法来设计接口。本文提出的设计原则和指导方针，以解决关键方面，包括：互动，视觉，声音，文字，和更多的应用程序界面设计。使用这些原则和惯例为出发点，得到最有效的界面软件和硬件平台的独特功能。 第4.0节： Serface 硬件 本节讨论具体涉及到serface的硬件设计注意事项和指导方针。 第4.1节： 输入法 1.基于视觉的触摸 与serface互动的主要方式是触摸。Serface从一开始就在为触摸设计，它是Surface 应用程序中互动的关键动力。 手指和blobs ：serface自动识别区分手指和blobs。当有人将手指放在屏幕上，手指会被识别。他们指出的方向，视觉输入系统会自动检测到手指数目、位置和方向。当其它不认定为手指或者标签的物品被放置在屏幕上时，被列为blobs。提供基本大小的信息并分配一个任意方向。方向值在blobs中通常是没有可靠的手指或者标签。 触摸交互- 表面SDK操作处理器识别三个离散的操作：移动，旋转和调整大小。 事实上，Surface SDK中只有三个操作手势是一个技术性的事实，但是从交互的角度看，有许多不同的触摸交互，一个人可以使用这些操作。下面的插图显示了如何使用一个手指或者几个手指，在各种触摸交互中执行虚拟对象。
点击- 按，然后释放 保持-然后按住 滑动或推- 使用你的手指滑动或推来移动对象
轻击-轻按，迅速滑落，然后释放 触摸并开启- 将你的手指，靠近物体外侧边缘的一块内容，并围绕其中心旋转 自旋- 扭转迅速用两个手指旋转对象
系统页面设计规范V1.0 柯建树2013/07/30
目录 一、基础规范 01、系统宽、高度 02、文本框设计规范 (1)基础规范 (2)应用场景 03、页码设计规范 (1)普通页码翻页 (2)小型页码翻页 04、文字的编排与设计 (1)文字大小 (2)文字颜色 (3)文字行距 (4)英文字体规范 (5)文字链接 05、整齐的概念和应用 06、模块化表现 二、参考指南 01、页面修饰 (1)简单的光影效果
(2)质感的表现 (3)透明效果的应用 02、个性皮肤的应用 03、图标的统一使用 04、图标表意 05、表格
基础规范 一、系统宽、高度 显示器分辨率比例 在软件系统的使用上，遵循以大多数为视觉标准，同时遵循其他分辨率的显示效果。 软件系统一般采用满屏显示内容，宽度为100%，高度100%，在设计网页时，应与使用量最大的分辨率作为参照，即1024px*768px。在这个尺寸上，系统应当具有全部显示的能力。 不同浏览器，不同分辨率下网页第一屏最大可视区域
在IE下，宽度21表示17px的滚动条加上4px的浏览器边框，做到全部兼容，以小分辨率设计，目前我们系统的设计标准是1003*600。 即PS的设计文档1003px*600px，72dpi。 二、文本框设计规范 尺寸大小 (1)小型输入框应至少设置5个中文字符宽度，内边距（padding）上下3px，左右7px，单行不少于18px； (2)大型输入框应至少设置8个中文字符宽度，内边距（padding）上下3px，左右7px，单行不少于18px； (3)搜索框设计宽度至少设置8个中文字符宽度，内边距（padding）上下3px，左右7px，单行不少于18px，宽度不少于130px； 帮助信息 (1)帮助信息一般有二类，限定标签提示、标示性文字等； (2)“限定标签提示”一般放在搜索框的左面； (3)“标示性文字”可设置灰色（#CCCCCC）显示，点击输入框后提示文字消失。提示文字应简明扼要，文字一般用于内容、用途、搜索范围等对用户有真正帮助意义的提示，“请输入关键字”这样的提示不应出现。 1、2、
********系统系统设计文档 *****系统设计小组 组长：**** 组员：**** **** **** ****
目录 1 引言 (1) 1.1编写目的 (1) 1.2背景 (1) 1.3定义 (1) 1.4参考资料 (1) 2 系统功能设计 (3) 2.1 功能模块设计 (3) 2.2 ****模块设计 (3) 2.3 ****模块设计 (3) 3 类设计 (4) 4 数据库设计 (6) 5 接口及过程设计 (7) 6 界面设计 (8) 7 其它设计 (12) 8 小结 (13)
说明： ●在进行系统设计时可以任意传统系统设计方法或面向对象系统设计方 法，或者两者相结合，不局限于使用一种方法。 ●文档中每章图都需要配有相应的文字解释。 ●本文档中的图按照章编号，如“1 引言”表示第一章，“1.1 编写目的” 表示第一章第一节。第一章第一个图标号为“图1.1 ****图”，而第二个 图标号为“图1.2 ****图”，写在图的下面，居中。 ●本文档中的表也按照章编号，第一章第一个表标号为“表1.1 ****表”， 而第二个表标号为“表1.2 ****表”，写在表的上面，居中。 ●使用visio画用例时，Actor及用例的图示模具（用例图模具.vss）可以 到BB平台下载。 1 引言 1.1编写目的 说明编写这份系统设计说明书的目的，指出预期的读者。 1.2背景 说明： a．待开发的软件系统的名称； b．列出此项目的任务提出者、开发者、用户以及将运行该软件的计算站（中心）。 1.3定义 列出本文件中用到的专门术语的定义和外文首字母组词的原词组。 1.4参考资料 列出用得着的参考资料，如：
假如你在Windows环境下开发，微软定义了一套称为“用户体验”的参考规范（当然，“用户体验”的内容已经超出了狭义的“用户界面”）。这个规范对菜单、按钮、图标、窗体、快捷键、消息框和文本等界面元素的设计，给出了一整套建议。倘若不是编写游戏之类的东西，就没有理由不参照这个规范。 以下是我见过的一些糟糕的用户界面风格： 过份使用各种奇形怪状、五颜六色的控件。这些界面往往出自充满激情和想法的新手。它很容易使人想起过去农村穿着红褂子、绿裤子的小 媳妇，或者今天城市街头画着大花脸的扭秧歌的大妈。 界面元素比例失调。我见过按钮巨大无比，其尺寸甚至超过显示重要内容的文本框的界面。 界面元素凌乱。比如说，按钮和文本框摆放地点随意，相当于客厅当卧室，卫生间当厨房。 违背使用习惯。你按下F1，它没有弹出帮助，却执行了一件绝对出乎你意料的动作。 消息框信息含糊、混乱。下面是某软件弹出的消息框。把“确定”和“取消”改为“是”和“否”会不会更清晰一些？就事论事，假如干脆自己做个form，改成“想”和“不想”，那更好。 还有一种糟糕的用户界面，乍一看很厉害，实际上完全是缺乏规划的结果。 这种软件本身的确提供了比较复杂的功能，但对于哪些是常用功能，哪些是很少用到的高级功能，缺乏评估。什么功能都往界面上挤，占地方不说，用户会厌烦，弄不好还会被吓跑。 对于这种软件来说，默认界面只应该显示目标用户最常使用的功能，至于不常用到的高级功能，可以“隐藏”起来，比如说，放到菜单里，不要都做成按钮摆到界面上。果真需要需要这些高级功能的话，用户自然会到菜单里去找的。 在这方面，微软Office软件堪称楷模。比如Word，从编写“代办文凭”这样的电线杆上的“狗皮膏”，到排版严肃的长篇巨著，都游刃有余。对于低级用户来说，它简单易用，对于高级用户来说，要的功能都有。这个软件界面做得就非常有水平。就象那些高级数码相机一样，操作之简单可以和“傻瓜”相机媲美。按一个按钮就可以使你心想事成，恰恰说明它聪明得可以。 一句话，你愿意使用界面上摆满了各种让人眼花缭乱的玩意儿，左看右看也不知道从哪儿下手的软件吗？ 软件界面设计相关的各项介绍
软件界面设计规范 1概要 界面设计中一定要保持界面的一致性。 一致性既包括使用标准的控件，也指使用相同的信息表现方法，如在字体、标签风格、颜色、术语、显示错误信息等方面确保一致。 界面力求简洁明了，保证系统功能设计的合理与明确，布局明确、交互操作合理、协调统一。功能要表现清楚，分类清晰有条理，避免过多的控件嵌套导致的视觉混乱；单一功能的操作目的明确，符合易用性原则，避免不必要的信息显示而对用户造成视觉干扰；力求操作简单，简单的功能一步完成，比较复杂的功能三步之内，复杂的功能操作使用操作向导来辅助客户完成。 2色调风格 2.1色调： 软件界面设计中常用的主色调包括：蓝色、红色、绿色、黑色 蓝色：运用的行业较为广泛，如通讯、电子、房产、钢铁、生产管理等行业大部分以蓝色为主色调来设计软件。 红色：在政府单位运用比较多。 绿色：一般运用于教育、医疗、农林等行业。 黑色：能源、石油、房地产行业有时候会用中性的黑色作为主色调。
表现区：通常用浅色，如：白色、淡灰、或者淡蓝之类，因为大面积的文字信息在浅色上便于长时间阅读，不容易形成视觉疲劳。 2.2风格： 软件界面的风格通常比较简约。不同行业，使用的环境不同稍有差异。 3登录界面 基本元素：logo、系统名称、输入框、提交按钮。如下： 4页面逻辑结构 功能页面功能页面 弹出页面弹出页面弹出页面
软件界面通常是上面这样的逻辑结构 首页：宏观预览各项设备管理数据，快速访问期望的数据功能 功能页面：查看某一功能模块的全部数据，查看某一对象的各类相关数据 弹出页面：填写和提交表单，对功能中的某一单项数据进行增加/删除/查询/修改/审核/打印/导出等功能操作。 5页面的基本属性 页面宽度：属性值为auto，最小值1024像素。默认状况下无横向滚动条。 注意：宽度、位置、边距为不可变数据 背景：页面整体为白色背景#FFFFFF 或者浅灰、浅蓝等，总之是非常接近白色的颜色。 注：白色为常用色值，对于特殊个性化页面可根据特殊要求变更色彩；背景色彩尽量少用饱和度高的颜色， 页面位置：居中 页面边距：上 0px；下 0px；左 0 px；右 0 px； 注意：有时候会专门设置一定数值的边距，这时通常 与模块间的间距相同，如上下左右都是5px。
软件用户界面设计规范 1.导言 1.1 目的 为开发人员提供界面设计和开发的指南，引导开发人员设计简洁美观的用户界面； 1.2 适用范围 适用于xxxxxx。 2.软件界面设计的重要性 2.1 发展趋势 软件用户界面的发展经历了从简单到复杂、从低级到高级的过程，用户界面在软件系统中的价值比重越来越高。 2.2 开发竞争 得益于互联网的发展和普及，软件开发的技术门槛在不断下降，大部分软件企业的技术手段也趋向于雷同，“软件设计”变得越来越重要。当大家都掌握了相似的技术和需求信息后，企业之间的开发竞争“比的就是设计”。 –软件用户界面设计要综合考虑“易用性设计”、“艺术设计”和“技术实现”，很有挑战性。 2.3 用户挑剔 用户界面在很大程度上影响着软件的命运，因为广大用户对软件的评价主要来源于他们操作用户界面的感受。同类软件越多，选择余地越大，购买者对软件
用户界面就越挑剔。 3.软件界面设计的现状、问题及原因 3.1 不容乐观的现状 尽管国内有很多技术出色、聪明过人的软件工程师，但是不少人开发出来的软件产品却既难用又难看，客户很不满意。导致经常要修改软件的用户界面，造成极大的生产力浪费。 到处是用户界面设计缺陷： –界面措辞含糊，甚至有错别字。连简单的消息框都设计不好，可能存在文不对题的语病。 –界面布局混乱，缺乏逻辑，凡是能放的东西都堆集上去，让用户不知从何下手。–没有防错处理，不对用户输入的数据进行检验，不根据用户的权限自动隐藏或者禁用某些功能。执行破坏性的操作之前，不提醒用户确认。 –不提供进度条、动画来反映正在进行的比较耗时间的过程，对于重要的操作也不返回结果，让用户干着急。 3.2 问题和原因之一 由于国内没有开设软件界面设计的课程，大家对这部分知识没有深刻的意识，只是在工作中凭着个人的经验与感觉设计软件的用户界面，这样产生的界面往往得不到大众用户的认可。 3.3 问题及原因之二 开发人员在设计用户界面方面不仅存在先天的教育缺陷，更加糟糕的是还常常“错位”的毛病。他以为只要自己感觉用户界面漂亮、使用起来方便，那么用户也一定会满意。 3.4 问题及原因之三
软件界面设计规范_V1.0 1概要 界面设计中一定要保持界面的一致性。 一致性既包括使用标准的控件，也指使用相同的信息表现方法，如在字体、标签风格、颜色、术语、显示错误信息等方面确保一致。 界面力求简洁明了，保证系统功能设计的合理与明确，布局明确、交互操作合理、协调统一。功能要表现清楚，分类清晰有条理，避免过多的控件嵌套导致的视觉混乱；单一功能的操作目的明确，符合易用性原则，避免不必要的信息显示而对用户造成视觉干扰；力求操作简单，简单的功能一步完成，比较复杂的功能三步之内，复杂的功能操作使用操作向导来辅助客户完成。 2色调风格 2.1色调： 软件界面设计中常用的主色调包括：蓝色、红色、绿色、黑色 蓝色：运用的行业较为广泛，如通讯、电子、房产、钢铁、生产管理等行业大部分以蓝色为主色调来设计软件。 红色：在政府单位运用比较多。 绿色：一般运用于教育、医疗、农林等行业。 黑色：能源、石油、房地产行业有时候会用中性的黑色作为主色调。 表现区：通常用浅色，如：白色、淡灰、或者淡蓝之类，因为大面积的文字信息在浅色上便于长时间阅读，不容易形成视觉疲劳。
2.2风格： 软件界面的风格通常比较简约。不同行业，使用的环境不同稍有差异。 3登录界面 基本元素：logo、系统名称、输入框、提交按钮。如下： 4页面逻辑结构 软件界面通常是上面这样的逻辑结构 首页：宏观预览各项设备管理数据，快速访问期望的数据功能 功能页面：查看某一功能模块的全部数据，查看某一对象的各类相关数据 弹出页面：填写和提交表单，对功能中的某一单项数据进行增加/删除/查询/修改/审核/打印/导出等功能操作。
Web应用界面设计规范（Design Specific ation for Web UI） 主讲人：ARay 目录： 一、软件界面规范的重要性及其目的 二、用户体验为何如此重要 三、Web规范体系介绍 四、界面设计开发流程 五、应该遵循的基本原则 六、界面设计规范 一、软件界面规范的重要性及其目的 ①使最终设计出来的界面风格一致化，开发编码人员相互之间开发更轻松，遵循统一的操作规范，以标准化的方式设计界面，提高工作效率。减少和改变责任不明，任务不清和由此产生的信息沟通不畅、反复修改、重复劳动、效率低下的现象。 ②产品设计通过规范的方式来达到以用户为中心的目的。 二、用户体验为何如此重要 ①日常生活中的遭遇 X员工悲惨的一天： 早晨起来，发现闹钟没有按原先设定响起来。 一边烧水，一边穿衣服，临走前去喝水却发现水还没有烧开。 到了地铁站，发现公交卡没有钱了。 无奈之下只能去排队买票。 排了3趟地铁，终于到公司了，但是你却迟到了。 结果：尽管你已经非常努力，但是你还是迟到了。 那么，让我们看看这一连串 的倒霉事， 是什么让我们如此狼狈？ ②什么是用户体验
用户体验（user experience）是以用户为中心的设计中最重要的一个部分，强调的是过程，是软件对用户行为产生的反应与用户期待值要尽可能的一致。 糟糕的用户界面表现： 表现一：过分使用各种奇形怪状、五颜六色的控件。 表现二：界面元素比例失调。比如按钮巨大无比，其尺寸甚至超过显示重要内容的文本框的界面。 表现三：界面元素凌乱。比如说，按钮和文本框摆放地点随意，该对齐的控件对不齐。 表现四：违背使用习惯。你按F1，它没有弹出帮助，却执行了一件绝对出乎你意料的动作。表现五：消息框信息含糊、混乱。比如软件弹出一个消息框。把原本“确定”和“取消”写成为“是”和“否”，让用户不知道什么意思。 表现六：还有一种糟糕的用户界面，乍一看很厉害，实际上完全是缺乏规划的结果。这种
软件设计规范 概述 软件设计是把需求转化为软件系统的最重要的环节，系统设计的优劣在根本上决定了软 件系统的质量。 在此，主要阐述软件系统设计的5个核心内容：体系结构设计、用户界面设计、数据库设计、模块设计、数据结构和算法设计。旨在帮助开发人员搞清楚“设计什么”以及“如何 设计”。 一般把设计过程划分为两个阶段：概要设计阶段和详细设计阶段，如下所示： *概要设计阶段的重点是体系结构设计。 *详细设计阶段的重点是用户界面设计、数据库设计、模块设计、数据结构与算法设计 等。 可根据项目的情况进行文档裁减和过程合并，如项目开发过程只有一个设计阶段和设计 文档。 体系结构 体系结构如同人的骨架。如果某个家伙的骨架是猴子，那么无论怎样喂养和美容，这家 伙始终都是猴子，不会成为人。 由此可见，体系结构乃是系统设计的重中之重。 目前业界比较流行的软件结构模式有C/S（客户/服务器）、B/S（BROWSE/SERVER）、层次结构（上下级层次结构、顺序相邻的层次结构、含中间件的层次结构） 体系结构设计原则 ● 合适性 即体系结构是否适合于软件的“功能性需求”和“非功能性需求”。高水平的设计师高就高在“设计出恰好满足客户需求的软件，并且使开发方和客户方获取最大的利益，而不是 不惜代价设计出最先进的软件。 ● 结构稳定性 详细设计阶段的工作如用户界面设计、数据库设计、模块设计、数据结构与算法设计等等，都是在体系结构确定之后开展的，而编程和测试则是更后面的工作，因此体系结构应在 一定的时间内保持稳定。
软件开发最怕的就是需求变化，但“需求会发生变化”是个无法逃避的现实。人们希望在需求发生变化时，最好只对软件做些皮皮毛毛的修改，可千万别改动软件的体系结构。如果当需求发生变化时，程序员不得不去修改软件的体系结构，那么这个软件的系统设计是失 败的。 高水平的设计师应当能够分析需求文档，判断出哪些需求是稳定不变的，哪些需求是可能变动的。于是根据那些稳定不变的需求设计体系结构，而根据那些可变的需求设计软件的 “可扩展性”。 ● 可扩展性 可扩展性是指软件扩展新功能的容易程度。可扩展性越好，表示软件适应“变化”的能 力越强。 可扩展性越来越重要，这是由现代软件的商业模式决定的： *社会的商业越发达，需求变化就越快。需求变化必将导致修改（或者扩展）软件的功能，现代软件的规模和复杂性要比十年前的大得多（对比一下操作系统的变化就明白了），如果软件的可扩展性比较差的话，那么修改（或者扩展）功能的代价会很高。 *现代软件产品通常采用“增量开发模式”，开发商不断地推出软件产品的新版本，从而不断地获取增值利润。如果软件的可扩展性比较差的话，每次开发新版本的代价就会很高。虽然开发商抓住了商机，但却由于设计水平差而导致没有赚取多少利润，真是要活活气死。 ● 可复用性 由经验可知，通常在一个新系统中，大部分的内容是成熟的，只有小部分内容是创新的。一般地可以相信成熟的东西总是比较可靠的（即具有高质量），而大量成熟的工作可以通过 复用来快速实现（即具有高生产率）。 可复用性是设计出来的，而不是偶然碰到的。要使体系结构具有良好的可复用性，设计师应当分析应用域的共性问题，然后设计出一种通用的体系结构模式，这样的体系结构才可 以被复用。 用户界面设计 为了提高用户界面的易用性和美观程度，总结了十个设计原则。用于提高易用性的界面 设计原则有8个： *用户界面适合于软件的功能 *容易理解 *风格一致
1.用户满意度=功能+___人机界面_____+响应时间+可靠性+易安装性+____信息____+可维护性+其他因素 2. ____人机交互（人机对话）____是指人与计算机之间使用某种语言、以一定的交互方式，为了完成任务进行的一系列信息交换过程。 3.软件界面设计分为____功能性设计界面____、____情感性设计界面____、____环境性设计界面____。 4.进行系统分析和设计的第一步是___用户分析_____。 5.使用较早，也是使用最广泛的人机交互方式是____交互方式____。 6.软件界面开发流程包括____系统分析____、____系统设计____、____系统实施____三个阶段 7.设计阶段包括界面的____概念设计____、____详细设计____、____原型建立____与界面实现以及综合测试与评估等8.VB 是以结构化___Basic_____语言为基础、以____事件驱动作____为运行机制的可视化程序设计语言。 9.菜单使用形式主要有____菜单操作____和____Tba控件操作____两种。 10.随着计算机图形技术的发展，以直接操纵、桌面隐喻以及所见即所得为特征的____图形用户界面____技术广泛被计算机系统采用。 11.在用VB 开发应用程序时，一般要布置窗体、设置控件的属性、___编写代码___。 12. 假定在窗体上有一个通用对话框，其名称为CommonDialog1,为建立一个保存文件对话框，则需要把Action 属性设置为__value__。 13. 计时器事件之间的间隔通过__interval__属性设置。 14. 语句“Print “5+65=”;5+65”的输出结果为__5+65=70__。 15. 设有下列循环体，要进行4次循环操作，请填空。 x = 1 Do x = x * 2 Print x Loop Until__x<=32__ 16. 下列程序段的执行结果为__2 3 5__。 x = 1 y = 1 For I = 1 To 3 F= x + y x = y y = F Print F; Next I 17. 以下为3个列表框联动的程序，试补充完整。 Private Sub Dir1_Change() File1.Path=Dir1.Path End Sub Private Sub Drive1_Change() Drivel.Path=File1.Path;Dir1.Path=Drivel.Path__[7]__ End Sub 18. 在下列事件过程中则响应该过程的对象名是cmdl，事件过程名是__窗口标题事件__。 Private Sub cmd1_Click() Form1.Caption=“VisualBasic Example” End Sub 19. 当将文本框的SelStar 属性设置为0时，表示选择第开始位置在第一个字符之前，设置为1时表示__[9]__。 20. 以下程序代码实现单击命令按钮Command1 时形成并输出一个主对角线上元素值为“-”，其他元素值为“+”第6*6 阶方阵。 Privas Sub Command1_Click() DimA(6,6) For I = 1 To 6 For J = 1 To 6 If I = J Then Print “-” Else __[10]__ End If Print A (I,J); Next J Print Next I End Sub 21. 字母B的KeyAscii 码值为65，其KeyCode码值___[11]__。 22. Visual Basic 中的控件分为3类：__[12]_、ActioveX 控件和可插入对象。
B/S系统界面设计规范 1. 引言 界面美观、操作易用性、维护成本低是评价B/S系统的关键。本规范参考了一些成熟产 品科学的开发方法，将开发过程中的方式、规则等强行的约束。希望藉此来提高用户操作感受，提升B/S产品的质量。 1.1. 编写目的 广义的界面概念包含了除页面布局设计之外，交互性的设计，及人体工程学方面的研究。本规范制订的依据从广义概念出发，总结以往项目的成败经验，目的是从整体上提升公司 B/S类产品的质量、开发效率。从以技术为中心发展为以客户为中心，将类似项目成功的经 验继承和积累下来，将B/S系统与C/S系统开发过程上的区别降低到仅显示控制的极小的层 面。 新的开发方式强调分层，规范出界面设计人员做什么，服务器编程人员做什么，这样就把页面和控制代码两个层面清晰的分开。 1.2. 背景 B/S模式系统以其易部署、易扩展、能够高度集成各种技术的特点，在公司产品线中占 越来越大的比重，.Net、J2ee等技术的发展更是将B/S系统的开发和桌面应用程序开发的工 程方法统一起来，突出服务器端技术，这些变革要求界面设计人员和服务器端编程人员可以应用更加科学的方法合作，团队的合作方式甚至决定了一个系统开发的成败。 目前公司较多的服务器端编程人员仍然处于后ASP时代”的开发方式，表现为前台 页面仍然与服务器代码高度的关联，带来的后果是重复建设、高昂的维护成本或失去控制的 项目，没有充分的发挥出集成开发工具的优势。 在以往的开发方式下界面设计侧重在静态页面的建设上，每个页面作为一个独立的模 块来处理，在页面交互中则是程序员根据自己的习惯来控制，程序对个人的编程风格的依赖 很强，这些在以往开发WEB站点的方式扩展到B/S系统有时是不正确的，甚至是背道而弛 的，当然也不利于规模化的团队合作。 1.3. 定义 术语定义： 效果图：由界面设计人员设计的页面效果图，综合了概要设计的业务需要和整个站点的风格，它规定了页面布局上的每个细节。 容器：即HTML标记的嵌套结构，如在表格-> 行-> 单元格内放置图片，那么可以认为单元格是放置图片的容器。 样式表：即级联式样式表CSS，它是W3C机构在HTML标记语言上扩展的格式语言。非标准交互控件：是通过标准控件组合、扩展等方法以提高特定业务执行效率而进行封装的控件，或概括为用户根据以往的操作经验不能够直接领会出操作方式的交互控件。 2. 界面设计规范细则 总体目标 以规范作为基本原则，在此框架内进行合理的扩展和变化，将站点内的每个模块服从于整个 站点，模块页面与高内聚”的控制代码紧密的结合在一起，同时对应于应用程序基于系统
软件界面设计规范 1.界面规范 .总体原则以用户为中心。 设计由用户控制的界面，而不是界面控制用户。清楚一致的设计。所有界面的风格保持一致，所有具有相同含义的术语保持一致，且易于理解拥有良好的直觉特征。以用户所熟悉的现实世界事务的抽象来给用户暗示和隐喻，来帮助用户能迅速学会软件的使用。较快的响应速度。简单且美观。 .原则详述 1.2.1.用户控制用户界面设计的一个重要原则是用户应该总是感觉在控制软件而不是感觉被软件所控制。操作上假设是用户--而不是计算机或软件--开始动作。用户扮演主动角色，而不是扮演被动角色。在需要自动执行任务时，要以允许用户进行选择或控制它的方式来实现该自动任务。提供用户自定义设置。因为用户的技能和喜好各不相同，因此他们必须能够个性化界面的某些方面。Windows为用户提供了对许多这方面的访问。您的软件应该反应不同的系统属性--例如颜色、字体或其他选项的用户设置。采取交互式和易于感应的窗口，尽量避免使用模态对话框，而使用"非模式"辅助窗口。"模式"是一种状态，它排除一般的交互，或者限制用户只能进行特定的交互。当最好使用一个模式或该模式只是可替换的设计时--例如，用于在一个绘图程序中选定一个特定感觉--请确保该模式是显然的、可见的，是一个明确的用户选定的结果，并且容易取消。在后台运行长进程时，保持前台式交互。例如，当正在打印一个文档，即使该文档不能被改变，用户也应该可以最小化该窗口。谅解。用户喜欢探索一个界面，并经常从尝试和错误中学习。一个有效的界面允许交互式的发现，它只提供一组合适的选择，并在用户可能破坏系统或数据的情况时发出警告。如果可行，还应提供可逆转或可还原的操作。即使在设计得很好得界面中，用户也可能犯错误。这些错误既可以是物理上得（偶然地指向了错误的命令或数据），也可以是逻辑上的（对选定哪一个命令或哪些数据做出了错误的决定）。有效的设计避免很可能导致错误的情况。它还包容潜在的用户错误，并且使用户易于还原。 1.2.2.清楚一致的设计一致允许用户将已有的知识传递到新的任务中，更快地学习新事物，并将更多的注意力集中在任务上。这是因为他们不必花时间来尝
这几天有人问我说：“最近看了好多教程，都老高大上了，但是老弟我做不到呀，想学点直接能拿来用的，这个要求过分吗……” 这个，好吧，那就直接说说能用的知识：字体字号。 也许你会说：字体字号？也太Low了吧，这个谁不知道重要呀。 对于这个问题，我想说：会和熟练，是两回事。一个App，不同部分的字体字号你能准确地说出来吗？ 很多刚做APP界面的设计师，经常会因为字号，字体颜色，间距而困扰。 拿到设计需求后，开始进行设计，不知道从何去调整界面的字号和行间距等。容易碰到的问题是页面和页面的字号调着调着就大小或颜色不统一了。并且容易导致设计稿反复得修改。设计出来的效果图文字左右间距层次不齐，导致与预期不符等。 这小节我将和大家理一理界面中常用的字体，字号，字体颜色及间距对齐的一些小经验。希望能对大家有些帮助。 一.成也字，败也字 在设计师的职业生涯中，至少一次甚至多次在工作中因为字体不协调栽跟头。在实践的过程中我们会慢慢发现一些规律或者经验规范。接下来我将和大家一起聊聊在界面设计中的那些常规字体的使用规范。 我们常常会听到，这也太LOW了吧！！你能统一一下字体吗？ 不明确而繁琐的字体搭配会导致整个画面失调。可以这样说，字体可以成就设计也可以毁掉设计。
问题的关键有： 1.字体样式太多，导致页面杂乱 2.使用的字体不易识别 3.字体样式和内容的气氛或规范不匹配 怎么避免这样的结果发生呢？ 通过设计经验可以帮助你做出更好的版式了解不同平台的常用字体设计规范
在每个项目设计中只使用1-2个字体样式，而在品牌字有明确的规范的情况下，只需要一种字体贯穿全文，通过对字体放大来强调重点文案。字体用的太多，越显得不够专业。 不同的样式的字体，形状或系列最好相同，保证字体风格的一致性。 字体与背景的层次要分明 确保字体样式与色调气氛相匹配 二.界面中文字使用的规则 在不同平台的界面设计中规范的字体会有不同，像移动界面的设计就会有固定的字体样式。网页中会有常用的几个字体，在这我和大家分别介绍一下。 以下是在 72像素/英寸下的规范 移动端常规字体 IOS:常选择华文黑体或者冬青黑体，尤其是冬青黑体效果最好。
软件界面设计规 1.界面规 1.1.总体原则以用户为中心。 设计由用户控制的界面，而不是界面控制用户。清楚一致的设计。所有界面的风格保持一致，所有具有相同含义的术语保持一致，且易于理解拥有良好的直觉特征。以用户所熟悉的现实世界事务的抽象来给用户暗示和隐喻，来帮助用户能迅速学会软件的使用。较快的响应速度。简单且美观。 1.2.原则详述 1.2.1.用户控制用户界面设计的一个重要原则是用户应该总是感觉在控制软件而不是感觉被软件所控制。操作上假设是用户--而不是计算机或软件--开始动作。用户扮演主动角色，而不是扮演被动角色。在需要自动执行任务时，要以允许用户进行选择或控制它的方式来实现该自动任务。提供用户自定义设置。因为用户的技能和喜好各不相同，因此他们必须能够个性化界面的某些方面。Windows为用户提供了对许多这方面的访问。您的软件应该反应不同的系统属性--例如颜色、字体或其他选项的用户设置。采取交互式和易于感应的窗口，尽量避免使用模态对话框，而使用"非模式"辅助窗口。"模式"是一种状态，它排除一般的交互，或者限制用户只能进行特定的交互。当最好使用一个模式或该模式只是可替换的设计时--例如，用于在一个绘图程序中选定一个特定感觉--请确保该模式是显然的、可见的，是一个明确的用户选定的结果，并且容易取消。在后台运行长进程时，保持前台式交互。例如，当正在打印一个文档，即使该文档不能被改变，用户也应该可以最小化该窗口。谅解。用户喜欢探索一个界面，并经常从尝试和错误中学习。一个有效的界面允许交互式的发现，它只提供一组合适的选择，并在用户可能破坏系统或数据的情况时发出警告。如果可行，还应提供可逆转或可还原的操作。即使在设计得很好得界面中，用户也可能犯错误。这些错误既可以是物理上得（偶然地指向了错误的命令或数据），也可以是逻辑上的（对选定哪一个命令或哪些数据做出了错误的决定）。有效的设计避免很可能导致错误的情况。它还包容潜在的用户错误，并且使用户易于还原。 1.2.2.清楚一致的设计一致允许用户将已有的知识传递到新的任务中，更快地学习新事物，并将更多的注意力集中在任务上。这是因为他们不必花时间来尝