基于 ARENA 平台高层业务软件的分层架构设计方法 【技术领域】
本发明是一种基于模块化设计思想的软件设计方法, 具体是一种基于 ARENA 平台 高层业务软件分层架构设计方法。 【背景技术】
目前基于大唐 ARENA 平台整个软件 UI 实现层、 业务层、 平台层相关部分之间的藕 合度太大, 当更新 UI、 平台改变等都需要作较大的改变, 这样给代码移植、 功能扩展等带来 很大困难, 为此采用分层的方式减少模块之间、 子模块之间的藕合度。 同时业务层可向外独 立提供模块接口, 所以业务层接口设计中应包括模块启动、 外部事件处理部分。
目前高层业务软件部分实现主要分为三种情况 ( 如图 1 所示 ) :
(1) 第三方完成 UI( 用户界面 User Interface) 及业务部分, 只需要移植完成 porting 层代码。
(2) 第三方完成业务部分, 应用需要完成 UI 及 porting 层。
(3) 独立研发完成所有功能 ( 包括 UI、 业务部分以及 UI 层与业务层之间的藕合 )。
其中 (3) 中, 独立研发模块 UI 层与业务层之间的藕合方式主要为三种 ( 如图 2 所 示): (1) 消息 ; (2) 接口 ; (3) 代码藕合即直接调用。
对于独立研发、 第三方移植等模块与模块之间的交互主要采用接口、 消息、 AMS( 启 动, 交互 ) 和外部事件处理等。这样整个软件部分处于高藕合、 低内聚状态, 给移植、 代码维 护带来极大的不便。如图 2 所示, 如果采用第一种方式即消息耦合, 将此模块移植到其它平 台且消息接口改变, 则需要将所有消息接口改变 ; 如果直接耦合 UI 代码 ( 刷屏等接口 ), 移 植到其它平台时由于 UI 接口改变需求修改所有相关代码 . 如果采用注册回调方式, 业务层 只需要调用 UI 层实现的回调接口即可, 即使移植到其它模块, 业务层不需要作任务修改。 【发明内容】
为了解决现有技术中存在的上述问题, 本发明提出一种基于模块化设计思想的软 件设计方法——基于 ARENA 平台高层业务软件分层架构设计方法, 具体技术方案如下 :
1、 一种基于 ARENA 平台高层业务软件分层架构方法, 其特征是包括步骤 :
1) 先把各个高层业务模块统一分解为 UI 层、 业务层和适配层 ;
2) 再设定每一个高层业务模块的功能 :
2.1)UI 层 : 完成人机交互 ; 为业务层提供业务刷屏接口 ; 向与该 UI 层有接口交互 的提供接口 ;
2.2) 业务层 : 完成本模块业务需求 ; 提炼 UI 通知及平台相关接口 ; 向与该业务层 有接口交互的模块提供功能性接口 ;
2.3) 适配层 : 提供业务层与平台的适配接口。
所述业务层提炼 UI 通知及平台相关接口, 是在移植过程中由 UI 及平台实现。
所述业务层中的实现避免与平台相关的接口和代码 ; 业务层与其它高层业务模块的交互是以 API 接口方式进行 ;
UI 部分与业务部分完全分离, 采用注册回调的方式进行刷屏 UI 处理, 由业务层提 取依赖平台和其它高层业务模块的适配接口。
各个高层业务模块之间的交互包括 : a) 模块启动、 停止、 暂停和恢复 ; b) 模块之间 的依赖关系 ; c) 对外部事件的响应。
UI 层与其它高层业务模块是互相依赖, 交互方式中排除类消息的方式。
各个高层业务模块在实现分层过程中, 将 UI 层、 业务层、 适配层实现分别存放在 不同的文件中 ; 同时将业务层单独编译成 LIB 库形式发布 ; 在代码实现上避免子模块之间、 模块之间以共享内存、 全局、 消息方式的藕合。
本方法采用结构化程序设计基本原则, 少量借签面向对象设计基础对高层业务软 件部分进行架构设计, 适用于大唐 ARENA 平台等移动通信终端高层业务软件。高层业务软 件采用本分层设计后, 其进行跨平台移植、 UI 更改等只需要修改少量适配层代码即可完成 新的项目开发, 较大的提高了软件的可移植性、 可扩展性。 【附图说明】
图 1 是现有技术中高层业务软件实现结构图 ; 图 2 是 UI 层与业务层藕合方式示意图 ; 图 3A 是本方法的整体架构示意图 ; 图 3B 是本方法的业务层依赖关系示意图 ; 图 3C 是本方法的各层接口示意图。【具体实施方式】
下面结合附图和具体实施方式对本发明作进一步说明。
一种基于 ARENA 平台高层业务软件分层架构设计方法, ( 如图 3A 所示 ) 根据分层 设计思想, 把高层业务模块统一分解为 UI、 业务层、 适配层 (Porting layer)。其中 UI 层主 要完成人机交互, 同时需要向业务层注册 UI 刷屏回调接口 ; 业务层主要完成本模块业务需 求, 其功能实现接口需要 UI 层及适配层完成, 从而完全脱离 UI 与平台的依赖性。所以业务 层需要提炼 UI 通知及平台相关接口, 这些都要在移植过程中由 UI 及平台实现。同时业务 层向其它模块提供必要的功能性接口。
为了减少业务层部分与其它子模块的藕合度, 业务层中实现不能包括与平台相关 的接口、 代码, 同时其与其它模块的交互以接口方式进行, 避免使用消息方式。
为了减少模块内部之间的藕合度, 减少其对 UI 及平台的依赖性, UI 部分与业务 部分完全分离, 采用注册回调的方式进行刷屏 UI 处理, 业务层提取依赖平台、 其它模块的 Porting( 适配 ) 接口 ( 如图 2 所示 )。
模块之间的交互主要是模块启动、 停止、 暂停、 恢复 ; 模块之间的依赖关系 ; 对外 部事件的响应。 业务层、 UI 层与外部模块可互相依赖, 但不能采用类消息的方式进行交互。
如图 3C 所示, 平台层需要向业务层提供适配接口, 同时业务层向 UI 及外部模块提 供调用 API, UI 层需要向业务层提供适配接口, 同时向其它模块提供接口。
模块在实现分层过程中, 将 UI 层、 业务层、 Porting Layer 实现分别存放在不同的文件中 ; 同时将业务层单独编译成 LIB 库形式发布。 在代码实现上避免子模块之间、 模块之 间以共享内存、 全局、 消息方式的藕合。在头文件组织方面采用如下方式 :
按照模块的功能内聚划分, 如模块 XXX 分为几个比较独立并具有一定内聚性的功 能实体 F1, F2, F3, 则头文件可定义为以下几个 :
xxx_pub.h——定义所有与外部模块公共 (module-global) 的类型、 常量和宏, 声 明所有与外部模块公共 (module-global) 的变量和函数原型。
xxx_f1.h——定义或声明所有与功能实体 F1 相关的类型、 宏、 变量、 函数原型以及 任务原型
xxx_f2.h——定义或声明所有与功能实体 F2 相关的类型、 宏、 变量、 函数原型以及 任务原型
xxxx_f3.h——定义或声明所有与功能实体 F3 相关的类型、 宏、 变量、 函数原型以 及任务原型
一般一个模块可以依据模块内部是否有几个比较独立的功能实体来决定选定一 种方式划分头文件。 如果头文件非常庞大则允许同时使用上面两种划分原则划分头文件。