应用系统命名规范模板.doc

资料内容仅供您学习参考，如有不当或者侵权，请联系改正或者删除。
应用系统命名规范

文档编号:

青岛高校信息产业有限公司

[注: 用方括号括起来并以蓝色斜体显示的文本, 它们用于向使用者提供指导, 在发布此文档之前应该将其删除。黑体正体显示的文本为预先设置好的文本, 可直接使用或修改]
[要定制 Microsoft Word 中的自动字段( 选中时显示灰色背景) , 请选择 File>Properties, 然后将 Title、 Subject 和 Company 等字段替换为此文档的相应信息。关闭该对话框后, 经过选择 Edit>Select All( 或 Ctrl-A) 并按 F9, 或只是在字段上单击并按 F9, 能够在整个文档中更新自动字段。对于页眉和页脚, 这一操作必须单独进行。按 Alt-F9, 将在显示字段名称和字段内容之间切换。有关字段处理的详细信息, 请参见 Word 帮助。]

修订文档历史记录

版本号
变更报告编号
更改条款及内容
更改人
审批人
更改日期

[评审确认后的版本为1.0, 每一扩展新功能规模, 版本升1.0, 每一变更有一变更报告, 带来版本0.1的升级, ]]
目录
1. 文档概述 4
1.1 目的 4
1.2 目标读者 4
1.3 术语与缩略 4
1.4 参考资料 4
2. 文档规范 4
3. 软件需求规范 4
3.1 功能分解层次约束 4
3.2 需求子系统命名 4
3.3 需求功能模块命名规范 4
3.4 需求功能描述 4
4. 系统分析设计 5
4.1 统一英文缩写或名词约定列表 5
4.2 设计子系统命名 5
4.3 设计功能模块命名规范 5
4.4 子系统功能跟踪规范 6
4.5 类、 实体命名 6
4.6 功能模块设计规范 6
4.7 数据库设计命名规范 6
4.7.1 表命名规范 6
4.7.2 字段命名规范 6
4.7.3 数据库设计规范 7
5. 系统实施 7
5.1 程序目录命名 7
5.2 JBOSS Server 文件目录及说明 8
5.3 10
5.4 10

1. 文档概述
1.1 目的
此组准则的目的是确保应用系统命名的一致性和可追踪性, 这些准则能够按原样使用, 或者进行部分定制, 以满足大部分项目的需求。
1.2 目标读者
系统分析员、 系统设计员、 项目经理、 质量管理员、 开发人员
1.3 术语与缩略
术语名称
术语描述
备注
EOS
上海普元公司提供的面向构件的中间件平台, 作为本项目应用软件的技术平台

构件
本规范所提到的构件及构件包的概念, 均指EOS中的构件与构件包。

FBFRAME
基础业务框架

1.4 参考资料
1.《EOS项目开发规范》.doc
2. RUP
2. 文档规范
u 文档命名规范: 系统全称+中文文档名。如: 《财富管理系统概要设计说明书.doc》
u 文档编写要求:
l Word XP( 项目组必须统一文档工具的版本)
l 所绘图形要求提供原始文件
l 在Word中的插图尽可能使用JPG格式, 以降低WORD文档的大小
l 文档一旦初步定稿之后, 评审者采用修正模式修改文档

3. 软件需求规范
3.1 功能分解层次约束
《软件需求规格说明书》中的功能被组织为两级, 分别对应于子系统( 主题) 和对应于子系统的功能( UC) , 如子系统内功能太多具有多层特征时, 可经过进一步分解降低为两层, 划分的依据是统一的, 如在依据业务流程的工作单元划分或依据用户类别划分;
3.2 需求子系统命名
一项目可包含多个子系统, 每一子系统以中文全称分别命名。
3.3 需求功能模块命名规范
子系统下的功能模块( 软件需求采用用例模型, 对应用例名称) 的命名采取格式为: 动词+名词的方式, 如系维护电话卡
3.4 需求功能描述
此描述的长度至少应当为 1 个段落, 而且不超出 3 个段落。描述中需包含功能的关键目的、 价值陈述和概念的说明, 能够详细说明功能点。

4. 系统分析设计
4.1 统一英文缩写或名词约定列表
本项目中, 无论数据库设计、 程序文件命名、 文档文件命名, 对于同一概念, 如果需要使用缩写, 统一使用如下定义。
词语/缩写
英文描述
中文描述
EOS

普元面向构件中间件平台
Doc
Document
文档
Src
Source Code
源码
Feature
Feature
功能点, 指经过设计后分解的功能
Query

查询, 在定义程序文件名称时, ”查询”功能使用的英文为Query, 例如AccountQuery.jsp
Add

增加, 在定义程序文件名称时, ”增加”功能使用的英文名称为”Add”, 例如AccountAdd.jsp
Update

编辑, 在定义程序文件名称时, ”修改”功能使用的英文名称为”Update”, 例如AccountUpdate.jsp
Delete

Delete
删除, 在定义程序文件名称时, ”删除”功能使用的英文名称为”Delete”, 例如Account Delete.jsp
List

结果列表使用英文名称, 例如AccountList.jsp
Return
Return
返回, 系统中表示返回的英文缩写
Success

系统中表示成功的英文单词均使用Success
Fault

系统中表示失败的英文单词均使用Fault
Error
Error
系统中表示错误的英文缩写
业务字典

系统中与业务相关的代码及对代码的描述, 例如, 用Authlevel表示用户认证等级, 而0: 所有用户, 1: 登录用户, 2: 产品绑定用户等。
EOS提供了对业务字典的管理, 经过EOS业务字典功能, 为系统实现提供的大量构件, 方便开发。

4.2 设计子系统命名
设计子系统是《软件需求规格说明书》中子系统在设计模型中的映射, 可能有扩展或调整, 为了区分出各个子系统应分别命名, 名称为中文全称名称加附在括号内的3个小写字母表示的缩写名称。缩写名称, 主要用于在构件名称中标识构件包和数据库表命名, 如使用用例建模, 子系统对应于用例模型中的包, 应在包中表明缩写。如:
资金管理( cms)
定价管理( pms)
仓储管理( wms)

4.3 设计功能模块命名规范
设计中功能模块的命名为英文, 方式为: 系统缩写名称+”_”+若干英文单词组成的业务描述, 名称单词第一个字母用大写其余使用英文小写。功能模块(用例)定义与EOS构件包命名一致, 如:
子系统
功能模块( UC)
设计命名
仓储管理( wms)
维护电话卡
wms_MaintainPhoneCard
出电话卡
wms_OutPhoneCard

4.4 子系统功能跟踪规范
每一设计子系统下建立一用例实现图, 命名为Main, 建立本子系统下功能实现与功能需求间的追踪关系, 如wms_MaintainPhoneCard( 设计阶段) -〉维护电话卡( 需求阶段) ; 每一设计子系统下建立一类图, 命名为Main, 建立本子系统下所有功能所涉及的实体及逻辑关系。
4.5 类、 实体命名
l 类、 实体命名采取全拼英文, 每词的命名采取首写字母大写其余字母小写的方式, 命名需要两词或以上的, 词间连续不要在对象名称的字符之间留空格, 如PhoneCard, 类名建议不要太长( 12个字符以内) , 如果太长, 使用单词的缩写, ( CamelCase法, 但首字母为大写)
l 对象名称不能使用汉字, 不能使用中文拼音或中文拼音的首字母, 尽可能不使用阿拉伯数字
l 必须保证的名称没有和保留词、 数据库系统或者常见访问方法冲突
4.6 功能模块设计规范
每一功能模块下建立一类图, 命名为Main, 建立本功能模块所涉及的界面类、 实体类及逻辑关系;
每一功能模块下建立一或多个流程图, 描述处理逻辑, 图的命名反映要处理的任务;
4.7 数据库设计命名规范
4.7.1 表命名规范
表名为大写字母构成: 系统缩写+_+对象名称( 对应类、 实体命名, 改为大写) + 大写的数据库对象后缀, 例如业务标准系统的某个表名: WMS_PHONECARD_TD , 下为命名规格说明:

对象名称
对象类别
命名规则( 加前缀)
表
业务数据表
WMS_对象名_TD
代码表
WMS对象名_TC
关联表
WMS_对象名_TJ
系统定义表
WMS_对象名_TS
键和索引
主键
WMS_对象名_PK
外键
WMS_对象名_FK
索引
WMS_对象名_IX
视图

WMS_对象名_VIEW
包

WMS_对象名_PACK
存储过程

WMS_对象名_PROC
函数

WMS_对象名_FUNC
触发器

WMS_对象名_TRI

4.7.2 字段命名规范

l 采取大写字母命名;
l 不同表的同一个业务字段类型、 长度、 字段名称保持统一, 例如, 客户编号可能存在于多个表中, 要求采用同样的字段名, 而且类型、 长度一致
l 字段名建议不要太长( 15个字符以内) , 如果太长, 请使用单词的缩写
4.7.3 数据库设计规范
l 必须满足三个数据库设计范式
l 保证数据完整性 使用事务提交概念、 使用触发器等手段、 设置外键
l 数据库维护( 整理, 备份, 恢复)
l 数据库访问操作必须考虑网络多用户使用冲突问题
l 对较大系统, 需要考虑数据安全性, 数据分布, 数据复制, 数据仓库等等
l 必须考虑数据库访问速度, 对于数据量较大的表, 一定要加索引

5. 系统实施
5.1 Eos数据构件目录命名
l 项目名使用项目简称
l 一项目建立一个数据库管理的构件包, 命名为: 项目简称+”_”+DATA
l 以子系统简称命名子系统数据构件, 其下包含本子系统所有的数据库表

5.2 开发目录命名

应用功能构件包的前缀识别所属子系统;
构建包的命名依据《功能分解矩阵》或系统分析设计模型。

5.3