ArticleDirectory
- Version Policy
- Variability management
- Model-driven
- Use Cases
Many products will encounter customization problems, that is, the configuration and customization work for some customers on top of general products, that is, handling 721 problems (to briefly describe such problems, we simply use 721 terms, 7 is a general function, 2 is a variable function, and 3 is a personality function. Here 721 only shows the approximate proportion of commonality and personality in the digital distribution, in reality, it is not completely allocated according to the proportion of 721), indicating the main content of the product line, which has been described many times in my previous blog. This article focuses on howOpenexpressappThis kind of object-oriented framework is customized.
Version Policy
- Problems caused by previous custom branch version policies
In the past, when we made the customer, we may specially create a customer group and createCodeBranch, and then make changes. Personal things are stored in their respective branches, and common problems are separately merged into the trunk after development, this can bring about a benefit that the custom task can be independent of the main version and can be freely changed.
However, this will cause the merge version problem in the future:
- If there are many Branch functions, we used to use the first phase of tasks for merging, which is boundDuplication of work
- Sometimes, during the merge process, there may be a gap between the customer and the main version.Design conflicts
- Because we do not explicitly adopt variable management, but use the branch version method to manage the customer work, the increase in the number of customers will inevitably bring aboutManagement complexity
I think this is why the product line engineering method has a set of arguments about code,Product Line Engineering considers that all functions (including 721) of the product can be passed through a setSource codeLibrary AcquisitionAnd then achieve custom release through means such as variability management.
- Product Line Version Policy of openexpressapp
Openexpressapp is based on the product line engineering method. I drew a picture to illustrate the overall version strategy for the customer work in the later stage of the project, as shown in:
- There is only one major version. All functions of this product are managed by the same code library, including general functions, variable functions, and personalized functions, these functions process variability through class inheritance, dynamic model configuration, static code configuration, and other methods.
- The general functions and variable functions are completed by the Field Engineering and will be the core assets of the product line. The individual functions are completed by the Application Engineering.
- The branch version only takes place on a temporary basis. For example, if you need to present the version to the customer immediately and fix some bugs in a short time and try again, you can temporarily create a branch. It must be clear that this branch must be of the discard type and has a short-term presence.
- As the number of customers increases, the features in 721 will bring about function migration, that is, the previous characteristics may change to variability or commonality. In the past, the variability may change to commonality, A common feature may also become a mutable feature, which requires us to rebuild the feature at any time during product development.
Variability management
- How to handle Variability
InSoftware product line engineering methods-four main methods and principlesWe have introduced the variability management in the product line. In terms of technical architecture, there are three basic ways to process variability:
The rectangle frame represents the entire software, the triangle rectangle represents the component, and the circle represents the interface. Next, I will briefly introduce these three methods. Later, we will map some of the commonly used technologies to these three methods.
Only one component is implemented, but the component provides various interface methods to change its behavior, such as the configuration file, runtime parameters, or component source code patching method.
A component has multiple implementations, and each component complies with the component interface specifications. Multiple implementations can be provided in the domain project, and then one of them can be selected in the application project, or one of the components can be developed in accordance with the component specifications in the Application Project
Expansion requires the architecture to provide some extension points that allow new components to be added. The added components can be within a specific product or framework. These components are not the functions provided by the system, but are inserted from the outside into the system. Therefore, the system architecture must consider the specific extensions.
- Specific variability Mechanism
- Inheritance (adaptation)
Subclass modifies some default behaviors by inheriting the parent class. Only one implementation component is available.
- Patch (adaptation)
If you can obtain the source code of the component, you can use the patch method to effectively change part of the behavior without the need to maintain the entire component. In this way, the patch is maintained by the Application Project, and the component itself is maintained by the domain project.
- Configuration during compilation (adaptation)
The compiler provides a mechanism to change components during compilation. preprocessing and macros belong to this method. Makefiles can compile multiple components with different variants, or select a correct component.
- Runtime configuration (adaptation)
Multiple implementations are available in the component, and the component behavior can be dynamically changed through configuration during runtime.
- Code Generation (replacement)
Code Generation: The Code required by some components or the entire product is generated by reading some high-level models, scripts, and other conventions.
- Component Replacement)
By default, multiple components are implemented. These components can be implemented by domain engineering or application engineering, you can replace the entire component to change the implementation method of specific functions as long as it complies with certain interface conventions.
- Plug-ins (extensions)
Many plug-ins provide extension points for the system. The plug-in can add additional functions as long as it finds the extension points.
Model-driven
When there is no model-driven, more customization work may be done through code, configuration, and scripts. If you consider the model, you need to model the variability, the following is a variant metadatabase in the product line project:
If we also support the class model, the class model and the variability model can be matched as follows:
If we use the code generation technology, after using these models, we can further generate only required code for a specific product.
Use Cases
For example, the comprehensive unit price accumulation of a list can form a typical list database, and through the accumulation process can also form a set of price databases. For this requirement, from the perspective of user requirements and sales, we can use the support for the Gallery library as an optional attachment for the product. The ideal solution we can achieve is to provide one or more DLL. When the system is tested in the directory, the gallery function is added, which requires us to apply the above variability technology to solve the problem.
- Uses adaptation and replacement methods to add gallery-related attributes by inheriting from the comprehensive list class library.
- Add related gallery modules
- Deploy gallery-related content toProgramIn order to achieve the module configuration through the simple copy function.
- Of course, there are more methods that need to be deepened in practical work ......
Recommended: online e-books you may need
My weibo: http://weibo.com/openexpressapp
Agile individual Sina apron:Http://q.t.sina.com.cn/135484
welcome to reprint, reprint Please note: Reprinted from Zhou jingen [http://zhoujg.cnblogs.com/]