zoukankan      html  css  js  c++  java
  • OEA中的AutoUI重构(2) 评审会议前的总体设计

        之前已经写了一篇关于其中Command模块的重构:《OEA中AutoUI重构(1) - Command自动生成》。Command自动生成的重构作为本次重构的一个“前锋战”,尝试用OO的方式把原来的过程式的界面自动生成流程进行优化,以支持更好的可扩展性。Command自动生成较为独立,所以就单独先进行了重构,目前重构已经完成,效果较好:和原有系统完成兼容,同时插入了更多必需的扩展点。

        本次重构主要是针对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:

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

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

  • 相关阅读:
    Hello,Cnblogs,I'm Kxia
    运维
    CRT 操作数据库乱码
    STM32 各引脚功能
    遍历结果集
    更换税控服务器主板后,重新申请注册码
    修改远程桌面端口号
    nginx 设置开机启动
    windows 日志清理批处理 设置到计划任务就可以每天清理日志了
    按关键字查找文件
  • 原文地址:https://www.cnblogs.com/zgynhqf/p/1909311.html
Copyright © 2011-2022 走看看