2 应用系统命名指南Word文件下载.docx
《2 应用系统命名指南Word文件下载.docx》由会员分享，可在线阅读，更多相关《2 应用系统命名指南Word文件下载.docx（17页珍藏版）》请在冰豆网上搜索。
3.6.1定义系统负责在何处提供操作选项
3.6.2术语在整个用例中的一致使用
3.7参与者和系统行为的独立段落
3.8备选流和子流
3.9前置条件和后置条件
3.10对于缺少的详细信息使用占位符（待定）
3.11补充规范的定义和引用
3.12使用UI原型／设计进行交叉检查
3.13异常流（可选）
3.13.1发生什么异常？
1.
简介
1.1
目的
此组准则的目的是确保应用系统命名的一致性。
1.2
范围
这些准则可以按原样使用，或者进行定制，以满足大部分项目的需求。
1.3
定义、首字母缩写和缩写
EOS：
上海普元公司提供的面向构件的中间件平台，作为本项目应用软件的技术平台
构件：
本规范所提到的构件及构件包的概念，均指EOS中的构件与构件包。
FBFRAME：
基础业务框架
1.4
参考资料
《EOS项目开发规范》.doc
2.
系统的描述
一项目可包含多个子系统，为了区分出各个子系统课分别命名，名称为中文全称名称加附在括号内的3个小写字母表示的缩写名称。
缩写名称，主要用于在构件名称中标识构件包和数据库表命名，对应于用例模型中的包。
如：
财富管理系统（wms）
资金管理系统（cms）
定价管理系统（pms）
3.
统一英文缩写或名词约定列表
本项目中，无论数据库设计、程序文件命名、文档文件命名，对于同一概念，如果需要使用缩写，统一使用如下定义。
词语/缩写
英文描述
中文描述
EOS
普元面向构件中间件平台
Doc
Document
文档
Src
SourceCode
源码
Fea
Feature
功能点，指经过设计后分解的功能
Req
Requirement
需求点，指需求调研后形成的用户需求
Query
查询，在定义程序文件名称时，“查询”功能使用的英文为Query，例如AccountQuery.jsp
Add
增加，在定义程序文件名称时，“增加”功能使用的英文名称为”Add”，例如AccountAdd.jsp
Update
编辑，在定义程序文件名称时，“修改”功能使用的英文名称为“Update”，例如AccountUpdate.jsp
Delete
删除，在定义程序文件名称时，“删除”功能使用的英文名称为“Delete”，例如AccountDelete.jsp
List
结果列表使用英文名称，例如AccountList.jsp
Return
返回，系统中表示返回的英文缩写
Success
系统中表示成功的英文单词均使用Success
Fault
系统中表示失败的英文单词均使用Fault
Error
系统中表示错误的英文缩写
业务字典
系统中与业务相关的代码及对代码的描述，例如，用Authlevel表示用户认证等级，而0：
所有用户，1：
登录用户，2：
产品绑定用户等。
EOS提供了对业务字典的管理，通过EOS业务字典功能，为系统实现提供的大量构件，方便开发。
4.开发目录编排与命名
4.1文档目录
遵循RUP的组织方式，强制配置。
4.2文档规范
文档命名规范：
系统全称+“_”+中文文档名。
《财富管理系统（WMS）概要设计说明书.doc》
文档编写要求：
WordXP（项目组必须统一文档工具的版本）
所绘图形要求提供原始文件
在Word中的插图尽可能使用JPG格式，以降低WORD文档的大小
文档一旦初步定稿之后，评审者采用修正模式修改文档
4.3需求/功能编排规范
软件需求采用用例模型，用例名称的命名为：
系统缩写名称+“_”+若干英文单词组成的业务描述,对应于用例,名称单词第一个字母用大写其余使用英文小写。
创建计划wms_CreatePlan）
用例定义与EOS构件包命名一致：
子系统
UC
包名
客户管理（crm）
客户信息管理
crm_CustInfo
客户关系维护
crm_CustAssign
大客户管理
crm_VipCust
客户服务
crm_CustServ
项目公共构件库
注：
系统管理部分的权限管理和机构管理在EOS提供的构件包基础上修改，并作为项目中的一部分
4.4程序目录命名
EOSServer文件目录及说明
说明：
1、对于业务逻辑、展现逻辑和数据实体文件，是由EOS提供发布时自动上传注册，不需要手工COPY文件到相应目录
2、上图中除标注外的其余目录均为非必要目录
4.5JBOSSServer文件目录及说明
5.数据库命名规范
表命名规范
●表名构成：
系统缩写+_+对象名称（英文单词或英文缩写）+数据库对象后缀，例如业务标准系统的某个表名：
BSS_ACCOUNT_TD
●表名全部使用大写
●表名建议不要太长（15个字符以内），如果太长，请使用单词的缩写
●对象名称不能使用汉字
●对象名称不能使用中文拼音或中文拼音的首字母
●对象名称尽可能不使用阿拉伯数字
●必须保证你的对象名称没有和保留词、数据库系统或者常用访问方法冲突
●绝对不要在对象名称的字符之间留空格
●如果对象的名称仅有一个单词，则不使用缩写
对象名称
对象类别
命名规则（加前缀）
表
业务数据表
BSS_对象名_TD
代码表
BSS_对象名_TC
关联表
BSS_对象名_TJ
系统定义表
BSS_对象名_TS
键和索引
主键
BSS_对象名_PK
外键
BSS_对象名_FK
索引
BSS_对象名_IX
视图
BSS_对象名_VIEW
包
BSS_对象名_PACK
存储过程
BSS_对象名_PROC
函数
BSS_对象名_FUNC
触发器
BSS_对象名_TRI
字段命名规范
●字段名全部大写
●不同单词之间使用“_”
●不同表的同一个业务字段类型、长度、字段名称保持统一，例如，客户编号可能存在于多个表中，要求采用同样的字段名，并且类型、长度一致
●字段名建议不要太长（15个字符以内），如果太长，请使用单词的缩写
属性默认类型定义（Oracle参考）
属性类别
类型
长度
备注
人的姓名
Varchar2
20
电话号码
30
部门
90
单位/机构名称
100
地址
判断字
CHAR
1
0：
否1：
是
时间、日期
DATE
意见、理由、描述、简介、备注
2000
CLOB
大于4000请采用CLOB类型
图片
BLOB
金额
NUMBER
8,2
比例
3,2
设计规范
一般必须满足三个数据库设计范式
●范式一：
表结构中不能含有任何重复的数据字段。
违反该范式的例子：
求职人员表：
求职人员编号
求职人员姓名
联系电话1
联系电话2
C001
张三
63179975
63179976
C002
李四
64516408
64516409
问题：
若增加一个“联系电话3”则要修改表结构，原来的应用程序也将重新修改。
正确处理：
求职人员联系表：
序号
联系电话
01
02
●范式二：
要求每一列均函数性地依赖于主关键字。
物业分布表：
分布点编号
所在地址
所在城市
H001
蒲汇塘路
上海
H002
漕宝路
H003
汉中路
主要服务表：
服务编码
服务收费
P01
70.99
P02
21.00
P03
502.54
服务记录表：
任务描述
树木修剪
1997/11/15
上油
1997/12/01
熔炉
1997/12/03
服务记录表是以“分布点编号”和“服务编码”作为主关键字。
“所在地址”和“任务描述”两列不完全函数性地依赖于主关键字。
显然服务期间地址通常是不变的，不管在什么地方执行任务，特定任务的描述应该是一样的。
●范式三：
表中记录符合第二范式且不存在传递依赖，当表中含有一定其他列的非主列时，存在传递依赖。
学生考试成绩表
学号
课程
考试日期
成绩
累计平均
S001
CIS091
1997/10/17
84
81
S002
MGT100
72
77
S003
93
“学号”，“课程”和“考试日期”为主关键字。
“累计平均”列代表该学生所有课程成绩的平均，这列传递依赖于“学号”列，因此不符合第三范式。
学生个人信息表
姓名
91
80
王五
78
特殊情况可不用设计范式
*存储计算值到数据库中。
*将历史信息分割到其他表中。
存储计算值：
通常，一个设计良好的关系数据库不存储任何计算数据如总和，平均值，最大值和最小值。
这些数据通常在运行时利用基本数据来计算。
然而，有些场合把计算值储存起来可能更简单，更快，更明智。
比如：
旅客表：
旅客编号
Z001
...
L004
W008
飞行情况表：
飞行次数
飞行日期
飞行里程
11
1998/01/02
7832
1800
1998/02/03
7743
27
1998/04/03
743
“飞行情况表”会很快增加，渐渐达到几万行。
旅客若打电话询问自己飞行有多少公里，希望立刻得到回答，然而查询“飞行情况表”并把所有单个里程加起来可能要花费几秒的时间。
这时就需要把总和信息存储起来，以供快速查询。
旅客里程
73873
92923
8727
为保持总公里数的相对实时性，可以每晚运行一个加总程序更新总和，这样做可至少带来两个好处：
其一：
总公里数可快速获取。
其二：
更好地平衡负载。
繁重的加总工作放在晚上处理。
为了更快更新，从而得到更准确的数据，需要使用类似触发器的方法来得到最新的数据。
查找历史：
假设维护一个信用卡支付系统，顾客通常打电话来了解自己最近的收支情况。
偶尔他们想知道几个月前的收支情况。
在这个应用中最主要的表如下：
业务交易表：
交易编码
客户编码
使用日期
T0001
C2021
1997/11/1
414.88
T1012
C3000
1997/11/9
65.90
该表会很快增长到几百万行，查找一个客户的所有记录需要几秒钟。
事实上顾客和服务人员对这反应时间都有抱怨。
改进方法一：
由于客户一般只查询最近月份的交易信息，可以另加两个同样的缓冲表，每月底，进行一次数据移动即可（把最近月份的数据删除）。
改进方法二：
可利用其“分区”的概念，通过复制机制，将一个数据库复制到另外一个数据库中。
其他
●保证数据完整性
⏹使用事务提交概念
⏹使用触发器等手段
⏹设置外键
●数据库维护（整理，备份，恢复）
●数据库访问操作必须考虑网络多用户使用冲突问题
●对较大系统，需要考虑数据安全性，数据分布，数据复制，数据仓库等等
●必须考虑数据库访问速度，对于数据量较大的表，一定要加索引
有关一般信息和更多的用例准则，请参阅RationalUnifiedProcess。
3.1
参与者准则
有关一般信息和更多的参与者准则，请参阅RationalUnifiedProcess。
3.1.1
每个具体用例至少涉及一个参与者
每个具体用例是否都至少涉及一个参与者？
如果不是，就存在问题了。
不与参与者交互的用例是多余的，应该将它删除或确定相应的参与者。
在某些情况中，会有多个参与者参与到用例交互中。
请确保检查在一个用例中使用多个参与者是否是有效的（请参阅“参与者泛化关系”）。
3.1.2
直观、描述性的参与者名称
参与者是否是具有直观、描述性的名称？
用户和客户都能理解这些名称吗？
参与者的名称与他们的角色对应，这一点很重要。
如果不是，则更改它们。
您应当参考用例模型来确保为用例中的每个参与者使用了正确的参与者名称。
3.1.3
参与者名称的一致使用
用例规范需要使用一致的参与者名称撰写。
需要注意确保参与者命名是清晰明确的。
不要笼统地使用“参与者”，而应当使用实际的名称来唯一地确定或定义参与者。
参与者名称可以视为是参与到一组系统交互中的角色。
3.2
用例名称
用例名称应是唯一、直观和解释性的名称，从而可以清晰明确地定义从用例获取的值的可观察结果。
检查用例名称的一种好方法是调查客户、业务代表、分析人员和开发人员是否都能理解用例的名称和描述。
请记住：
您需要从参与者的角度定义值的可观察结果。
每个用例名称需要描述用例支持的行为。
名称中需要包含要执行的操作和要操作的关键元素。
通常，这是一种简单的“动词／名词”组合。
用例应当从触发用例的参与者的角度进行命名。
示例包括：
“注册课程”、“选择授课课程”。
3.3
用例简短描述
3.3.1
至少1个段落
用例中需包含用例的简短描述。
此描述的长度至少应当为1个段落，并且不超出3个段落。
描述中需包含用例的关键目的、价值陈述和概念的说明。
3.3.2
示例（可选）
如果简短的示例“故事”能够增加价值，则可以在简短描述中包含它来帮助进一步地描述环境。
此示例通常需遵循基本流，同时在有帮助时包含数据值。
3.4
祈使语气的一致使用：
用例中的系统需求需使用祈使语气撰写。
相对于“应当”和“必须”，通常更倾向于使用“需要”来一致地描述需求。
并且应避免使用暗示需求是可选或未定义的需求的消极词汇，例如，“应该”、“可能”、“等”。
3.5
词汇表术语的使用
用例中使用的所有业务术语在项目的词汇表中进行定义。
如果用例中存在词汇表中未包含的业务术语，则术语需要：
添加到词汇表中，同时包含简短描述（最多1个段落）。
在用例中进行更改，以反映词汇表中定义的正确业务术语。
3.6
“操作”术语的使用
3.6.1
定义系统负责在何处提供操作选项
用例需要明确地说明系统负责在何处提供用作供参与者选择的可用选项的操作。
在多数情况下，可用选项应当作为基本流的组成部分而提供，并在对应的备选流的第一个语句中作为入口点引用。
3.6.2
术语在整个用例中的一致使用
诸如“新建”、“修改”、“取消”、“删除”、“确定”和“打印”之类的术语在整个用例的使用需保持一致：
相同的逻辑操作不能使用不同的术语指代。
特别需要注意确保在备选流中使用的操作术语与在基本流中使用的操作术语匹配。
3.7
参与者和系统行为的独立段落
每次参与者和系统之间的交互改变焦点（在参与者和系统之间）时，下一个行为段需使用新的段落描述。
先描述参与者，然后再描述系统。
句子必须以“<
参与者名称>
需xxxxx”或“系统需xxxx”开始。
始终使用全称来正确地表示参与者名称，而不是使用缩写。
3.8
备选流和子流
每个备选流和子流清晰明确地定义进入流中的所有可能的入口点，并结束于从流中退出的所有可能的出口点。
备选流还将明确地说明出口点和参与者继续到下一步的位置－是返回到基本流中的特定步骤还是结束。
在事件流由于存在复杂的行为而变得混乱时，或者在单个流的长度超出实际的打印页面时，可以使用子流来提高明确性和管理复杂性。
子流使用以下形式撰写：
将自包含的详细行为逻辑组移动到子流中，然后在事件流中以摘要形式引用此行为。
3.9
前置条件和后置条件
用例规范中需包含一组在用例开始之前（前置条件）和用例结束之后（后置条件）期望为真的条件（也称为假定）。
请注意，用例可能会以多种方式结束，对于每种方式应相应地描述其“后置条件”。
3.10
对于缺少的详细信息使用占位符（待定）
在信息尚未定义或尚未确定时，用例中需包含对问题或元素的引用，并包含占位符：
待定。
3.11
补充规范的定义和引用
在一些附加需求无法在事件流期间自然地描述时，可以将这些需求定义为补充需求。
对于那些特定于用例的需求，需在用例规范的“特殊需求”一节中定义。
对于那些在系统范围内适用的需求（特别是非功能性质的那些需求），需在一个或多个独立的补充规范文档中定义。
可靠性：
－系统必须每周7天、每天24小时可用。
－系统的平均故障间隔时间（MTBF）必须为48小时。
性能：
－系统在预期的正常负载条件下的在线响应时间不得超出5秒。
3.12
使用UI原型／设计进行交叉检查
用例内容需对照UI原型／设计进行交叉检查，以确保用例或UI原型／设计中没有缺少任何系统需求。
在需要对用例进行更改时，需进行以下操作：
将对UI原型的更改记录为未来操作的讨论内容。
3.13
异常流（可选）
提供以下准则来帮助发现异常流：
3.13.1
发生什么异常？
对于用例中的每个步骤，需要考虑会发生什么异常。
每个独特的异常都可以捕获为“异常流”。
在某些情况中，单个异常流可以在用例之间共用，例如“超时”。
所要捕获的关键信息是在发生异常时的业务需求，即参与者应体验到什么？
升级会员 