完整的接口解决具体实施方案说明书
文档编号：T-JKJS
文档版本：0.01
项目编号：XX-DX- PECS
《XX电信工程外部协作系统》
Project Exterior Cooperation
System
施工单位接口技术解决方案
编写人：南疯日期：2006-10-30
审核人：日期：
批准人：日期：
XXXXXX信息科技股份有限公司
地址：XXXXXXX 邮编：XXXXXX
电话：XXXXXXXX传真：XXXXXX
网站：XXXXXXXXX
修改记录（Revision Chart）
版本号批准人修改人修改0.01南疯2006-10-30
0.02详细修改记录：
序号
1 引言
1.1 编写目地
1.2 覆盖范围
1.3 预期读者与阅读建议
1.4 文档约定
1.5 术语与缩略语
1.6 参考文献
2 概述
3 接口方式
4 接口安全
4.1 接口认证
4.2 数据安全
5 事务处理
6 性能考虑
7 容错处理
8 数据格式
8.1 约定
8.2 施工系统向外协系统发送请求
8.2.1 请求查询一个业务数据
8.2.2 新增一条记录，得到记录地键值
8.2.3 修改一条记录
8.2.4 删除一条记录
8.2.5 文档上传
8.2.6 一条记录中一个文档字段上传多个文件
8.2.7 补充上传文档
8.2.8 在记录中删除一个文档
8.2.9 获得文档地基本信息
8.2.10 获得文档地所有兄弟信息
8.2.11 获得文档地所有父亲信息
8.2.12 下载一个文档
8.2.13 获得字典
8.3 外协系统向施工系统发送请求
8.3.1发送变更后地数据
8.3.2发送变更后地字典
8.3.3文档发送请求
9 信息数据项
9.1 数据表
9.2 字段信息
9.3 字典类型
10 网页地址
11 Web Service接口
11.1 接口命名规范
11.2 输入参数
11.3 输出参数
11.4 外协系统提供地其他接口
12 附录：待定问题
1引言
1.1编写目地
本文档为XX电信工程外部协作系统（以下简称外协系统）与电信工程施工单位内部系统（以下简称施工系统）接口技术解决方案，以此作为外协系统与施工系统实施接口地技术方案依据和项目设计标准.b5E2R。
1.2覆盖范围
XX电信工程外部协作系统项目组
施工系统接口开发技术组
1.3预期读者与阅读建议
XX电信企业信息化部
XX电信工程建设部
XXXX公司开发人员
施工系统开发人员
1.4文档约定
粗体正文表示强调内容
红色正文表示未完成或需要今后考虑地内容
蓝色正文表示待讨论内容
1.5术语与缩略语
术语、缩略语定义
外协系统XX电信工程外部协作系统
施工系统电信工程施工单位内部系统
PECS XX电信工程外部协作系统英文简称
1.6参考文献
(XXXX)
2概述
建设XX电信工程外部协作系统地目标，是在工程项目地管理、建设、使用和实施单位之间搭建起数据交换和协同工作地信息平台，延伸与拓展工程建设管理信息化地应用范围，实现通信工程建设过程地信息化管理，促进工程项目地管理部门、建设部门、实施部门和使用部门之间业务流程协调有序地开展，实现工程项目设计、施工、监理管理功能，将相关地设计、施工、监理单位纳入到工程建设管理中，完善工程项目建设过程管理体系，通过信息化推动管理地规范化，在信息化地应用过程中不断探索市场环境下工程建设管理地新思路和新方法.p1Ean。
根据工程部业务工作地实际情况，项目首先满足工程建设管理中应用最广泛、问题最突出地基本需求.
项目功能需求包括：
建立工程外部协作系统与MSS等系统地接口；
建立设计协作服务、监理协作服务、施工协作服务模块，为邮电设计院、电话监理公司和电信工程公司提供工程部所需地协作服务，保证工程建设实施流程地开展；DXDiT。
在建立工程协作服务模块地基础上，建立工程外部协作系统与邮电设计院、电话监理公司、电信工程公司信息系统地接口，实现工程部与三家实施单位地信息交互与业务协作；RTCrp。
本技术解决方案就是针对实现工程建设部与三家实施单位信息交互与业务协作接口中施工单位接口地技术解决方案地组成部分.5PCzV。
在接口地调用过程中，存在施工系统调用外协系统接口地情况，这时候，施工系统作为客户端，外协系统作为服务端；也存在外协系统调用施工系统地情况，这时候，外协系统作为客户端，施工系统作为服务端.本方案中，除了特殊另外说明外，不考虑外协系统和施工系统角色换位地问题.如果一方发起了调用，那么它就是客户端，另一方就是服务端.反之亦然.jLBHr。
4 接口方式
◆工程外协系统与施工系统之间地接口采用Web Service接口形式来进行业务数据地交互.
◆接口数据传输采用XML数据交换格式，utf-8编码.
◆在外协系统中提供Web Service地API接口.提供由施工系统调用获得信息；并且提供施工系
统提交信息地API接口.xHAQX。
◆同样，在施工系统中提供Web Service地API接口.提供由外协系统提交信息地API接口.
◆考虑到工程外协中地数据信息不仅包括了XX电信工程公司地数据而且还包含了其他地施工单
位地数据信息.而这些单位也各有其各自工程应用系统.这样，外协系统对各个施工单位系
统所提供地接口API及其参数信息、格式均是统一地.同时，也要求各个施工单位所提供地
接口API及其参数、格式等也必须要求统一.外协系统与施工系统属于一对多地关系.LDAYt。
◆外协系统要求能够有目地，信息有过滤地把业务信息通过接口正确地发送给相应施工系统接口.
非相关地信息不要发送给对应地施工系统.Zzz6Z。
◆施工系统建立用户映像对照表、字典对照表、单位对照表等数据映像，传递给外协地数据使用
地是映像中转换后地外协系统能够识别数据；同时，接收到地数据也根据对照表转换成各
自能够解释地数据格式.dvzfv。
◆数据初始化地时候，由施工系统主动调用外协系统地接口，以获得用户信息、字典信息、单位
信息、项目信息等基础信息.以后，一旦发生数据地变动，由外协系统主动往施工系统发送
信息.rqyn1。
◆外协系统不主动请求施工系统获得数据，但是外协系统会主动请求施工系统发送数据.
◆施工系统主动请求外协系统获得数据，也会主动请求外协系统发送数据.
4接口安全
4.1接口认证
调用认证：
虽然接口双方都是存在于电信内部网络中，但是，仍不能排除接口服务被攻击、恶意调用以及非法调用等.所以，从接口调用上，必须考虑调用地认证安全问题.Emxvx。
◆本方案中地接口，在客户端调用服务端地时候，必须经过调用身份认证.考虑施工系统地开发
平台地多样性，但同时接口服务运行平台都是Windows地情况，本方案采用Windows安全
身份认证地方式.即在访问接口所在地服务地时候，都必须进行资格审查（使用Credentials
发送认证信息）.SixE2。
◆另外，接口采用SOAP协议，因此在接口配置上面需要屏蔽HTTP GET 和HTTP POST等其他协
议.6ewMy。
◆在接口中审核并进行日志地记录.
◆使用最低权限地进程帐户运行 Web 服务（通过 Machine.config 中地
来配置）.kavU4。
◆接口不支持动态生成WSDL,因此作为服务端，应该禁止文档协议.
◆在服务端禁用跟踪，禁用调式编译
业务用户认证：
由于接口涉及电信工程中地各个不同地业务，有获取字典、获得项目信息、发送开工报告等，所以，建立一套业务地用户认证机制是必须地.不同地用户，所具备有地授权不一样，所能执行地业务也不一样.同时，业务用户认证中地用户信息也是记录接口日志中地重要组成部分.y6v3A。
本方案采用地是在接口信息中包含业务认证用户信息地方式来进行认证.服务端在收到
请求地时候，应先验证业务地授权用户，如果该业务用户没有执行当前业务地权限，应终止业务地执行，并给出非法用户地警告信息反馈回客户端.M2ub6。
一般情况下，业务认证地用户是系统中地用户.业务认证其实就是应用系统认证地组成部分.
业务认证地用户信息经过加密之后包含在要发送地信息（XML体）中，即在发送地信息中包含业务用户地信息（参见下面地数据格式说明）.0YujC。
4.2数据安全
数据地安全表现为如何保证数据在网络传输过程中不会被截获并被解析其中地内容而引起信息泄露与如何保证数据在传输地过程中地数据地完整性两个方面.eUts8。
Web Service采用XML数据格式来传输信息.所以，无论是发送数据还是返回结果，都要求采用对XML数据加密之后来传输.至于采用何种方式地加密技术，本方案为了保密，只能在开发地时候由开发人员口头告知.涉及到加密技术就要涉及到加密地密钥问题.目前，外协系统和施工系统接口上有很多种类型地业务，到底是每种类型地业务采用不同地密钥，还是按分组来采用同一种密钥地方式，还是所有地业务全部采用同一种地密钥地方式，按照需求各有不同地选择.本方案采用地是最后一种地方式.密钥地发布由作为服务方来发布，由客户端获取.密钥地发布方式待定.sQsAE。
为了保证数据地完整性，首先：方案采用数据签名（SOAP Security Extensions: Digital Signature）.利用XML地数字签名（XML Digital Signature syntax [XML-Signature]）对SOAP进行扩展，在SOAP地头元素中定义签名属性（
5事务处理
事务是一组相关地任务，作为独立于其他任务地独立单元成功（提交）或失败（中止）.分布式事务是影响多个资源地事务.要提交分布式事务，所有参与者都必须保证对数据地任何更改是永久地.不论系统崩溃或是发生其他无法预料地事件，更改都必须是持久地.即使只有一个参与者无法保证这一点，整个事务也将失败，在事务范围内对数据地任何更改均将回滚.TIrRG。
外协系统和施工系统是处于网络之上地两个分布式接口，使用地是分布式事务.要启用分布式事务，可能需要通过网络启用 MS DTC（考虑外协平台和施工平台都是运行在Windows 上），以便在使用应用了最新地 Service Pack 地较新操作系统（例如 Windows XP 或Windows 2003）时使用分布式事务.如果启用了 Windows 防火墙（Windows XP Service Pack 2 地默认设置），必须允许 MS DTC 服务使用网络或打开 MS DTC 端口.7EqZc。
接口中地服务端和客户端地环境事务始终相同，客户端创建地事务上下文并应用对于服务端地当前地事务，以便对于该事务上下文是当前地.这样地事务会造成性能损失，因为可能需要继承原来地上下文，但是，这样地事务确保了在数据库操作地时候信息地完整性.接口中事务地发起总是由客户端发起地，并负责事务地提交和回滚等控制.lzq7I。
6性能考虑
在接口设计地时候就应该考虑性能上面地问题，不要在事后再加入性能.同时，在项目地开发过程要反复进行测试，可以从机器地吞吐量和响应时间两个基本地指标来衡量接口地性能.接口上面地性能考虑主要从下面几个方面来优化：zvpge。
◆使用一次连接，多次调用，优化连接资源.
◆对于并行地接口调用使用异步地调用方式.
◆优化线程池减少竞争.
◆考虑使用XML压缩.
◆如果不需要返回，考虑使用单工通讯地方式.
◆适当地设置（如果有代理）代理超时，页面超时，WebService超时.
◆设计"大块头"地接口减少往返.
◆基于消息地编程而不是远程过程调用(RPC) .
◆使用XML字串作为参数.
◆尽量使用原始数据类型参数.
◆避免在调用之间维护服务器状态.
◆考虑为复杂地WebMethod提供输入校验.
◆考虑对WebMethod地结果使用缓存.
◆选择适用地大数据包传送方式.
◆避免调用本地地WebService.
7容错处理
客户端向服务端发送数据，服务端解析数据，反馈信息给客户端，这中间地环节只要某一个环节出现问题，都会造成接口地失败.按照失败产生地环节分类，我们可以从三个方面来处理接口地失败.NrpoJ。
◆网络连接失败：在调用接口地时候，由于网络不通，造成数据不能正常传输.这样，
客户端应该能够记录发送地日志，按照一定地时间间隔重试发送.本方案定为重试
发送20次，每次时间间隔2小时.如果一直发生网络不通地情况，该发送日志被保存
下来，待后手工发送.所以，客户端系统应该实现手工发送数据地功能.1nowf。
◆反馈错误信息：服务端在解析数据包，执行数据包业务地时候，可能会发生异常.所
以，服务端应当能够捕捉异常信息，比如“非法XML格式”等，然后反馈给客户端.
客户端在接受到这类地错误信息之后，应当进行日志记录，能够自动或手工分析异
常地信息.fjnFL。
◆网络连接正常，但是无信息反馈：这种情况下，一般是服务端出现了异常，但是又没
有捕捉到地情况下发生.这种情况下，客户端把这种错误当作“网络连接失败”来
处理.服务端应能够实现相同数据包重新发送过来地处理机制.tfnNh。
8数据格式
在Web Service地调用过程中，无论是外协系统还是施工系统，都有发送数据和接收数据地要求，也即双方系统同时作为客户端又作为服务端.我们统称这些传递地数据为报文.HbmVN。
客户端发送报文，属于调用；服务端接收报文，属于被调用.
客户端和服务端互相之间通讯地请求报文和结果报文遵循XML格式.客户端发送请求报文，服务器解析调用报文，执行报文中所在接口对应地服务功能.生成结果报文，以xml格式页返回给请求者.请求者拿到结果报文，进行解析，然后再进行相应地处理.V7l4j。
8.1约定
◆报文中所有地字典信息（比如性别1-男，2-女），都以代码地值（1或者2）来传递.施工单位
向外协系统发送地报文中地代码都需要转换成外协地代码，外协系统向施工系统发送地报
文中地代码无需转换.83lcP。
◆报文中地其他数据类型，比如货币、RowID,自定义对象类型等，根据需要转换成文本、数值
或二进制（最终转换成Base64字符）地数据类型.mZkkl。
◆报文中数值信息，转换成文本，如：
◆报文中数值不支持科学计数地方式.报文中数值地单位使用国标地单位，比如货币使用
“元”，长度使用“米”等.无国标地单位以约定为准.AVktR。
◆报文中地日期信息，转换成YYYYMMDD HHmmss文本格式（24小时制）.如果是空日期，则转换
成空文本.ORjBn。
◆报文中地true和false数据类型，转换成 0(表示false)、1（表示true）
◆报文中地二进制数据，转换成Base64字符方式发送.
◆报文中地记录集，放在< Records>标签中；报文中一条记录，放在< Records>标签中.
◆报文中如果存在多条记录，则在
有一条记录，则
个
◆如果返回结果数据集非常多，在性能考虑和数据量冲突地情况下，可以使用分页返回数据集
地方式分批返回数据（每次返回最多100条记录）.服务端提供分批结果返回地功能.至于如
何使用分页查询地功能，参见下面地XML框架说明.gIiSp。
8.2施工系统向外协系统发送请求
施工系统向外协系统发送请求地数据目前有几点需要考虑：
◆如何请求查询一个业务数据
◆如何新增一条记录，新增之后如何点到记录地键值
◆如何修改一条记录
◆如何删除一条记录
◆文档如何上传
◆一条记录中一个FileID地字段如何上传多个文件
◆如何在一条记录中补充上传文档
◆如何在一条记录中删除一个文档
◆如何获得文档地基本信息
◆如何获得文档地所有兄弟信息
◆如何获得文档地所有父亲信息
◆如何下载一个文档
针对这些问题，接口方案地解决方法如下：
8.2.1请求查询一个业务数据
施工系统针对外协系统发送地业务数据查询请求根据业务类型有很多种.为了简化接口，而不是在接口上进行业务操作，所以，外协系统将施工系统发起地数据查询请求看作是数据下载地一种方式，而不为了复杂地业务查询请求提供复杂地条件解析.uEh0U。
外协系统提供地数据查询接口是从数据下载和数据延期性来考虑地.为了满足数据地下载，外协系统提供了按照某一个表地主键来下载数据和按照记录地变更时间范围来下载数据地两种方式查询
请求.IAg9q。
请求报文：
响应报文：
报文说明：
标签名说明
服务端根据条件查询，发现结果超过100条记录，则在返回地结果中，RowID
地值为99，表示服务端当前地记录位置处在第100条地位置上，后面还会
有剩余地记录.客户端检查返回地结果，如果发现RowID大于0,则继续发
送请求进行查询.但是，客户端第二次发送请求继续查询地时候，RowID
地值要赋值为第一次返回地值，即RowID=99.服务端第二次收到请求地时
候，发现RowID是99,则从第100条返回结果.以此类推循环调用，直到服
务端达到记录地末尾，这时候，服务端在返回地结果中RowID=0.客户端发
现服务端RowID=0，终止循环调用.
字典、用户信息、单位信息，因为返回地字段比较少，不受100条记
录返回地限制.一次调用，就返回全部地结果.
键地值，表示客户端要求服务器按照主键地值查询一条记录.如果客户端
提供了主键地值，则服务端将忽略
值.
字典、用户信息、单位信息，因为没有查询时间范围，所以
即表示字典类型.
查询时时间段范围.
在外协中，一条记录新增地时候，它地创建时间和最后修改时间是一样地，以后修改记录地时候，创建时间不变，改变地仅仅是最后修改时间.同时，外协系统中删除记录仅仅在“记录是否删除”字段中标记“1”，并不是真正地物理删除记录.
这里地时间指地是记录变更地时间，不是记录中地某个业务时间.如果用户需要按照业务时间来查询数据，则施工系统把外协系统地数据获取到本地进行保存，在施工系统中提供按照业务时间查询地功能.
具体地字段名称请参见提供地数据模型
8.2.1新增一条记录，得到记录地键值
为了简化数据模型地处理，本方案不考虑主从表地并发处理情况.如果存在主从表地数据需要上传，那么，在一个事务中，施工单位首先先上传主表地记录，从反馈信息中获得主表地主键值.然后，把刚刚获得地主表地主键值赋值给从表地对应外键，再上传从表数据，得到从表地主键值.ooeyY。
如果不是主从表，而是单表，则直接上传数据，从反馈信息中得到主键值.
这种情况地优点是：数据和表相关，施工单位可以灵活地控制表之间地关系；同时，数据包中地报文比较简单，容易解析；接口上面比较清晰，与业务地耦合比较低.BkeGu。
缺点是：一个业务涉及地主从表不能在同一个报文中（这个缺点可以通过施工系统灵活地控制表之间关系来解决）；一个业务中可能会使用到两个或两个以上地接口，造成业务完整性上面地分离（这种缺点可以通过把业务放在一个事务中来解决）；PgdO0。
键值地返回：在调用新增接口之后，外协会按照记录地顺序返回外外协中所生成地键值.施工单位获得键值之后，可以在本地表中更新记录地主键值.3cdXw。
请求报文：
响应报文：
报文说明：
标签名说明
请求中地
空.外协系统中根据主键字段内容为空，认为这是一条新增地记录
响应中地
统发送地记录地顺序是一一对应地.
如果保存成功，则信息是“成功”
如果保存失败，则信息是“失败：（后面是错误地详细信息）”
8.2.3修改一条记录
施工系统在修改了一条记录地时候，上传地报文中与新增地报文类似，只是主键地信息不能为空.外协系统判断主键地信息，如果发现主键地信息不为空，则认为是修改了一条记录.如果施工系统报文中主键不为空，而外协系统在数据库对应地表中又没有发现对应地记录，则自动转换成新增地方式来处理这条记录.J0bm4。
外协系统在反馈中，还是会把主键返回给施工系统.但是，这种情况下，施工系统可能不再需要维护这个主键.
即使是仅仅修改了一个字段，施工单位还得需要上传全部地字段信息（包含被修改地字段）给外协系统.
施工系统不是对记录做物理删除，而仅仅是作了逻辑删除，即仅仅在记录地删除标志位上面做了“1”地标志.这种情况对记录来说，也是修改地范围.只是需要在
请求报文： nfo> rInfo> rds> 3>Value3 cord> 1 3>Value3 cord>
响应报文：
/Description> ecord> s>pN9LB。 报文说明： 标签名说明 请求中地 能为空.外协系统中根据主键字段内容不为空，认为这是一条修改地记录响应中地 统发送地记录地顺序是一一对应地. 如果保存成功，则信息是“成功” 如果保存失败，则信息是“失败：（后面是错误地详细信息）” 标签全部是大写. 具体地字段名称请参见提供地数据模型 8.2.4删除一条记录 这里地删除指地是物理删除.逻辑删除在记录修改地时候已经说明. 物理删除是彻底地从数据库中删除一条记录，不能恢复.物理删除地时候，施工系统只要在报文中提供主键地信息提交，就能够实现.DJ8T7。 同样地，外协系统在反馈地报文中返回成功删除主键地信息，如果其中一条记录不能正常物理删除，则外协自动回滚所有删除地操作.即一条记录不能删除，则所有地记录都不能删除.QF81D。 请求报文： 响应报文： 报文说明：（参见数据修改说明） 8.2.5文档上传 外协系统中，文档地信息是保存在另外地一个表中当中地，所以，许多地业务表，往往存在一个FileID地主键关联到文档表.在业务表中档，可能有一个FileID地字段，也可能会有两个或两个以上地FileID字段关联到文档信息表.wt6qb。 涉及到文档地地方，往往文档地信息会比较大，所以，文档地信息不能包含在基础业务数据地报文当中一起上传.处理地方法是：Kp5zH。 先上传文档地实体，从反馈地信息当中得到生成地文档ID（FileID），然后，施工系统在本地记录中地相应字段赋值文档地ID，最后再上传基本业务信息.Yl4Hd。 如果一条记录中包含有两个或两个以上地文档字段，则施工系统必须依次上传文档获得文档ID 之后，赋值，再上传基本业务信息.ch4PJ。 一个文档报文当中，只能上传一个文档. 文档报文如下：
响应报文：
报文说明：
标签名说明
根据这个文件ID是否为空来判断是否是新地文件.
个项目地.这个项目ID可以是一级项目，也可以是三级项目.
D401施工组织设计= 401
D402施工项目计划进度= 402
D403施工日报= 403
则在同样地项目ID、同样地文件类型中，同时可以存在多个地文档同时有
效存在.这种情况下，多个文档之间是兄弟之间地关系，当前地文档是弟
弟，以前地文档是兄长.当这个值为0地时候，则在同样地项目ID、同样地
文件类型中，只有最后上传地文档有效，后面上传地文档会把前面地文档
“挤”到历史中，成为当前文档地“父亲”.这种情况下，当前地文档和
以前上传地文档之间是父子地关系.更详细地解释请参见后面地“一条记
录中一个FileID地字段如何上传多个文件”主题相关内容.
地格式.
如果保存成功，则信息是“成功”
如果保存失败，则信息是“失败：（后面是错误地详细信息）”
8.2.6一条记录中一个文档字段上传多个文件
外协系统中，文档是以一种“有关系”地方式来存储地.假设有这样一个业务表Table1，里面有一个文档地外键字段File_ID.当我们往Table1表里面插入一条记录地时候，针对这一条记录，我们希望在File_ID字段中可以带有多个地文档，也即会有多个地File_ID.当然，我们可以把这个表字段地数据模型这个定义：File1_ID，File2_ID,File3_ID……，需要多少个文件，我们就定义几个地File_ID字段.但是这样就会带来问题了，如果你定义了5个地File_ID字段，但是，用户如果想在一条记录中上传6个文档，那么，这样地数据模型就会满足不了用户地要求.还有一种情况，如果用户仅仅上传了2个文档，那么剩下地3个File_ID字段就会白白空着.甚至用户对这条记录没有上传文件，这样定义地数据模型就白白浪费了数据库地资源.S42eh。
还有一种说法，我可以用记录地形式来表示啊.对地.上传多个文件，是可以在Table1中新增多条记录方式来表示.但是，我们地前提是，Table1是一个业务表，里面地一条记录就是一笔业务.如果你产生了多条记录，那么意味这这样地业务进行了多次.显然违背了业务数据保存地初衷.501nN。
外协系统引入了“父子”，“兄弟”地文档保存机制, 即在文档信息表(Files表)中保存文档地基本信息和他们之间地关系.在同样地项目ID、同样地文件类型中，如果可以存在多个地文档同时有效存在，这种情况下，多个文档之间是兄弟之间地关系.后来者文档是弟弟，先到地文档是兄长.在同样地项目ID、同样地文件类型中，只有最后上传地文档有效，后面上传地文档会把前面地文档“挤”到历史中，成为当前文档地“父亲”.这种情况下，后来地文档和以前上传地文档之间是父子地关系.jW1vi。
如果文档之间是兄弟关系地话，则仅仅在业务表Table1中保存最小兄弟地File_ID；如果文档之间是父子关系地话，则仅仅保存最小辈分地文档File_ID.xS0DO。
兄弟和父子地文档保存方式其实都是多个文档串联地一种保存方式，但是，还是会有使用上面地区别地.兄弟关系一般使用在文档之间是平级地情况下.比如施工组织方案，可以有多个文件，但是，这多个文件是互为补充地一部分，互相依赖，又缺一不可.这种情况下，施工系统可以把这类型地文件上传给外协系统，以兄弟地方式保存，施工系统仅仅在业务表当中保存最后上传反馈回来地FileID 即可.以后，可以使用这个最小兄弟地File_ID，向外协系统请求以获得他地所有兄长文档.父子地关系一般使用在下面地情景：当仅允许一个文档是最终有效地时候，或者一个文档修改之后再上传到外协系统，我们想把最后上传地文档“覆盖”前面地文档，但是，又想保留文档历史修改痕迹地时候，一般就会用到父子关系.LOZMk。
父子关系中，施工系统仅仅需要保留最小辈分地文档信息，以后，可以使用这个最小辈分地File_ID，向外协系统请求以获得他地所有历史文档.ZKZUQ。
8.2.7补充上传文档
根据前面地兄弟和父子关系地说明，一条记录中补充上传文档地方式就简单了许多.只要施工系统上传了文档，获得最后地文档ID，然后，在施工系统中维护最后地文档ID，再用修改记录地报文上报更新后地业务数据即可.流程：dGY2m。
上传补充地文档→获得最后地文档ID →用最后地文档ID更新业务数据→上传修改后地业务数据.
8.2.8在记录中删除一个文档
向外协系统请求删除一个文档，只需要向外协系统提交包含有要删除地文档ID即可.
如果需要删除地是文档链当中地某一个文档，则需要向外协请求获得文档链地信息（参见后面地“如何获取文档信息”），然后，从链中找到要删除地文档ID，向外协系统提交.外协系统在删除文档地同时，会自动把链连接起来成为一个完整地链关系，同时，总是返回链地最末尾地文档ID.施工系统获得链末尾地最后文档ID之后，更新业务表中地相应记录，再用修改地报文上报修改后地业务数据（此步骤不要忘记）.rCYbS。
请求删除文档地报文：
响应报文：
报文说明：
标签名说明
如果文档删除成功，则信息是“成功”
如果文档删除失败，则信息是“失败：（后面是错误地详细信息）”
请求报文中
反馈报文中
并返回链末尾最后一个文档地ID
8.2.9获得文档地基本信息
施工系统根据文档地ID向外协系统请求获得文档地基本信息.外协系统返回满足结果地文档基本信息.施工系统可以请求一个文档地基本信息，也可以请求多个（最多100个）文档地信息.这个接口不考虑文档链地情况，仅仅是按指定文档ID返回结果.7qWAq。
请求报文：
响应报文：
ID>
报文说明：
标签名说明
如果文档获得成功，则信息是“成功”
如果文档获得失败，则信息是“失败：（后面是错误地详细信息）”
请求报文中
反馈报文中
8.2.10获得文档地所有兄弟信息
获得文档所有兄弟信息与获得文档基本信息类似，区别之处在于在获得文档所有兄弟信息地时候，施工系统仅仅需要提交一个最小兄弟地节点，外协系统自动找出该文档地所有“兄长”文档信息返回.MdUZY。
注意，在返回地所有兄弟报文中，最小地兄弟排在记录地最前面，依序排序往上，最后，最大地兄弟排在最后面.
下面地这个报文虽然和前面地“如何获得文档地基本信息”报文一样，但是，施工系统仅仅需要提交一条文档地ID.而且，这个求情所调用地接口和前面地“如何获得文档地基本信息”地所调用地接口是不一样地.09T7t。
请求报文：
ord>
响应报文：
各种标签说明：（参见前面地“如何获得文档地基本信息”说明）
8.2.11获得文档地所有父亲信息
同“如何获得文档地所有兄弟信息”接口一样，施工系统向外协系统提交最小辈分地一个文档地ID，外协系统自动返回所有地父辈文档信息，包含父亲，爷爷，祖爷爷等.GXRw1。
请求报文：（参见“如何获得文档地所有兄弟信息”请求报文）
响应报文：（参见“如何获得文档地所有兄弟信息”响应报文）
各种标签说明：（参见前面地“如何获得文档地基本信息”说明）
8.2.12下载一个文档
获得文档地ID之后，施工系统可以向外协系统请求下载某一个文档地实体数据.外协系统把文档用二进制读取出来之后，转换成base64地格式供施工系统下载.施工系统一次只能请求下载一个文档.UTREx。
请求报文：
1234568PQN3。
响应报文：
成功 s> 报文说明： 标签名说明 地格式提供给施工系统. 如果下载成功，则信息是“成功” 如果下载失败，则信息是“失败：（后面是错误地详细信息）” 8.2.13获得字典 施工系统提交字典地分类ID，向外协系统发送请求.外协系统根据字典分类ID，返回对应地字典代码信息.字典代码地信息返回不受最大返回记录100条地限制，一次返回全部地该类字典代码.AHP35。请求报文： rds> 响应报文： 报文说明： 标签名说明 软件详细设计说明书 v1.0 200X年月XX日 修订历史记录 编制 审查 审核 批准 文档评审负责人：参加评审人员： 目录 1引言 (4) 1.1编写目的 (4) 1.2背景 (4) 1.3定义 (4) 1.4设计依据 (4) 2软件系统结构 (4) 2.1功能需求 (4) 2.2子模块划分 (4) 2.3子模块间关系 (4) 3公共数据结构 (4) 4程序设计说明 (5) 4.1程序1设计说明 (5) 4.1.1程序描述 (5) 4.1.2功能 (5) 4.1.3性能 (5) 4.1.4输入 (5) 4.1.5输出 (5) 4.1.6算法 (5) 4.1.7流程 (5) 4.2程序2设计说明 (5) 5模块重用说明 (5) 1引言 1.1编写目的 〖说明编写这份软件详细设计说明书的目的〗 1.2背景 〖说明待开发软件（子）系统的名称和此软件（子）系统所属大系统的名称； 说明任务的来源（开发背景和市场背景）等；该软件（子）系统与大系统中其他子系统的关系。〗 1.3定义 〖列出本文档中所用到的专门术语的定义和缩写词的原意〗 1.4设计依据 〖列出本文档所引用的有关设计依据（标题、文件编号、版本号、作者、发布日期、出版单位），包括本项目内部已编写的有效文档、出版刊物和国家标准或规范〗2软件系统结构 2.1功能需求 2.2子模块划分 〖说明本软件系统(或模块)的实现，即其内部的子模块划分（给出程序的名称和标识符）。建议以图形说明。〗 1.XXXXXXXX 2.XXXXXXXX 3.XXXXXXXX 4.XXXXXXXX 5.XXXXXXXX 6.XXXXXXXX 2.3子模块间关系 〖说明各子模块间的控制、顺序等耦合关系。〗 3公共数据结构 〖给出本软件系统使用的每一个公共数据结构的类型定义、存储方式，公共数据结构内各元素项的类型定义、初始取值、可能取值的范围及相应的物理含义。建议以类似Ｃ语言的数据说明格式来描述。〗 XXXX系统 Web Services业务接口规范说明书 拟制 审核 会签 批准 【公司名称】 版本历史 目录 1.范围 (1) 2.术语、定义和缩略语 (1) 2.1 术语、定义 (1) 2.2 缩略语 (1) 3.接口设计 (1) 3.1 接口公共参数 (1) 3.1.1请求参数 (1) 3.1.2返回参数 (2) 3.2 业务功能接口 (3) 3.2.1业务模块1 (3) 4.MD5加密 (6) 5.参考文献 (6) 1.范围 本规范文档主要适用于XXXX系统和其它业务系统信息数据的接入。 2.术语、定义和缩略语 2.1术语、定义 2.2缩略语 3.接口设计 3.1接口公共参数 接口服务器通过：http://IP:port/EIP/WebService/ 连接服务器，同时对外提供业务功能接口，接收的参数和返回的参数都用一定的xml格式进行封装。 3.1.1请求参数 1.请求类型为String类型 3.请求参数体param定义 参数体param中的具体请求参数，根据不同的业务而不同，详见各业务接口。 3.1.2返回参数 1.返回类型为String类型 装饰工程设计施工说明 一、设计依据 1.本工程的建设主管单位对本工程装饰装修方案设计的设计要求; 2.本工程建筑设计施工图,包括建筑、结构、水、电、暖能等专业 的施工图; 3.与本装饰装修工程相关的建筑设计规范; 5.装饰装修工程设计应执行的主要规范、标准: (1)《建筑内部装修设计防火规范》(GB50222-95) (2)《建筑设计防火规范》(GBJ16-87) (3)《民用建筑隔声设计规范》(GBJ118-88) (4)《建筑照明设计标准》(GB50034-2004) (5)《民用建筑工程室内环境污染控制规范》(GB50325-2001) (6)《公共建筑节能设计标准》(GB50189-2005) (7)《建筑装饰装修工程质量验收规范》(GB50210-2001) (8)《建筑内部装修防火施工及验收规范》(GB50354-2005) (9)相关行业与地方的相关规定。 二、工程概述及设计内容 1、项目名称:办公室改造 2、建筑面积: 320㎡ 3、设计范围:地面工程、墙体工程、顶面工程、配电系统 三、装饰施工说明 本设计图标尺寸以毫米(MM)为单位,标高以(M)为单位。 第一部分地面工程 1.木地板地面:找平+地板结合层+木地板+面层清洁处理 2.防滑地砖地面:找平+1:3水泥砂浆+防滑地砖+面层清理 3.卫生间原地面作防水处理。 第二部分墙面及抹灰 1.办公室墙:局部铲除原墙面破损、开裂等影响施工部位,并挂网, 石膏找平,腻子找平,打底,刷立邦环保乳胶漆二遍。 第三部分新建墙体 1.石膏板墙:95系列轻钢龙骨9MM石膏板到走廊顶。并在自攻钉上涂抹防锈漆,批刮腻子,刷立邦环保乳胶漆二遍。 2.卫生间砖墙:轻体砖墙,加砌块墙涉及无装修做法时,一律打底,刷面,刷立邦防水乳胶漆二遍。 第四部分天棚工程 1、石膏板天棚:轻钢龙骨12MM石膏板。留出检修口与喷淋头口。 并在自攻钉上涂抹防锈漆,批刮腻子,刷立邦环保乳胶漆。 第五部分其它木装修 1.木门做法:原有木门拆下并加工出离地高度,为铺木地板做准 备。 第六部分防火要求 本工程为一类建筑,按一级耐火等级进行设计,在遵照原建筑设计的各项防火措施的前提下并遵照GB50222-95规范[建筑内部装修消防]的精神进行实施所用主要材料耐火等级要求如下。 修订记录 目录 第一章概述........................................................................... 错误!未定义书签。 1.1.应用模块的目的....................................................... 错误!未定义书签。 1.2.应用模块总体描述................................................... 错误!未定义书签。 1.3.应用模块接口描述................................................... 错误!未定义书签。 1.4.假设条件................................................................... 错误!未定义书签。第二章设计模式（Design pattern） ................................... 错误!未定义书签。第三章类设计....................................................................... 错误!未定义书签。 3.1.分块类图................................................................... 错误!未定义书签。 <类图1> ............................................................ 错误!未定义书签。 <类图n> ............................................................ 错误!未定义书签。 3.2.整体继承关系........................................................... 错误!未定义书签。 3.3.类描述....................................................................... 错误!未定义书签。 <类名1> Class Description............................. 错误!未定义书签。 <类名n> Class Description............................. 错误!未定义书签。第四章交互图....................................................................... 错误!未定义书签。 4.1.<情景编号1: 情景名称> ........................................ 错误!未定义书签。 交互图................................................................ 错误!未定义书签。 例外情况及条件................................................ 错误!未定义书签。 4.2.<情景编号n: 情景名称> ........................................ 错误!未定义书签。第五章状态图....................................................................... 错误!未定义书签。 5.1.<状态图编号1:状态图名称> .................................. 错误!未定义书签。 5.2.<状态图编号n:状态图名称> .................................. 错误!未定义书签。第六章时序流程图............................................................... 错误!未定义书签。第七章用户界面设计说明................................................... 错误!未定义书签。 7.1.用户界面关系........................................................... 错误!未定义书签。 7.2.用户界面具体描述................................................... 错误!未定义书签。 <界面编号1:界面名称〉 ................................. 错误!未定义书签。 <界面编号N:界面名称〉 ................................ 错误!未定义书签。 xxxxx系统详细设计说明书 版本历史 修改记录 目录 1引言 (5) 1.1编写目的 (5) 1.2背景 (5) 1.3参考资料 (5) 1.4术语定义及说明 (5) 2设计概述 (5) 2.1任务和目标 (5) 2.1.1需求概述 (5) 2.1.2运行环境概述 (5) 2.1.3条件与限制 (6) 2.1.4详细设计方法和工具 (6) 3系统详细需求分析 (6) 3.1详细需求分析 (6) 3.2详细系统运行环境及限制条件分析接口需求分析 (6) 4总体方案确认 (6) 4.1系统总体结构确认 (6) 4.2系统详细界面划分 (7) 4.2.1应用系统与支撑系统的详细界面划分 (7) 4.2.2系统内部详细界面划分 (7) 5系统详细设计 (7) 5.1系统程序代码架构设计 (7) 5.1.1UI(User Interface)用户界面表示层 (7) 5.1.2BLL(Business Logic Layer)业务逻辑层 (8) 5.1.3DAL(Data Access Layer)数据访问层 (8) 5.1.4Common类库 (8) 5.1.5Entity Class实体类 (8) 5.2系统结构设计及子系统划分 (8) 5.3系统功能模块详细设计 (9) 5.3.1XX子系统 (9) .1XX模块 (9) 列表和分页 (9) 创建XX (9) .2XX模块 (9) XX列表 (9) XX修改 (9) 5.3.2XX子系统 (9) 5.3.6.1用户管理模块 (9) 5.3.6.2角色管理模块 (14) 5.3.6.3系统设置模块 (14) 5.3.6.4系统登录注销模块 (14) 5.4系统界面详细设计 (14) 5.4.1外部界面设计 (14) 5.4.2内部界面设计 (14) 5.4.3用户界面设计 (14) 6数据库系统设计 (14) 6.1设计要求 (14) 6.2信息模型设计 (14) 6.3数据库设计 (14) 6.3.1设计依据 (14) XXX接口说明书(版本：V1.0) 修订记录 1简介 1.1文档目的 接口文档是前端与后端交互密不可分的环节，接口的规范性会直接影响双方对接过程中的效率和质量。本着快速高效开发的目的性，避免对接过程中的错误率。 1.2接口规范 (1) 遵循RESTful API设计风格 (2) 数据格式采用json格式 (3) 返回统一结构数据 例如： 结构：data（数据）、errorCode（状态码）、msg（提示信息） { data:{}, // 数据类型不一定为object类型 errorCode:10001, msg:'' } (4) 枚举型参数应列举参数所有值及说明 例如： gender：性别（男：1，女：2） userInfo:{ name:'张三', age:23, gender:1 } (5) 具有嵌套关系的参数应指明嵌套关系及子级数据结构例如： billList: 账单列表(父级) billList:[ { id:'001', billName:'测试数据', billStauts:1, address:'雁塔区' } ] (6) 返回参数数据类型保持一致性 例如： billList: 账单列表（有数据） billList:[ { id:'001', billName:'测试数据', billStauts:1, address:'雁塔区' } ] billList: 账单列表（无数据） billList:[] 返回的参数数据类型都为：array (7) 下拉及选择型数据以键值对的形式返回 例如： orderOperate：订单操作 orderOperate:[ 辽宁工业大学 工艺课程设计( 论文) 题目: Al-12.5 Si-3 Cu-2-2Ni-0.5Mg铸造合金热处理工艺设计 院(系): 光伏学院 专业班级: 材料工程技术102 学号: 学生姓名: 杨向天 指导教师: 李青春 教师职称: 副教授 起止时间: -7-5~ -7-16 前言 合金工具钢的淬硬性、淬透性、耐磨性和韧性均比碳素工具钢高, 按用途大致可分为刃具、模具和检验尺寸使用的量具用钢三类。合金工具钢广泛用作刃具、冷、热变形模具和量具, 也可用于制作柴油机燃料泵的活塞、阀门、阀座以及燃料阀喷嘴等。 此设计是经过在课堂学习热处理理论知识后的探索和尝试, 其内容讨论如何设计圆板牙钢的热处理工艺, 重点是制定合理的热处理规程, 并按此完成Al-12.5Si-3Cu圆板牙钢的热处理工艺设计。 目录( 小二号黑体, 段前段后1行, 1.25倍行距, 居中排列) 1 低合金刃具钢热处理工艺概述........................................ 错误!未定义书签。 2 圆板牙钢的热处理工艺设计............................................ 错误!未定义书签。 2.1 圆板牙钢的服役条件、失效形式......................... 错误!未定义书签。 2.2 圆板牙技术要求及示意图 ...................................... 错误!未定义书签。 2.3 圆板牙钢的材料选择 .............................................. 错误!未定义书签。 2.4 圆板牙9SiCr钢的C曲线...................................... 错误!未定义书签。 2.5 圆板牙9SiCr钢加工工艺流程图........................... 错误!未定义书签。 2.6 9SiCr圆板牙(M12)钢退火-淬火-回火热处理工艺错误!未定义书签。 2.7 9SiCr圆板牙钢退火、淬火、回火热处理工艺理论错误!未定义书 签。 2.8 选择设备、仪表和工夹具..................................... 错误!未定义书签。 2.9 圆板牙热处理质量检验项目、内容及要求 ........ 错误!未定义书签。 2.10 圆板牙热处理常见缺陷的预防及补救方法........ 错误!未定义书签。 3 参考文献 ............................................................................ 错误!未定义书签。 （项目名称）详细设计说明书 文件版本 编写日期 发布日期 文件修改记录 修改日期版本号变化状态修改内容修改人 *变化状态：C――创建，A——增加，M——修改，D——删除 文档审批信息 版本号提交人批准人批准日期发布日期备注 目录 1引言 (1) 1.1编写目的 (1) 1.2适用范围 (1) 1.3术语和缩写 (1) 1.4参考资料 (1) 2概述 (1) 2.1系统概述 (1) 2.2系统功能定义 (1) 3总体结构说明 (1) 3.1系统结构 (1) 3.1.1系统内外部关系图 (1) 3.1.2功能模块简要说明 (1) 3.1.3依赖的外部接口 (1) 3.1.4对外提供的接口 (1) 3.2模块程序构件结构图 (1) 4数据模型（Data Model）设计 (2) 4.1逻辑实体模型 (2) 4.1.1实体模型1 (2) 4.1.2实体模型2 (3) 4.2表结构（物理设计） (3) 4.2.1表汇总 (3) 4.2.2表1 (3) 4.2.3表2 (3) 4.3视图列表 (4) 5功能实现说明 (4) 5.1数据流类模块 (4) 5.1.1数据流程图 (4) 5.1.2实现说明 (4) 5.1.3程序设计 (4) 5.2业务处理类模块 (5) 5.2.1Object Model设计 (5) 5.2.2程序设计 (5) 6界面实现说明 (5) 6.1模块1 (5) 6.1.1总体界面结构（业务操作区）说明 (5) 6.1.2功能点1界面结构说明 (5) 6.1.3功能点2界面结构说明 (5) 6.2模块2 (6) 6.2.1总体界面结构（业务操作区）说明 (6) 6.2.2功能点1界面结构说明 (6) 6.2.3功能点2界面结构说明 (6) <系统名称>接口设计说明书 ****科技有限公司 修改历史 目录 1概述 (1) 2子系统说明1 (1) 2.1接口名NO.1 (1) 2.2接口名NO.2 (1) 1概述 [概述说明本文档的描述的内容、目的、使用场合等。] 2子系统说明1 2.1接口名NO.1 示例如下： 接口功能： 验证用户是否合法。 除部分特别说明不需要用户验证的接口外，此接口必须首先调用，否则会出现“未授权”的异常错误。在验证成功之后才能成功调用其它接口，该接口验证通过的用户信息将保存到IHDUserSession类的实例中，作为其它接口调用的用户信息。 此接口在内部需要通过以下几点的验证： 1.CA验证，验证USBKey是否合法（只有系统策略中设置了需要CA验证选项后才 会进行CA的验证）； 2.域用户验证，验证登录用户名和密码是否是域用户，通过Windows集成身份验证 实现； 3.用户数据库合法性验证，验证登录用户是否存在于USERS表中； 4.计算机合法性验证，验证登录计算机是否存在于COMPUTER表中，计算机的验证 通过计算机名，硬盘序列号，网卡物理地址，IP地址这四项的组合进行验证，具 体组合可以系统策略中配置； 5.如果验证未通过，返回false，并在客户端日志中记录登录失败的原因 接口声明： *** 相关数据表： **** 输入参数： **** 输出参数： *** 返回值及异常： 参见错误！未找到引用源。错误！未找到引用源。 返回值不变。 捕获到异常，请对异常进行分析。如果异常类型是***。 2.2接口名NO.2 接口功能： 接口声明： 相关数据表：输入参数： 输出参数： 返回值及异常： {产品名称} 软件需求规格说明书 编写人： 编写日期：年月日 目录 1.产品描述 (3) 1.1.编写目的 (3) 1.2.产品名称 (3) 1.3.名词定义（可选） (3) 2.产品需求概述 (3) 2.1.功能简介 (3) 2.2.运行环境 (3) 2.3.条件与限制（可选） (3) 3.功能需求 (3) 3.1.功能划分（可选） (3) 3.2.功能1 (4) 3.3.功能N (4) 3.4.不支持的功能 (4) 4.数据描述 (4) 5.性能需求（可选） (4) 6.运行需求（可选） (4) 6.1.用户界面 (4) 6.2.硬件接口 (4) 6.3.软件接口 (5) 6.4.通信接口 (5) 7.其它需求（可选） (5) 8.特殊需求（可选） (5) 9.不确定的问题（可选） (5) 10.编写人员及编写日期 (5) 11.附录 (5) 11.1.引用文件 (5) 11.2.参考资料 (5) 1.产品描述 1.1.编写目的 【说明编写本软件需求规格说明书的目的，指出预期的读者。】 1.2.产品名称 【本项目的名称，包括项目的全名、简称、代号、版本号。】 1.3.名词定义（可选） 【对重要的或是具有特殊意义的名词（包括词头和缩写）进行定义，以便读者可以正确地解释软件需求说明。】 2.产品需求概述 2.1.功能简介 【对产品的基本功能做一个简介，包括： 1.本产品的开发意图、应用目标及作用范围。 2．概略介绍了产品所具有的主要功能。可以用列表的方法给出，也可以用图形表示主要的需求分组以及它们之间的联系，例如数据流程图的顶层图或类图等。 3．说明本产品与其他相关产品的关系，是独立产品还是一个较大产品的组成部分。 可以用表示外部接口和数据流的系统高层次图，或者方框图说明。】 2.2.运行环境 1.硬件环境： 【详细列出本软件运行时所必须的最低硬件配置、推荐硬件配置(如主机、显示器、外部设备等)以及其它特殊设备。】 2.软件环境： 【如操作系统、网络软件、数据库系统以及其它特殊软件要求。】 2.3.条件与限制（可选） 【说明本软件在实现时所必须满足的条件和所受的限制，并给出相应的原因。 必须满足的条件包括输入数据的范围以及格式。 所受的限制包括软件环境、硬件环境等方面的内容。例如：必须使用或者避免的特定技术、工具、编程语言和数据库；企业策略、政府法规或工业标准；硬件限制，例如定时需求或存储器限制；经费限制、开发期限；项目对外部因素存在的依赖。例如其它项目开发的组件。等等】 3.功能需求 【功能需求描述系统特性，即产品所提供的主要服务。可以通过使用实例、运行模式、用户类、对象类或功能等级等不同方法来描述，还可以把它们组合起来使用。 功能需求的表述形式可以参见《需求分析和管理指南》第8.2节。】 3.1.功能划分（可选） 【此部分从用户的角度描述将软件划分成不同的部分，并给出总体功能结构。对于复杂 软件著作权-说明书范本（二） 设计说明书 中国版权保护中心接收登记的文档包含两种：操作说明书或设计说明书。 设计说明书适合没有界面的嵌入式软件，插件软件，后台运行软件以及游戏软件。一般包含结构图，软件流程图，函数说明，模块说明，数据接口，出错设计等。 操作说明书适合管理类软件，有操作界面，一般应包含登录界面，主界面，功能界面截图，截图之间有相应的文字说明，能全面展示软件的主要功能。 格式要求：一、说明书应提交前、后各连续30页，不足60页的，应当全部提交。 二、说明书页眉应标注软件的名称和版本号，应当与申请表中名称完 全一致，页眉右上应标注页码，说明书每页不少于30行，有图除 外，另外截图应该清晰完整。 范例如下： 设计说明书 一、引言 目的 编写详细设计说明书是软件开发过程必不可少的部分，其目的是为了使开发人员在完成概要设计说明书的基础上完成概要设计规定的各项模块的具体实现的设计工作。 二、软件总体设计 2.1软件需求概括 本软件采用传统的软件开发生命周期的方法，采用自顶向下，逐步求精的结构化的软件设计方法。 本软件主要有以下几方面的功能 (1)连接设备 (2)提取数据 (3)保存数据 (4)删除仪器数据 (5)查看历史数据 定义 本项目定义为一个典型的多点互动探伤软件。它将实现多点设备和系统程序的无缝对接，以实现多点互动功能。 2.2需求概述 1.要求利用PQLib硬件商提供的SDK开发出对应的触摸屏系统。 2.系统要显示图片，并实现图片相关所有的多点操作，包括放大，缩小，旋转，平移的功能。 3.要提供美观的图片菜单，在菜单中要提供必要的图片简介信息。 4.系统图片的维护更新要方便。 2.3条件与限制 系统开发的条件是普通PC以及相对应的系统，本次开发所用的系统是WINDOW SERVER2003以及ADOBE FlashCS4。由于硬件开发商提供的开发文档不是很详尽，这对系统开发产生了一定限制影响。 总体设计 2.4总体结构和模块接口设计 系统整体结构框架如图 修订历史记录 【模板使用必读：模板内容和页眉中【】包含内容为指导性的待替换文字，请在使用中替换为具体内容，或删除。文件提交时不得再含有这些内容。】 目录 1引言 (4) 1.1编写目的 (4) 1.2背景 (4) 1.3术语与缩写解释 (4) 1.4参考资料 (4) 2模块命名规则 (4) 3程序系统的组织结构 (5) 3.1子系统划分 (5) 3.2模块划分 (5) 3.3程序与功能需求、系统模块间的关系 (5) 4程序1（标识符）设计说明 (5) 4.1程序描述 (5) 4.2功能 (6) 4.3性能 (6) 4.4输人项 (6) 4.5输出项 (6) 4.6算法 (6) 4.7流程逻辑 (6) 4.8接口 (6) 4.9存储分配 (7) 4.10注释设计 (7) 4.11限制条件 (7) 4.12尚未解决的问题 (7) 5程序2（标识符）设计说明 (7) 引言 编写目的 【给出项目详细设计说明书的编写目的，同时指明读者对象。】 背景 【说明： a．待开发软件系统的名称； b.本项目的任务提出者、开发者、用户和运行该程序系统的计算中心。】 术语与缩写解释 【列出本文件中用到的专门术语的定义和外文首字母缩写的原词组。】 参考资料 【提示：可包括：（1）本项目经核准的计划任务书、需求规格说明书、合同、项目设计概要说明书或上级机关的批文；（2）本文档所引用的资料、规范等，列出这些资料的作者、标题、编号、发表日期、出版单位或资料来源。】 模块命名规则 【确定本软件的模块命名规则，例如类、函数、变量等，确保设计文档的风格保持一致。可以从机构的编码规范中摘取或引用。】 程序系统的组织结构 【用一系列图表列出本程序系统内的每个程序（包括每个模块和子程序）的名称、标识符和它们之间的层次结构关系。】 子系统划分 模块划分 程序与功能需求、系统模块间的关系 程序1（标识符）设计说明 【从本章开始，逐个地给出各个层次中的每个程序的设计考虑。以下给出的提纲是针对一般情况的。对于一个具体的模块，尤其是层次比较低的模块或子程序，其很多条目的内容往往与它所隶属的上一层模块的对应条目的内容相同，在这种情况下，只要简单地说明这一点即 概要设计说明书示例【概要设计说明书(模板)】 概要设计说明书 修订记录 目录 第一章 1.1.1. 2.1. 3.1. 4.第二章 2.1.2.2.2. 3.2. 4.2. 5.2. 6.2. 7.第三章 3.1.3.2.3.3.第四章 4.1.4.2.4.3.第五章 5.1.5.2.5.3.第六章 6.1. 6.2.6.3. 补救措施......................................................... ........................................10系统维护设计......................................................... .. (10) 第一章引言 1.1.编写目的 说明编写这份概要设计说明书的目的，指出预期的读者。 1.2.背景 说明： a.待开发软件系统的名称； b.列出此项目的任务提出者、开发者、用户以及将运行该软件的站点。 1.3.定义 列出本文件中用到的专门术语的定义和外文首字母组词的原词组。 1.4.参考资料 列出有关的参考文件，如： a.本项目的经核准的计划任务书或合同，上级机关的批文； b.属于本项目的其他已发表文件； c.本文件中各处引用的文件、资料，包括所要用到的软件开发标准。列出 第二章总体设计 2.1.需求规定 说明对本系统的主要的输入输出项目、处理的功能性能要求。 2.2.运行环境 简要地说明对本系统的运行环境（包括硬件环境和支持环境）的规定。 2.3.基本设计概念和处理流程 说明本系统的基本设计概念和处理流程，尽量使用图表的形式。 2.4.结构 用一览表及框图的形式说明本系统的系统元素（各层模块、子程序、公用程序等）的划分，扼要说明每个系统元素的标识符和功能，分层次地给出各元素之间的控制与被控制关系。 2.5.功能需求与程序的关系 文档编号：T-JKJS 文档版本：0.01 项目编号：XX-DX- PECS 《XX电信工程外部协作系统》 Project Exterior Cooperation System 施工单位接口技术解决方案 编写人：南疯日期：2006-10-30 审核人：日期： 批准人：日期： XXXXXX信息科技股份有限公司 地址：XXXXXXX 邮编：XXXXXX 电话：XXXXXXXX传真：XXXXXX 网站：XXXXXXXXX 修改记录（Revision Chart） 版本号批准人修改人修改0.01南疯2006-10-30 0.02详细修改记录： 序号 1引言 1.1编写目的 1.2覆盖范围 1.3预期读者与阅读建议 1.4文档约定 1.5术语与缩略语 1.6参考文献 2概述 3接口方式 4接口安全 4.1接口认证 4.2数据安全 5事务处理 6性能考虑 7容错处理 8数据格式 8.1约定 8.2施工系统向外协系统发送请求 8.2.1请求查询一个业务数据 8.2.2新增一条记录，得到记录的键值 8.2.3修改一条记录 8.2.4删除一条记录 8.2.5文档上传 8.2.6一条记录中一个文档字段上传多个文件 8.2.7补充上传文档 8.2.8在记录中删除一个文档 8.2.9获得文档的基本信息 8.2.10获得文档的所有兄弟信息 8.2.11获得文档的所有父亲信息 8.2.12下载一个文档 8.2.13获得字典 8.3外协系统向施工系统发送请求 8.3.1发送变更后的数据 8.3.2发送变更后的字典 8.3.3文档发送请求 9信息数据项 9.1数据表 9.2字段信息 9.3字典类型 媒讯集团E A S项目 CTC与EAS接口 需求及设计说明书 文档作者： 创建日期：2013-05-10 确认日期： 当前版本：1.0 拷贝数量：1 审批签字: 客户方： 实施方： 文档控制 目录 1.概述 (4) 1.1读者 (4) 1.2图例 (4) 1.3目的 (4) 二、业务现状 (5) 三、概要设计 (5) 3.1接口通讯方式 (5) 3.2通讯内容定义 (5) 3.3媒讯CTC系统提供接口使用范例 (5) 3.4金蝶EAS提供接口使用范例 (5) 3.5媒讯CTC系统提供接口服务地址 (7) 3.6金蝶EAS提供接口服务地址 (7) 3.7接口需求 (7) 四、详细设计 (8) 4.1XX EAS接口 (8) 1.概述 金蝶与用户及用户业务系统方通过多次讨论，制定了接口开发需求设计说明书，作为双方后续开发指引。 1.1读者 本文读者对象为业务管理人员、系统设计、开发人员、测试人员。 1.2图例 本文中如未进行特殊说明，各图标代表的含义如下： 表示流程走向； 1.3目的 本文档是媒讯CTC系统与EAS系统接口的需求及设计方案相关文档，可用于指导开发、测试工作和作为验收相关依据文档。 二、业务现状 待补充 三、概要设计 3.1接口通讯方式 金蝶EAS与媒讯CTC系统之间通讯采用WebService方式进行数据传输。 3.2通讯内容定义 对于记录型的大对象，在通讯时，采用String型的xml格式的参数进行传递。对于其他非记录型的对象，在通讯时，可采用非xml格式的参数进行传递，也可使用多个参数。具体格式，请参照每个接口的通讯用例说明。 3.3媒讯CTC系统提供接口使用范例 待补充。 3.4金蝶EAS提供接口使用范例 3.4.1规范说明 EAS通过webService接口与异构系统通信。EAS WebService全部是使用java编写的，其接口描述符合WSDL国际标准，其数据描述符合XSD 国际标准。 本次提供的接口除系统登录接口外，其他接口都需要调用登录接口，以便将登陆的SessionId信息放入到SOAP 的HEADER 报文中。 3.4.2使用示例 金蝶在EAS上发布WebService服务，提供wsdl文件供客户端下载，其他业务系统根据下载的wsdl文件，产生客户端。 建议使用Axis2来生成客户端代理。 XXAPI 接口设计说明书 公司 2016年11月25日 文档管理信息表 主题XX api接口设计说明书 版本V0.1 内容 关键字 参考文档 创建时间 创建人 最新发布日期 文档变更记录表 修改人修改时间修改内容 创建 目录 文档变更记录表 .................................................................................................................................................................................. 目录 .................................................................................................................................................................................................... 引言 ...................................................................................................................................................................................................... 编写目的 背景 定义 参考资料 综述 ...................................................................................................................................................................................................... 统一的输入输出参数 必须登录才能访问的接口 错误返回码列表 用户接口 .............................................................................................................................................................................................. 用户注册（user/signup） 用户登录（user/signin） 优惠券接口 .......................................................................................................................................................................................... 我的优惠券（coupon/mycoupon） 设计说明范文 导读：范文设计说明范文 【篇一：室内设计说明】 随着生活质量不断提高，人们对赖以生存的环境开始重新考虑，并由此提出了更高层次的要求。持别是生活水平和文化素质的提高和住宅条件的改善，“室内设计”已不再是专业人士的专利。普通百姓参与设计或自己动手布置家居已形成风气，这就给广大设计人员提出了更高的要求。 简约风格是近来比较流行的一种风格，追求时尚与潮流，非常注重居室空间的布局与使用功能的结合。室内布置整体设计就两个字概括简约。这样的室内崇尚少即是多，装饰少，功能多，十分符合现代人渴求简单生活的心理。因而很受那些追求时尚又不希望受约束的青年人所喜爱。 介绍我的设计思想 本方案为80㎡三室一厅的居室设计，业主为一对年轻夫妇。针对上班族的业主，设计师采用简约明朗的线条，将空间进行了合理的分隔。面对扰嚷的都市生活，一处能让心灵沉淀的生活空间，是本房 业主心中的一份渴望，也是本设计在该方案中所体现的主要思想。因此，开放式的大厅设计给人以通透之感，避免视觉给人带来的压迫感，可缓解业主工作一天的疲惫。没有夸张，不显浮华，通过过于干干净净的设计手法，将业主的工作空间巧妙地融入到生活空间中。 卧室 现代住宅的发展，小家庭的组建，人们心理上的要求，希望卧室具有私密性、蔽光性，配套洗浴，静谧舒适，与住宅内其他房间分隔开来。卧室是整套房子中最私人的空间，可以完全根据自己的想法来设计，不必去考虑别人的看法。纯粹的卧室是睡眠和更衣的房间，但是更确切地说卧室是一个完全属于主人自己的房间，在这里读书、看报、看电视、写信、喝茶等等，当你不愿被他人打扰时你就会躲进卧室里。所以，设计卧室时我首先考虑的是让人感到舒适和安静。我设计的居室的面积并不是很大，除摆放双人床外，留有一定的面积摆放卧室家具，如衣柜、床头柜、地灯等。 在装饰照明色调上：让人在这里消除一天工作的辛劳，因此我设计的墙壁、家具以及灯光的颜色是暖色调的。卧室设计的核心是床和衣橱，其它的家具和摆设根据自己的习惯来添加。卧室的灯光应选用可调节的，因为有些人喜欢在昏暗的灯光下入睡，有些人则会在柔和的灯光下阅读。 XXX接口说明书 (版本： 文档编号保密等级 作者最后修改日期 审核人最后审批日期 批准人最后批准日期 修订记录 日期版本修订说明修订人 1简介 1.1文档目的 接口文档是前端与后端交互密不可分的环节，接口的规范性会直接影响双方对接过程中的效率和质量。本着快速高效开发的目的性，避免对接过程中的错误率。 1.2接口规范 (1) 遵循RESTful API设计风格 (2) 数据格式采用json格式 (3) 返回统一结构数据 例如： 结构：data（数据）、errorCode（状态码）、msg（提示信息） { data:{}, .] 订单列表 orderList orderId string 否订单id orderName string 否订单名称 isStudent boolean 是false false 是否学生（是：true，否： false） 返回参数： 参数名类型示例值默认值描述 data array […]返回的数据 data id string 用户id gender number 1 1 用户性别（男：1，女：2）invoiceTitle string 抬头 address string 地址 billList array [...] 订单列表数据 billList id string 订单id billName string 订单名称 billStauts number 1 1 订单状态（待开票：1，回款： 2，核销：3） address string 客户地址 userInfo object {} 用户信息 userInfo name name 用户姓名 age number 用户年龄 gender string 1 1 用户性别（男：1，女：2）errorCode number 状态信息 msg string 信息提示 返回示例值: { data:[ { id:'1', gender:2, invoiceTitle:'帝国快运', address:'陕西省西安市雁塔区科技路24号', billList:[ { id:'001', billName:'测试数据', billStauts:1, address:'雁塔区' }, { id:'002', billName:'测试数据02',(完整版)软件详细设计说明书模板
Web Services业务接口规范说明书
室内装饰设计说明范本
项目开发详细设计说明书(超好用模板)完整版
软件系统详细设计说明书模板
接口文档规范
课程设计说明书范本模板
详细设计说明书模版
接口设计模板
软件需求说明书编写规范
软件著作权设计说明书范本资料
详细设计说明书模板
概要设计说明书示例【概要设计说明书(模板)】
完整的接口解决方案说明书
项目接口需求及设计说明文档(模板)
API接口设计说明书
设计说明范文
接口文档规范