OEA中的AutoUI重构(2)- 评审会议前的总体设计

简介:

 本次重构主要是针对OEA框架中的AutoUI部分。这个任务在月初时计划在一个月内完成,包括问题分析、设计新的结构、编写设计文档、开展设计评审、代码实现、提交评审。本系列文章用于记录整个过程中的关键项。

    本篇文章主要记录了在设计评审会议前我所做的工作,包括:

  1. 历史状况分析
  2. 重构目标
  3. 逻辑设计方案
  4. 结构关系图

 

历史状况分析


    由于是重构,所以我们需要弄清楚当前的问题是哪些,历史代码的结构,为什么这样的结构会造成这些问题。历史代码的结构原来已经写过相关的文章:《OpenExpressApp 框架结构(1)》、《OpenExpressApp 框架结构(2)》。这里主要说一下现有的问题。

    为了收集更全面的问题列表,我和每一个开发人员、测试人员、需求人员进行了沟通。以下以基于OEA框架的GIX4应用程序为例子,来说明现有的问题:

    从用户角度看

用户觉得,当前生成的界面不好看,虽然可以换多套皮肤,但是布局太死,不能更换一些新的布局。

image

另外,用户提出目前的界面中,有一些弹出窗体的界面与整个应用的风格不统一。

    从开发人员的角度看

由于我本身也是一名开发人员,平时也记录了一些小问题,觉得AutoUI目前存在的问题主要有这些:

image

    理想中的AutoUI:

目前的元数据包含太多信息,没有进行分离,界面生成时需要的元模型应该是纯净的。

元数据应该是可以持久化的,这样不但可以在持久层对元数据进行修改,而且更好地支持了产品的客户化。

 

重构目标


    以上的问题中,并不是所有的都需要一次性完成,经过过滤、排序,得到以下的目标列表:

image

    质量属性中,优先级自上而下慢慢变低。

    因为我们用的是OEA框架中的AutoUI模块,该模块的目标就是自动生成界面,以简化界面的开发、统一界面的模式、重用界面开发模式,所以可重性自然是最重要的。需要完成系统90%以上的界面生成。在默认情况下,能够生成一个完整的应用程序。这些需要生成的可重用构件包括:
大粒度:应用程序界面框架、布局模块、数据列表、树型数据列表、实体编辑面板、导航栏、工具栏等。
小粒度:按钮、属性编辑器等。

    其次,在保证可重用性的前提下,就需要保证系统的可扩展性,这也是本次重构需要重点考虑的。原来的系统中,应用程序的生成已经完全实现,但是预留的扩展点并不多,导致扩展起来并不容易。现在,需要在设计时,估计未来的应用模式并留下更多的扩展点,这些扩展点可能包括:布局模式的扩展、界面生成算法的扩展、生成后的控件的局部扩展等。当然了,更多的扩展点很可能需要在具体代码开发时才知道,到时再设计扩展点并将其文档化下来。

    其它的比较简单,不再一一具体解释。

 

逻辑设计方案


    整个逻辑设计过程,主要按照以下的几个过程展开:

image

    约束是指重构时需要考虑的一些限制条件。由于目前OEA已经在产品GIX4上应用,而GIX4中代码量并不小,所以这里主要的一个约束是:重构后的AutoUI模块的外部接口需要兼容原有系统。(当然,这个约束并不是100%严格,但是可以作为一个约束条件,在设计时酌情考虑。)

    然后就是细化整个重构的目标:

image

    需求细化后,其实就开始系统的类库结构设计了。主要还是画一些类图、包图。同时,记录一些设计的要点、权衡点。在整个设计完成后,再次回顾了质量属性。这些过程过于细节,在此就不细讲了。

 

两张重要的草稿


image

    上图是构思中的重构后的AutoUI的结构图。

image

    上图是如果扩展控件生成方案。本来是作为OEA中开发人员使用XAML编写控件的支持,不过后来决定这次暂时不实现。(主要是考虑到升级困难和模型驱动的思想有冲突。)

 

最终设计的类的结构图


    先是AutoUI涉及到的逻辑组件的依赖图

image 

 

重构后整个设计的逻辑层图

image

 

以下是各个包内的详细设计

ViewEntity 与 Entity 分离:

image

图中显示的是三种可能的视图实体和领域实体的关系。使用下图中的关系来支持多样的视图模型:

image 

 

 

逻辑控件/控件编辑器

image

 

 

布局模式

image

 

 

界面元数据:

单个界面组成单元的元数据

image 

整个界面的元数据

image

这张图是本次设计中最重要的地方,它组织了多个单个块的元数据(UIBlockDefinition)来形成界面的聚合元数据(AggregateBlocks)。每个UIBlock都可以进行布局样式的应用、整个AggregateBlock也可以应用布局样式。

该设计并不是单向依赖的,最重要的几个类紧耦合在了一起。由于我觉得这样的核心元数据再进行抽象会不易于理解,所以没有再为其分离接口进行解耦。

 

 

控件工厂

image

 

 

逻辑视图控制器

image

 

 

生成界面的流程控制器

ViewControlGenerator

image

RegionContainers

image

LayoutManager

image 

AutoUI 流程控制器

image

客户程序使用方法

image

AutoUI流程概要

image

 

小结 


    这些设计还都只是个人的构想,还需要经过接下来的设计评审后才能正式进入实现阶段。总的来说,自己觉得界面元数据那块的设计还是有点难于理解。不过时间比较紧,先就这样了。等待评审结果……

 

PS:

从开始收集问题到画出所有的设计,花了我几天的时间。一些问题还是在梦中想明白的,哈哈。不过发现最近自己效率有点低,有时候想问题专注不下来,想着想着就又乱了。

另外,这篇文章发得有点晚,其实评审会议已经完成了,下一篇会总结评审后的设计。

目录
相关文章
|
5月前
|
监控 项目管理
PMBOK泛读(第四章) - 项目整合管理(二)
PMBOK泛读(第四章) - 项目整合管理(二)
33 0
|
5月前
|
敏捷开发 监控 安全
PMBOK泛读(第四章) - 项目整合管理(一)
PMBOK泛读(第四章) - 项目整合管理
35 0
|
5月前
|
存储 安全 数据管理
PMBOK泛读(第十三章) - 项目相关方管理
PMBOK泛读(第十三章) - 项目相关方管理
55 0
|
5月前
|
存储 安全 数据管理
PMBOK泛读(第十章) - 项目沟通管理
PMBOK泛读(第十章) - 项目沟通管理
54 0
|
5月前
|
监控 数据挖掘 项目管理
PMBOK泛读(第四章) - 项目整合管理(三)
PMBOK泛读(第四章) - 项目整合管理(三)
27 0
|
5月前
|
数据挖掘 项目管理 索引
PMBOK泛读(第四章) - 项目整合管理(四)
PMBOK泛读(第四章) - 项目整合管理(四)
31 0
|
5月前
|
数据可视化 数据挖掘 测试技术
PMBOK泛读(第五章) - 项目范围管理(一)
PMBOK泛读(第五章) - 项目范围管理
52 0
|
5月前
|
自然语言处理 数据挖掘 项目管理
PMBOK泛读(第五章) - 项目范围管理(二)
PMBOK泛读(第五章) - 项目范围管理(二)
38 0
|
5月前
|
数据挖掘 项目管理 数据库
PMBOK泛读(第八章) - 项目质量管理
PMBOK泛读(第八章) - 项目质量管理
35 0
|
5月前
|
监控 算法 数据挖掘
PMBOK泛读(第六章) - 项目进度管理(二)
PMBOK泛读(第六章) - 项目进度管理(二)
35 0

热门文章

最新文章