《系统设计说明书》参考模版.docx

上传人:b****3 文档编号:5683574 上传时间:2023-05-09 格式:DOCX 页数:36 大小:473.95KB
下载 相关 举报
《系统设计说明书》参考模版.docx_第1页
第1页 / 共36页
《系统设计说明书》参考模版.docx_第2页
第2页 / 共36页
《系统设计说明书》参考模版.docx_第3页
第3页 / 共36页
《系统设计说明书》参考模版.docx_第4页
第4页 / 共36页
《系统设计说明书》参考模版.docx_第5页
第5页 / 共36页
《系统设计说明书》参考模版.docx_第6页
第6页 / 共36页
《系统设计说明书》参考模版.docx_第7页
第7页 / 共36页
《系统设计说明书》参考模版.docx_第8页
第8页 / 共36页
《系统设计说明书》参考模版.docx_第9页
第9页 / 共36页
《系统设计说明书》参考模版.docx_第10页
第10页 / 共36页
《系统设计说明书》参考模版.docx_第11页
第11页 / 共36页
《系统设计说明书》参考模版.docx_第12页
第12页 / 共36页
《系统设计说明书》参考模版.docx_第13页
第13页 / 共36页
《系统设计说明书》参考模版.docx_第14页
第14页 / 共36页
《系统设计说明书》参考模版.docx_第15页
第15页 / 共36页
《系统设计说明书》参考模版.docx_第16页
第16页 / 共36页
《系统设计说明书》参考模版.docx_第17页
第17页 / 共36页
《系统设计说明书》参考模版.docx_第18页
第18页 / 共36页
《系统设计说明书》参考模版.docx_第19页
第19页 / 共36页
《系统设计说明书》参考模版.docx_第20页
第20页 / 共36页
亲,该文档总共36页,到这儿已超出免费预览范围,如果喜欢就下载吧!
下载资源
资源描述

《系统设计说明书》参考模版.docx

《《系统设计说明书》参考模版.docx》由会员分享,可在线阅读,更多相关《《系统设计说明书》参考模版.docx(36页珍藏版)》请在冰点文库上搜索。

《系统设计说明书》参考模版.docx

《系统设计说明书》参考模版

 

交行集中工作平台

设计说明书

 

2008年5月

 

1

引言

1.1编写目的

[说明编写这份设计书的目的,指出预期的读者和有关阅读建议。

]

本设计说明书文档包括该项目的建设背景、目标、建设容、系统架构、接口、数据模型、功能模型、部署模型、功能设计等的描述,用于指导该项目的开发与部署,同时,作为该项目的重要技术资料,作为系统未来维护或扩展的参考。

本文档的阅读者为本系统的设计、开发人员、接口系统的开发人员、系统维护人员。

1.2名词术语

[描述与该系统相关的特定概念和术语,如某些缩写代号,统一的词汇表达等]

MISUP:

MISUniformPlatform,MIS统一架构平台,交通银行为支撑灵活的、高效的、易管控的、良好用户体验的管理型应用的开发、运行和管理,而规划建立的符合SOA技术的MIS应用统一架构体系,该体系规划包括相应的方法论、平台(工具)以及交通银行IT资产容。

集中工作平台:

应用基础框架:

集中任务中心:

EOS:

EXT:

SOA:

Service-OrientedArchitecture,面向服务的架构,SOA是一个软件架构,同时也是一个构件模型,它将企业应用的不同功能单元(称为业务服务)通过这些服务之间定义良好的接口和契约联系起来。

接口是采用中立的方式进行定义的,它应该独立于实现服务的硬件平台、操作系统和编程语言。

这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。

本项目中涉及SOA概念,主要侧重于松散耦合的应用架构、复用、业务构件化的意义。

1.3参考资料

[列出有关的参考文件,如:

·本项目的经核准的计划任务书或合同、上级机关的批文;

·属于本项目的其他已发表文件;

·本文件中各处引用的文件、资料,包括所要用到的软件开发标准。

·列出这些文件的标题、文件编号、发表日期和出版单位,说明能够得到这些文件资料的来源。

]

《集中工作平台预研总结报告.doc》

《集中工作平台技术预研工作总结.ppt》

《MISUP-IWP项目设计与开发规.doc》

1.4文档约定

[说明本文档中的有关约定信息,例如名词的缩写,代码表示,隐含式的约定等。

]

本文档中工作流引擎指EOS工作流平台的工作流引擎,交通银行简称为“交行”,普元软件技术()简称为“普元”。

Bankcomm:

交行或者交通银行

Primeton:

普元或普元软件技术()

本文档中所涉及的构件包、构件均表示基于EOS平台的构件包和构件概念。

2总体设计

2.1建设背景

[说明:

·为什么要建这套系统

·要达到的目标是什么]

交通银行大集中完成后,大量的MIS系统迫切需要建设,然而我行MIS应用建设的方式还是相对孤立的。

尽管采用了单点登录、统一认证、门户整合、企业总线等方面的技术,但在应用与应用之间,缺乏统一的业务构件规划;应用实施过程中,缺乏业务构件的抽象和抽取,因此无法形成IT资源的有效积累和复用;各个应用分别建设,又缺乏公共资源的复用,导致各个应用需要分别实现用户、权限管理,以及应用的UI框架,导致IT建设的重复投入,以及使用者的体验不好。

Internet已经日益成为应用程序开发的默认平台。

用户对应用程序复杂性要求日增,但现在的Web应用程序对完成复杂应用方面却始终跟不上步伐。

用户与今天中等复杂程度的Web应用程序交互时,其体验并不能令人满意。

上面的这些问题,实际上也是大多数大型企业(包括同业)IT建设中的共同挑战,而SOA的理念和规(标准)的一步步完善,为解决这些问题带来了曙光,而国平台厂商以及同业银行做出的实践,初步验证了企业级业务构件化和统一架构的可行性。

在这样一个外因素的背景下,软件中心提出了MIS系统规划和建设的更大目标:

建立以业务构件化为基础的,符合先进技术发展趋势的交行MIS统一架构平台(MISUP),以支撑灵活的、高效的、易管控的、良好用户体验的管理型应用的开发、运行和管理。

其中,集中工作平台作为MIS统一架构平台的重要组成部分,关系到使用者的体验,成为最先建设的重点容。

2.2系统建设目标

[描述系统建设的目标,适用围和相关原则]

集中工作平台实施完成后,将成为交行MIS应用的基础平台,各个MIS系统将遵循该平台的相关规接入进来,并提供统一的用户操作入口,因此,在设计上将重点考虑如下特性:

应用模型的通用性和可扩展能力,技术框架的灵活性,运行的效率和稳定性。

以下列出了集中工作平台具体的建设目标:

2.2.1提高用户体验

希望提供给用户:

●UI展现、操作友好

⏹易交互:

交互性强,尽量不使用或少使用页面全部刷新的不友好方式,而采用基于ajax技术的局部刷新效果;

⏹丰富的控件:

开发或集成丰富的UI控件,既丰富了用户的交互手段,又方便了开发人员。

●集中桌面

⏹一次登录:

用户一次登录,即可在各应用中间切换

⏹一个工作平台:

提供给用户一个统一的工作平台,用户在该平台上即可完成各项操作。

正是基于上述原因,要求本系统实现:

●支持RIA的UI框架;

●MIS应用桌面。

2.2.2建立统一的MIS应用架构

希望给各个应用提供:

●公共模型及服务

⏹用户、组织机构模型:

从现有系统和交行实际,抽取出公共的模型,为各应用服务;

⏹权限模型:

从现有系统和交行实际,抽取出公共的模型,为各应用服务。

●集中流程任务处理

⏹待办工作:

抓取用户在各应用中的待办任务,统一展现给用户处理;

⏹已办工作:

抓取用户在各应用中的已办任务,供用户查看。

⏹待阅中心:

抓取用户在各应用的待阅消息,供用户查看。

正是基于上述原因,要求本系统实现:

●应用基础框架;

●集中任务中心。

2.2.3集中工作平台

以上四个目标有机形成集中工作平台,提供交行MIS应用的应用统一入口:

2.3设计和实现约束

[描述系统设计和实现中受到的约束,包括设计与实施策略、开发工具、团队结构、时间表、遗留代码等。

]

通过项目启动前的方案验证和技术预研工作,为本项目的实施打下了良好的基础,并确定了如下的设计和实现原则:

●技术架构采用J2EE+普元EOS6

●UI框架采用EXT2

●应用桌面采用Portal实现

●用户认证采用LDAP

2.4组织结构和用户类

[描述系统涉及的组织机构,系统相关的用户]

集中工作平台旨在为未来交行MIS应用提供统一的应用框架、组织模型、权限控制,因此,几乎交行所有需要使用MIS应用(如HR、OA、CRM、资金管理等)的人员均作为该平台的用户,并且涉及到交通银行的所有组织机构,同时,交通银行的某些合作伙伴(如开发中心的外协公司)也可能是该平台的用户。

由于本平台涉及的组织结构和用户非常庞大,而且与未来接入本平台的应用相关,无法列出最终完整的组织结构,下图仅作为组织结构的一个示例。

使用本平台及其架构的用户类如下:

●业务用户(普通用户)

通过集中工作平台,使用各个具体应用系统功能的操作用户,他们一般的操作行为是:

通过集中工作平台的统一登录,进入到集中工作平台的主界面,可以浏览到他可以使用的功能菜单树,可以看到自己的集中任务列表,也可以选择自己的菜单项定义为快捷菜单。

普通用户通过点击自己权限围可以看到的菜单项,进入具体的应用功能界面。

由于接入系统的差异性,业务用户的用户特征差异化很大,操作应用系统的方式的差异也很大,但共同的特性就是:

希望在使用不同应用的功能时,不希望多次登录,并希望所有系统的功能能够集中显示,各个应用系统功能具有一致的操作风格和模式。

业务用户由于群体广泛,使用的电脑终端的差异性可能也会比较大,包括客户端的硬件配置、操作系统版本、浏览器类别和版本,这些差异化要求集中工作平台对于系统环境具有较广泛的兼容性。

●集中工作平台管理员

集中工作平台的管理员主要负责维护集中工作平台的应用基础框架,如应用接入的注册和管理,统一组织模型、集中任务的管理、监控和手工数据同步。

集中工作平台管理员要求对集中工作平台的架构和相关接入规比较熟悉,对计算机应用系统的操作比较熟练。

●应用系统管理员

应用系统管理员主要负责通过集中工作平台维护其管理的接入应用,包括应用的权限定义、角色设置、参数维护、数据同步等。

应用系统管理员熟悉电脑操作,了解集中工作平台的接入规。

●机构管理员

机构管理员主要负责通过集中工作平台维护组织机构和人员信息,以及实现与各个接入应用的组织和人员数据的导入与导出等。

机构管理员有管理上的层次,不同层次的机构管理员具有不同层次的数据操作权限

机构管理员熟悉电脑操作,了解集中工作平台提供的组织模型结构关系和相关接口。

●应用系统开发人员

应用系统开发人员指接入集中工作平台的应用项目开发团队技术人员,他们需要了解集中工作平台的相关架构、公用框架、模型、规、接口,以确保实施的应用能够无缝接入到集中工作平台中。

另外,开发人员需要将开发的功能定义到集中工作平台的功能管理中。

应用系统开发人员熟悉电脑操作和软件开发技术。

在系统机构设计和功能设计上,要求充分考虑用户类的使用特征,更好满足使用者的操作体验。

2.5系统架构

[描述系统的总体框架,从技术、应用、功能几个角度介绍系统组成,使用图例的方式描述子系统、业务单元(功能模块)和工具之间的关系。

使用图例方式描述本系统与外围环境的关系,使用文字描述业务基础件(基础构件库)的在系统中的作用]

2.5.1技术架构

[从技术角度描述系统组成,包括系统使用平台,框架,技术及他们之间关系]

2.5.2应用架构

[从应用角度描述系统平台和各个应用的关系]

2.5.3功能架构

[从功能角度描述系统的功能及功能之间,功能和用户之间的关系]

2.5.4UI架构

【从用户交互的角度,描述系统最终的用户操作界面的布局】

2.6接口设计

2.6.1外部接口

[描述系统同外界的所有接口的安排包括软件与硬件之间的接口、本系统与各支持软件之间的接口关系。

]

2.6.2部接口

[描述系统之的各个系统元素之间的接口的安排]

2.7系统环境

[根据需求的要求描述系统运行的工作环境]

2.7.1网络拓扑

[描述部署和运行系统的一种或多种物理网络(硬件)结构,应该包括运行系统的物理节点(计算机、CPU)及其互连情况(总线连接、LAN连接、点到点连接等)。

]

2.7.2硬件环境

[简要地说明系统对硬件环境的要求]

2.7.3软件环境

[简要地说明系统对软件环境的要求]

2.8非功能特性设计

[以列表的方式介绍系统非功能性的特性,以及对特性相关设计,包括系统易用,可管理,低维护成本]

2.8.1系统兼容性

[描述系统可能运行的软硬件平台环境以及采用的应用平台的兼容性说明]

2.8.2安全性

[描述为保证系统应用安全,包括通讯安全,数据安全,为保证安全采取的备份和故障应急处理的策略]

2.8.3运行效率

[描述系统能够支持的处理能力,吞吐量,响应时间等定能指标]

2.8.4可扩展能力

[描述系统为以后功能和性能扩展提供的特性]

2.8.5用户文档

[描述系统为用户培训,用户使用系统帮助方面提供的文档]

3系统公共模块设计

[描述系统公共模块的设计]

3.1权限控制

 

3.2日志处理模块

[描述系统日志处理设计和日志使用规]

3.3异常处理模块

1、在构件包中建立异常资源文件,针对错误码,包括显示在页面的提示和真正的错误提示,例如:

abf_auth_0001=无效的用户名或者密码!

[用户{0}密码错误!

]

其中{0}表示变量,如果异常提示中有多个变量,依次为{0},{1}…[]的信息为真正的错误信息。

如果没有,则和前面信息一致。

显示给用户的信息为[]前的信息。

异常资源文件为构件包资源配置目录下resources/exception/exception.properties

2、错误码的构成规则

构件包名+”_”+四位数字:

例如abf_auth_0001

3、实现一个写业务异常的运算逻辑

接口如下:

publicstaticvoidsetBusiException(StringerrCode,StringlogFlag,String...params)throws.eos.system.exception.EOSException

第一个参数是资源文件中定义的错误码

第二个参数为是否写业务日志的标志,缺省为“true”,其他值为不写

第三个参数开始,为异常资源中的变量,当异常资源定义中,对应错误码的信息汇总有{0},{1},{2},则需要设置第三、四、五个参数

在该运算逻辑中,将实现如下处理逻辑:

4、业务逻辑中,当需要进行业务异常提示时,调用写业务异常的运算逻辑,由于运算逻辑会抛除异常,所以该运算逻辑将连接在一个结束图元前。

5、通过EXT提供一个显示业务异常的提示页面,当发生异常时,弹出业务异常提示窗口。

3.4Session处理

Session将保存如下信息:

1)用户基本信息:

2)用户所属机构信息:

3)用户所属岗位信息:

4)用户所属工作组信息:

5)用户所属角色信息:

6)用户包含的功能列表:

 

3.5UI框架设计

【将UI架构进行细化,形成可实施的设计方案】

4应用基础框架子系统设计

[针对应用需求进行设计,如果分为多个子系统,则每个子系统作为一个一级目录进行设计]

4.1系统框架

4.1.1概述

应用基础框架(ABFrame)为集中工作平台提供基础的支撑,同时也为未来接入集中工作平台的其他应用提供基础框架以及权限控制的有关服务,主要的功能框架如下图所示:

使用应用基础框架(ABFrame)的主要场景和作用包括:

1、集中工作平台通过ABFrame实现交行MIS系统组织机构和权限模型的统一和数据的统一管理

2、为未来新的MIS系统建设,提供了一套可供复用的应用框架,提升了新应用开发的起点,也保持了各个应用之间基础框架的一致性

3、集中工作平台通过ABFrame实现了交行组织机构和用户的统一管理,可以为各个应用提供组织和用户数据的导出

4、集中工作平台通过ABFrame实现了MIS系统的权限控制服务,可以为各个应用提供用户在应用中的权限数据

4.1.2业务流程描述

注意:

在设计业务流程时候,关心的是业务本身的流程,而不是功能的流程,对于功能流程在功能设计中描述

应用基础框架主要是基础数据的管理,并无明显的业务流程,故该部分省略。

4.1.3用例描述

[列出用例模型中的一些用例或场景,这些用例或场景应体现最终系统中重要的、核心的功能;或是在构架方面涉及围很广(使用了许多构架元素);或强调或阐明了构架的某一具体的细微之处。

]

在应用基础框架中,可以按照用例的特征和松散耦合的情况,划分为主控性的用例和三大部分,分别为:

权限管理、组织机构管理、应用基础工具和服务等,如下图:

集中工作平台

管理员

应用系统管理

机构管理员

组织管理

权限管理

显示应用桌面

用户登录

<>

用户退出

修改个人信息

修改个人密码

设置快捷功能

集中工作平台

业务应用系统

<>

<>

<>

<>

基础工具服

设置个人菜单树

找回密码

操作员(普通用

户)

注册个人账户

主控制部分的用例描述:

参与者

用例

触发方式

需求特性描述

优先级

操作员

用户登录

地址首页

1、可以选择界面样式

2、记录登录出错次数,登录时间

3、显示应用桌面(主界面)

操作员

用户退出

点击主界面功能按钮

1、关闭窗口,或退回到首页(登录页)

2、系统清除用户Session

操作员

修改个人密码

菜单

在输入原有密码正确的前提下,修改个人的登录密码

操作员

设置快捷功能

点击菜单

或者点击主界面功能按钮

1、用户可以定制应用的功能到快捷菜单

2、快捷菜单显示在portal醒目位置

3、用户点击快捷菜单,平台进入快捷菜单对应的应用功能

操作员

设置个人菜单树

菜单

允许每个人根据自己所具有的功能(来自不同的系统)组织自己的菜单树

操作员

修改个人信息

菜单

允许操作员查看和修改自己的信息,包括联系方式、出生日期、等

操作员

注册个人

点击首页面按钮

输入个人信息

操作员

找回密码

点击首页面按钮

输入信息,重置密码并发送到

其他三部分的用例将在下面章节进行描述。

4.1.3.1权限管理的用例描述

权限管理部分主要处理与权限管理控制相关的数据维护的用例,如下图:

(1)应用功能管理

移动功能到另一个功能组下

查看功能组信息

增加功能组

修改功能组信息

删除功能组

查看功能信息

增加功能

修改功能信息

删除功能

浏览应用树

查看应用信息

注册新应用

修改应用信息

集中工作平台

管理员

(fromUseCaseView)

...

删除应用

应用系统管理

(fromUseCaseView)

...

移动功能组到另一个功能组

用例描述:

参与者

用例

触发方式

需求特性描述

优先级

应用系统管理员

浏览应用树

菜单

1、一级节点为应用

2、应用展开为功能组(允许多层)

3、功能组展开为下属功能组或功能

应用系统管理员

查看应用信息

点击应用树的应用节点

1、能够看到应用的信息

2、可以看到应用包含的岗位列表

3、可以看到应用包含的工作组

集中工作平台管理员

注册新应用

1、点击应用树根结点的右键菜单

2、菜单

1、输入新应用的信息

2、点击保存

3、刷新应用树(如果从应用树右键触发)

集中工作平台管理员

删除应用

点击应用树根结点的右键菜单

1、删除应用记录

2、删除应用对应的功能组、功能

3、删除应用对应的菜单

4、删除与相应功能对应的角色关联和操作员关联

应用系统管理员

修改应用信息

1、点击应用信息页面的按钮

修改应用信息后保存

应用系统管理员

查看功能组信息

点击应用树的功能组节点

1、能够看到功能组的定义信息

2、能够看到功能组包含的功能清单

应用系统管理员

增加功能组

1、点击应用树功能组节点的右键菜单

2、点击功能组信息页面的按钮

1、增加功能组的信息

应用系统管理员

修改功能组信息

1、点击应用树功能组节点的右键菜单

2、点击功能组信息页面的按钮

1、修改功能组的信息

应用系统管理员

删除功能组

1、点击应用树功能组节点的右键菜单

2、点击功能组信息页面的按钮

1、删除功能组的信息

应用系统管理员

查看功能信息

1、点击应用树的功能节点

2、点击功能组信息页面功能列表的功能

1、能够看到功能的定义信息

2、能够看到功能所包含的资源清单

3、能够看到拥有该功能的角色和操作员

4、查看与该功能有约束关系的功能列表

应用系统管理员

增加功能

1、点击应用树的功能节点

2、点击功能组信息页面功能列表的功能

1、增加功能的信息

2、设置功能的约束关系

3、配置功能的资源清单(通过构件包导入后选择)

应用系统管理员

修改功能信息

1、点击应用树的功能节点

2、点击功能组信息页面功能列表的功能

1、修改功能的信息

2、修改功能的约束关系

应用系统管理员

删除功能信息

1、点击应用树的功能节点

2、点击功能组信息页面功能列表的功能

1、删除功能的信息

2、删除功能的约束关系

应用系统管理员

移动功能到另一个功能组下

通过拖拽应用树的功能节点到另一个功能组节点触发

改变功能所属的功能组

应用系统管理员

移动功能组到另一个功能组下

通过拖拽应用树的功能组节点到另一个功能组节点触发

改变功能组所属的功能组

(2)菜单管理

用例描述:

参与者

用例

触发方式

需求特性描述

优先级

应用系统管理员

根据应用树产生菜单树

1、点击应用信息页面的功能按钮

2、点击应用树的应用节点右键菜单项

1、根据应用-功能组-可定义为菜单的功能项,产生树形节点,并允许选择

2、选择需要产生菜单的功能项(缺省为选中)

3、点击初始化成菜单的功能按钮

应用系统管理员

浏览菜单树

菜单

1、一级节点为应用

2、应用展开为菜单(允许多层)

应用系统管理员

查看菜单项信息

点击菜单树的菜单节点

1、能够看到菜单的定义信息

2、能够看到菜单所包含的功能

应用系统管理员

增加菜单项

1、点击菜单树的菜单节点右键菜单

2、点击菜单信息页面的功能按钮

1、增加菜单的信息

2、设置菜单和功能的对应关系

3、配置菜单功能的资源清单

应用系统管理员

修改菜单项信息

1、点击菜单树的菜单节点

2、点击菜单信息页面的按钮

1、修改菜单的信息

应用系统管理员

删除菜单项

1、点击菜单树的菜单节点

2、点击菜单信息页面的功能按钮

1、删除菜单的信息

2、删除菜单的所有子菜单

应用系统管理员

移动菜单项到另一个菜单下

通过拖拽菜单树菜单节点到另一个菜单节点触发

将菜单及其子菜单移动到指定节点下

(3)角色管理

(4)操作员管理

 

4.1.3.2组织机构管理的用例描述

 

4.1.3.3应用基础工具和服务的用例描述

 

4.1.4实体关系描述

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > IT计算机 > 电脑基础知识

copyright@ 2008-2023 冰点文库 网站版权所有

经营许可证编号:鄂ICP备19020893号-2