Autoui reconstruction in OEA (2)-overall design before the review meeting

I have written an article about the reconstruction of the command module: OEA autoui reconstruction (1)-Automatic Command generation. Command auto-generated refactoring is a "Forward war" of This refactoring. We try to use OO to optimize the original process-based interface auto-generated process to support better scalability. The Automatic Generation of commands is relatively independent, so the reconstruction is performed independently. At present, the reconstruction has been completed and the effect is good: it is compatible with the original system, and more necessary extension points are inserted at the same time.

This refactoring mainly targets the autoui part of the OEA framework. This task is planned to be completed within one month at the beginning of the month, including problem analysis, designing new structures, writing design documents, conducting design reviews,CodeImplementation and submission for review. This seriesArticleUsed to record key items throughout the process.

This article mainly records what I did before the design review meeting, including:

1. Historical Status Analysis
2. Reconstruction goal
3. Logic Design Scheme
4. Structure Diagram

 

Historical Status Analysis

Because it is refactoring, we need to find out what the current problem is, the structure of the historical code, and why such a structure will cause these problems. The history code structure has already been written in related articles: openexpressapp framework structure (1) and openexpressapp framework structure (2). Here we will focus on the existing problems.

To collect a more comprehensive list of problems, I communicated with every developer, tester, and requirement engineer. The following is a gix4 application based on the OEA framework:ProgramFor example, to illustrate the existing problems:

From the user's perspective:

The user thinks that the current interface is not easy to see. Although multiple skin sets can be changed, the layout is too dead to replace some new la S.

In addition, the user proposes that some pop-up forms are different from the style of the entire application.

From the developer's perspective:

As I am also a developer, I have recorded some minor issues. I think the current problems of autoui are mainly as follows:

Ideal autoui:

Currently, metadata contains too much information and is not separated. The meta model required for interface generation should be pure.

Metadata should be persistent. In this way, not only metadata can be modified at the persistence layer, but also better support the customization of products.

 

Reconstruction goal

Not all of the above problems need to be completed at one time. After filtering and sorting, the following target list is obtained:

In quality attributes, the priority gradually decreases from top to bottom.

Because we use the autoui module in the OEA framework, the goal of this module is to automatically generate interfaces to simplify interface development, unify interface modes, and reuse interface development modes, so reusability is naturally the most important. You must generate more than 90% of the system interfaces. By default, a complete application can be generated. The reusable components to be generated include:
Large granularity: application interface framework, layout module, data list, tree data list, entity editing panel, navigation bar, toolbar, etc.
Small granularity: buttons, attribute editors, etc.

Secondly, to ensure reusability, we need to ensure the scalability of the system, which is also a key consideration for this restructuring. In the original system, application generation has been fully implemented, but there are not many reserved extension points, which makes expansion difficult. Now, we need to estimate the future application mode and leave more extension points during design. These extension points may include: Layout mode extension and interface generation.AlgorithmAnd the local extension of the generated control. Of course, more extensions may need to be known during code development. Then, design the extension points and document them.

The others are relatively simple and will not be explained in detail one by one.

 

Logic Design Scheme

The entire logical design process mainly follows the following steps:

Constraints are some constraints that need to be considered during refactoring. Currently, OEA has been applied to the product gix4, but the amount of code in gix4 is not small. Therefore, the main constraint here is that the external interface of the reconstructed autoui module must be compatible with the original system. (Of course, this constraint is not 100% strict, but can be considered as a constraint during design as appropriate .)

Then the goal of the entire reconstruction is refined:

After the requirements are refined, the system's class library structure is actually designed. It mainly draws some class charts and package diagrams. At the same time, record some design points and trade-offs. After the design, the quality attributes were reviewed again. These processes are too detailed and will not be detailed here.

 

Two important drafts

Is the structure of the reconstructed autoui in the conception.

If it is an extension control generation scheme. It was originally used as a developer in OEA to write controls using XAML, but later it was decided not to implement it this time. (The main reason is that the upgrade difficulty conflicts with the model-driven idea .)

 

Structure of the final design class

First, autoui involvesLogical component dependency Diagram:

 

 

After reconstruction, the entire designLogic layer Diagram:

 

The detailed design in each package is as follows:

Separated viewentity and entity:

The figure shows the relationships between three possible view entities and domain entities. The relationships in use support various view models:

 

 

 

Logical Control/control Editor

 

 

Layout mode

 

 

Interface metadata:

Metadata of a single interface component

 

Metadata of the entire Interface

This figure is in this design.The most important thingIt organizes the metadata of multiple individual blocks (uiblockdefinition) to form aggresponblocks ). Each uiblock can apply layout styles, and the entire aggresponblock can also apply layout styles.

This design is not one-way dependency, and the most important classes are tightly coupled. I don't think it is easy to abstract such core metadata, so I didn't decouple the separation interface.

 

 

Control Factory

 

 

Logical View Controller

 

 

Process controller for generating the interface

Viewcontrolgenerator

Regioncontainers

Layoutmanager

 

Autoui process Controller

Customer program usage

Autoui Process Overview

 

Summary 

These designs are only personal ideas, and they need to be reviewed before they can officially enter the implementation stage. In general, I think the design of the interface metadata block is still a bit difficult to understand. However, the time is tight. Waiting for review results ......

 

PS:

It took me a few days to start collecting problems and drawing all the designs. Some questions are still to be understood in the dream, haha. However, I found that my efficiency is a little low recently. Sometimes I can't focus on my problems, but I am confused when I think about it.

In addition, this article was a little late. In fact, the review meeting has been completed. The next article will summarize the design after the review.