软件构架文档.docx
- 文档编号:11011412
- 上传时间:2023-05-28
- 格式:DOCX
- 页数:32
- 大小:324.65KB
软件构架文档.docx
《软件构架文档.docx》由会员分享,可在线阅读,更多相关《软件构架文档.docx(32页珍藏版)》请在冰点文库上搜索。
软件构架文档
TopTAIS3
软件构架文档
版本<1.0>
修订历史记录
日期
版本
说明
作者
2007-5-15
1.0
初始版本
李荩晖
目录
1.简介5
1.1目的5
1.2范围5
1.3定义、首字母缩写词和缩略语5
1.4参考资料5
1.5概述5
2.构架表示方式6
3.构架目标和约束6
3.1分层结构6
3.1.1业务实体层7
3.1.2实体状态层7
3.1.3原子活动层7
3.1.4复合活动层7
3.1.5业务过程层7
3.1.6界面控制层8
3.1.7页面展示层8
3.2功能划分8
3.2.1业务系统8
3.2.2前台框架8
3.2.3公共组件8
3.2.4外部信息交换8
4.用例视图9
4.1用例:
上门申报9
4.1.1用例实现:
纳税申报12
4.1.2用例实现:
征前减免13
4.1.3用例实现:
抵缴税款15
4.2征收税款17
4.2.1税款征收-现金21
4.2.2税款征收-银行转账22
4.2.3税款征收-税银划款24
4.2.4税款征收-税库划款25
5.逻辑视图27
5.1概述27
5.2在构架方面具有重要意义的设计包27
6.进程视图27
7.部署视图27
8.实施视图28
8.1概述28
8.2层28
9.数据视图(可选)28
10.大小和性能28
11.质量28
软件构架文档
1.简介
目的
TopTais2经过了两年半的运行,暴露出的很多不适应需求变化、严重影响性能的结构问题。
为了适应税收征管系统省级大集中的发展方向,需要从系统架构上对征管系统进行大的调整,以达到真实反映用户需求、快速跟踪需求变化、易于用户理解、简化用户操作、提高系统响应速度、提供更加高效、完善、准确的查询等目标;
本文档将从构架方面对系统进行综合概述,其中会使用多种不同的构架视图来描述系统的各个方面。
它用于记录并表述已对系统的构架方面做出的重要决策。
税收征管系统三版的分析设计人员可以根据本文档进行税务系统的设计工作,并用本文档中的描述作为分析设计任务完成评审时的标准。
范围
所有参与税收征管系统三版的分析设计人员都需要仔细阅读本文档,根据本文档描述的分层、分子系统、分包原则进行系统的分析设计工作。
负责软件系统集成的人员和配置管理人员也需要阅读本文档,用来指导系统的集成配置环境以及系统集成设置等工作。
本文档用以指导后续的系统分析设计工作,本文档的修订将影响后续所有的分析设计模型和相关文档。
定义、首字母缩写词和缩略语
参见《百泉会议纪要》
参考资料
[本小节应完整地列出此软件构架文档中其他部分所引用的所有文档。
每个文档应标有标题、报告号(如果适用)、日期和出版单位。
列出可从中获取这些参考资料的来源。
这些信息可以通过引用附录或其他文档来提供。
]
概述
[本小节应说明此软件构架文档中其他部分所包含的内容,并解释此软件构架文档的组织方式。
]
[本节说明当前系统所使用的软件构架及其表示方式。
还会从用例视图、逻辑视图、进程视图、部署视图和实施视图中列出必需的那些视图,并分别说明这些视图包含哪些类型的模型元素。
]
2.构架表示方式
本文首先描述了规划中的系统分层模型,系统的分层逻辑将作为系统设计的原则贯穿于系统设计的完整周期。
系统进行分层最重要的目的是将繁杂的业务逻辑进行解耦。
将简单的计算、存储等功能剥离出来,采用公共的方式进行实现。
将核心业务逻辑集中在一起,便于对业务逻辑进行配置和整理,同时降低系统开发对于行业资深开发人员的需要。
对于业务计算和存储提出了统一的解决方案,目的在于采用统一的处理方式应对业务操作的复杂性(业务自身的增加、修改、删除)和提供业务处理的效率(不因为运行时间的延续造成系统速度的降低)。
本文主要通过用例视图来描述具体业务活动如何实现系统的分层模型,并且具体描述税收征管系统的分层模型以及各个层次中的分包情况。
3.构架目标和约束
鉴于税务系统的非常复杂,首先根据公司的实际情况对系统进行职能划分,确定系统的分层结构以及各个层次的职责,然后对各个模块以及层次进行详细的描述。
图一:
系统分层结构图
分层结构
软件系统的总共分为七层,由外至内分别是:
页面展示层、界面控制层、业务过程层、复合活动层、原子活动层、实体状态层、业务实体层。
分述如下:
业务实体层
业务实体层负责所有业务相关表证单书(以下简称业务实体)的管理。
业务实体层是纯静态的,没有任何业务操作,只负责业务实体的持久化和版本管理。
实体状态层
实体状态层的职责是管理表达业务实体数据变化过程的描述;业务实体数据变化过程描述分为两类:
活动描述和状态描述;
活动描述:
分为操作记录和业务记录两类;操作记录描述用户使用系统完成业务活动的数据;相当于系统的业务操作日志,用来记录、分析用户的操作情况;业务记录描述业务操作过程形成的对应于实际的业务实体,用来记录业务运行过程;业务过程层需要保证操作记录和业务记录之间的数据一致性和完整性;
状态描述:
分为状态变化记录和当前状态记录两类;业务状态是业务主体对象所处的某种状态的简称,业务状态一般具有临时性、易变性,描述了业务主体逐步演化的过程。
状态数据的处理要仔细考虑并发处理的情况。
状态有以下特性:
●业务状态的变迁由业务活动驱动;
●状态变化记录描述了业务状态变化的过程;
●当前状态记录描述了系统当前状态的实时情况;
●状态变化记录和当前状态记录之间的数据一致性由状态层保证;
领域操作层
完成领域模型内的操作、操作记录以及对外服务。
领域操作层封装了领域模型的对外接口,负责只涉及自身实体数据变化的业务操作。
在业务比较简单时,领域模型可以只有一个领域操作层,将业务操作、业务记录保存集中在一起实现。
当业务操作比较复杂(涉及多个状态变化)时,可以将领域操作层分为以下两个层次:
原子操作层
原子活动是业务主体对象的最小变化逻辑,负责将业务主体对象从一个状态迁移到另一个状态,在状态的迁移过程中不存在中间状态;原子活动有如下特性:
●原子活动是基于业务对象的,原子活动只描述某一个业务对象的状态变化;
●原子活动的执行不依赖于其他原子活动,只依赖于迁出的业务状态是否允许;
●原子活动保证状态变化前后的稳定性和一致性;
●原子活动本身的过程记录到活动数据中;
复合活动层
复合活动层负责业务化的活动封装,将领域模型能够对外提供的接口封装起来,保证相关的一组活动能够按照一个约定的次序执行。
因此复合活动层需要关注业务活动的执行和撤销,注意撤销时的业务活动次序与正向流程相反。
同时,复合活动层负责记录活动记录本身,包括活动、活动的修改、活动的删除、活动的冲销等操作。
业务逻辑层
业务逻辑层完成各个领域模型之间的业务逻辑,并对上层提供完整的业务结果;业务逻辑层是业务过程处理的核心,负责处理事务化的业务流程;业务逻辑负责调度一个或者多个业务活动的执行与否和执行次序,并且保证这些业务活动的同步和事务,业务逻辑本身不完成具体的业务操作;业务逻辑负责达成用户操作的目的,基本上可以对应于用例模型中的用例;系统中的配置项大部分作用于业务逻辑。
界面控制层
界面控制层负责用户操作页面的调度,界面流程的控制。
界面控制负责在收集到足够的信息后将用户操作请求发送给业务过程层用以完成用户要求的工作。
页面展示层
页面展示层负责提供业务过程的前台展示工作;展示用户完成业务工作所需要了解的信息,辅助用户录入业务数据、检查用户录入数据的完整性、校验用户录入数据的有效性。
页面展示层将用户录入的信息提交给界面控制层;
功能划分
整个系统分为公共框架、业务系统和外部信息交换系统三个部分。
公共框架又分为前台框架和后台公共组件两个部分。
业务系统
业务系统指完成特定用户业务要求的系统,和税收征管业务密切相关的各个功能模块都属于业务系统的范畴。
业务领域层的分包(分子系统)的原则是根据不同的业务主体对象进行分包,将不同的业务主体对象分别封装在不同的包中。
业务主体对象之间允许存在引用关系,业务主体对象之间的引用关系需要参照系统分析模型中的定义。
当前税务系统中的业务主体对象基本可以分为纳税人模型、税款模型、税票模型、发票模型、案件模型等。
前台框架
前台框架为系统提供统一的前台展现支持,将所有系统涉及的展现控制都集中起来,保证业务系统对外展现的一致性;
前台框架提供了对页面元素的统一支持,包括页面分区、菜单管理、提示区管理、多页面支持、统一的Grid支持、代码解析工具等。
公共组件
提供一系列公共服务支持,包括组织机构、权限管理、待办事宜、任务管理、工作流、文书管理、消息管理、统一配置管理、日志管理等功能。
外部信息交换
作为系统对外部的接口,外部信息交换系统提供了系统与外部应用之间的统一衔接方式,外部信息交换系统屏蔽掉所有系统内部实现细节,对外部提供业务语义级的服务接口;外部信息交换用于支持核心系统和周边系统之间的衔接;外部信息交换对外提供系统数据的查询服务和业务操作入口功能,对内提供外部数据传递和访问服务;
4.用例视图
图二:
架构中的典型用例
本节抽取两个典型用例来描述如何根据分层架构来进行用例分析,具体描述了各个层次之间的职责划分和具体实现方案。
用例:
上门申报
图三:
上门申报-本地视图
上门申报由申报受理岗发起,完成纳税人到征收大厅的申报处理过程。
前置条件:
纳税人已经完成了税务登记,纳入正常管理;
基本流:
1、操作员输入纳税人识别号;
2、系统根据输入的纳税人识别号查找纳税人信息,并且查找税种登记、减免、停业、预缴、警示等相关信息;
3、操作员录入纳税人申报信息并检查纳税人未申报税种;
4、系统根据录入的纳税人申报信息计算应纳税额、抵免金额等,从而计算出应补退税额;
5、操作员确认计算结果并提交系统;
6、系统将计算好的各项税额分别记录保存;
7、系统提示申报成功;用例结束;
后置条件:
纳税人的申报结果已经记录在系统中,可以依据申报结果进行税款清缴。
扩展点:
在步骤2中,当发现纳税人是非正常户时,完成非正常户恢复用例;
图四:
上门申报-基本流(序列图)
图五:
上门申报-基本流(协作图)
如上图所示,系统的核心逻辑控制分为四层:
1、界面控制层(上门申报受理)负责通过控制页面调度来将信息展示给用户,同时搜集必要的信息组装成过程控制信息(申报过程记录)传递给业务过程层(申报过程控制);
2、业务过程层负责调度复合活动层来完成具体的业务逻辑(在上门申报用例中过程相对简单,复杂逻辑参见下例);
3、复合活动层负责活动记录的持久化以及原子活动的次序调用;
4、原子活动层完成具体的业务活动;详细活动描述参见活动用例实现。
上门申报-用例实现关系
用例实现:
纳税申报
纳税申报活动负责记录纳税人的申报,申报活动增加纳税人的待征税款,同时增加纳税人的应征税款。
图六:
纳税申报-基本流(序列图)
图七:
纳税申报-基本流(协作图)
如上图所示,原子活动层通过协调多个状态变化完成状态迁移功能;状态管理维护单个状态的变化。
用例实现:
征前减免
征前减免负责完成记录待征税款到减免税款的转移过程,减少待征税款,增加已减免税款。
图八:
征前减免-基本流(序列图)
图九:
征前减免-基本流(协作图)
用例实现:
抵缴税款
抵缴税款负责完成记录待征税款到多缴税款的转移过程,减少待征税款,减少多缴税款。
抵缴税款-基本流(序列图)
抵缴税款-基本流(协作图)
征收税款
征收税款用例由税款征收岗发起,完成纳税人待征税款的征收处理过程。
纳税人待征税款一般来源于上门申报,但是某些处理处罚也会形成纳税人的待征税款。
纳税人缴纳税款有多种形式,除包括传统的银行转账缴纳、现金缴纳外,还有随着信息化发展而来的税银联网划款、税库银联网划款等多种方式。
前置条件:
纳税人已经存在待征税款;
基本流:
1、操作员输入纳税人识别号;
2、系统根据输入的纳税人识别号查找纳税人待征税款信息;
3、操作员录入纳税人实际缴纳金额并选择缴纳方式;当发现当前日期超出纳税人待征税款的限缴日期时,提示操作员需要加收滞纳金;
4、系统根据操作员录入的纳税人实际缴纳金额和选择的缴纳方式进行处理;税银转账的需要通知银行系统、税库银转账的需要通知国库系统;
5、系统提示征收完成,并开具相应的票据;
6、用例结束;
后置条件:
1、纳税人的待征税款减少实际缴纳的金额;
2、现金征收时操作员手中的现金增加;
3、银行转账时纳税人的待上解税金增加;
扩展点:
在步骤4中,操作员选择的是税银转账时,进入税银转账用例;
在步骤4中,操作员选择的时税库转账时,进入税库转账用例;
在步骤4中,当发现当前日期超出纳税人待征税款的限缴日期时,进入滞纳金加收用例;
征收税款-基本流(序列图)
征收税款-基本流(协作图)
在上图中,显示了上面三层逻辑职责:
1、界面控制层(征收税款受理)负责通过控制页面调度来将待征收信息展示给用户,同时确定用户的实缴金额和缴款方式,并将这些信息组装成过程控制信息(征收过程记录)传递给业务过程层(征收过程控制);
2、业务过程层负责调度复合活动层来完成具体的业务逻辑封装,征收时需要同时考虑票证的使用、滞纳金的收取等业务逻辑;这些逻辑的整合是业务过程层的主要任务,也就是我们经常提到的“业务逻辑”
3、复合活动层负责具体的税款征收记录和票证使用记录,根据不同的征收方式会有不同的税款记录形式,因为这里是一种“并行”的方式,不同于申报时的“串行”方式,所以不在上图中展现了,具体内容见后面的用例实现。
4、原子活动层完成具体的业务活动;详细活动描述参见活动用例实现。
征收税款-用例实现关系
税款征收-现金
税款征收-现金用例描述了采用现金方式征收税款时的系统处理逻辑;
税款征收-现金(序列图)
税款征收-现金(协作图)
税款征收-银行转账
税款征收-银行转账用例描述了纳税人自行到银行采用转账形式缴纳税款时的系统处理逻辑;
税款征收-银行转账-基本流(序列图)
税款征收-银行转账-基本流(协作图)
税款征收-税银划款
税款征收-税银划款用例描述了采用税银联网后操作员通过系统联网直接将纳税人税款划转时的系统处理逻辑;
税款征收-税银联网划款-基本流(序列图)
税款征收-税银联网划款-基本流(协作图)
税款征收-税库划款
税款征收-税库划款用例描述了采用税库银联网后操作员通过系统联网直接将纳税人税款划入国库时的系统处理逻辑;
税款征收-税库划款-基本流(序列图)
税款征收-税库划款-基本流(协作图)
5.逻辑视图
概述
图业务系统整体分层结构
整个系统分包方面可以分为三层:
业务层包含操作页面、界面控制、业务过程等逻辑层,按照业务过程进行纵向划分;领域层包括复合活动、原子活动、状态控制等逻辑层,根据核心业务主体进行划分;实体层封装业务实体的管理,根据实体业务类别分包;公共组件层包含和具体业务无关的支撑环境组件。
业务层
业务层基本上按照业务过程进行分包,分包原则是保证相关业务过程的完整性,便于从业务层进行系统规模调整,为用户提供涵盖不同功能范围的产品。
领域层
领域层按照业务主体进行分包,业务主体是业务系统中关注的主要实体;业务主体需要在多个业务部门共享信息;业务主体是可以不依附于其他业务主体单独存在的业务实体;
业务实体层
业务实体具体到税务系统就是对应于实际纸质存在的表证单书,分包逻辑参见业务层的划分方式。
在构架方面具有重要意义的设计包
税款模型
税款模型-内部分包描述
税款实体-类依赖关系
税款状态变化
税款状态-待征状态描述
纳税申报-类依赖关系
税款征收-类依赖关系
在税款模型中,对外提供服务的是复合活动控制,包括申报活动控制和征收活动控制等,它们为业务系统提供完整的税款变化服务,保证同一个业务的内部状态关系一致;原子活动负责在税款两个状态之间的迁移任务,保证状态之间的关系一致;状态管理负责管理状态内部的变化情况和当前状态的一致性。
6.进程视图
暂略。
7.部署视图
暂略。
8.实施视图
概述
[本小节指定并定义各个层及其内容、添加到指定层时要遵循的规则以及各层之间的边界。
还应包括一个显示层间关系的构件图。
]
层
[对于每个层,都用一个小节来加以说明,其中包括该层的名称和一个构件图,并列举位于该层的子系统。
]
9.数据视图(可选)
暂略。
10.大小和性能
暂略。
11.质量
暂略。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 构架 文档