Basic steps of product line Architecture Design

I. Organization of product line requirements
Many industries have constructed a series of products with similar functions, but each product contains some unique features,
It is called a product line. Assume that a software system is being built, and each product has shared functions.
You need to share data or communicate with other parts. In this case, you can use the following method to organize the requirements:
Develop the foreground document of the product series to describe the common working methods and shared features of the product.
To better understand the shared usage model, we should also design a set of use cases, first, how the user runs together
User-created interaction between different applications.
Develop public software requirements that define special requirements for shared functions, such as public guis and communication protocols.
Provides product development prospects, specification descriptions, and use case models that define special features for each product in the series.
Shows the results of the organization.
Vision docunment is used to define problems and solutions at a higher abstraction level.
The term used to describe the application, including the target market, system users, and application features. Foreground document is a valid requirement
And may be the most important document. Because a short or even incomplete document is helpful for Project
Members work towards the same goal. The team has a common goal and script, and may have a common mentality. If the group
The team's goals are unknown and conflict with each other, and chaos will soon emerge.
Foreground documents are used to obtain user requirements, system features, and other project requirements. In this way, the scope of the foreground document spans the needs
The upper two layers of the pyramid define problems and solutions at a higher abstraction level.
Because the product may change in many ways, you need to obtain the change points as much as possible in the requirement analysis.
Changes include features, platforms, user interfaces, quality attributes, and target markets.
Ii. determine the scope
Determine the scope to define which systems belong to this product line and which do not belong to this product line. This range is also
It represents the Optimal Prediction of the products that the Organization will develop for the foreseeable future. If the range is too small
If the ROI is not good, the workload for developing a single product using the core asset library is too large.
The scope of determination is not to discover commonalities, but to discover the commonalities that can be fully utilized, which can greatly reduce the system
The cost of unified construction. In addition, when determining the scope, we should not only consider similar products, but also choose different products online.
Common functional blocks may exist, which is also a concern.
In the core asset library, the software architecture is the top priority, and a product can be different in almost all product lines.
For a general architecture, the key to the design is that there is a set of clear rules in the architecture design that allow changes.
Changes are part of the architectural design responsibility. The architecture design must be clarified, what must be kept unchanged, and what is allowed
What changes have taken place and how to deal with such changes, which are often part of the important characteristics of the new system.
Of course, the architecture itself is a constant part.
3. Determine change points
Because the product may change in many ways, at the beginning of the product line design, we must determine the requirements of the product line.
Obtain the change point in the analysis. These include features, platforms, user interfaces, quality attributes, and target markets. Second,
In the product line architecture design, we can also obtain other changes. Finally, in the product line implementation process
Changes may bring new inspiration. This is necessary because some decisions can only be determined after more information is obtained.
Iv. supported change points
There are many ways to support change points in architecture design, for example:
In our object-oriented design model, this change can be achieved through generalization and specialization. It features a series
Has the same interface but has different behaviors.
Build an extension point into the implementation of the element, that is, place it in a place where additional behaviors and functions can be added securely.
.
The construction parameters can be introduced through the element, subsystem, or subsystem set. The configuration may need to be used here.
File, you can use reflection when necessary.
For the architecture stored in the core asset library, you must write a document for it, focusing on expressing changes and application changes.
It should also describe the architecture instantiation process, that is, how to apply changes. The valid and
Invalid application instance to avoid application errors. The product line architecture must be evaluated to ensure that this architecture is effective
And Application Security.
V. organization principles of product line Architecture
Software Architecture is always considered a technical issue,. Why are there a lot of good technicians?
Team members, but the project still fails? There are many reasons for inquiry. In the past, many of them were particularly emphasized due
Why are the requirements of product lines organized? But how are these problems introduced and solved as software architects?
Therefore, we need to study the organizational principles and models of the product line architecture.
A good product line architecture should follow several core principles at the organizational and technical interaction level, including conception, foresight,
Rhythm, collaboration, and simplification.
1) Conception
Conceptual principles demonstrate how to draw a consistent, binding, and flexible future map to the beneficiaries of the Architecture
Image. As an architect, the key is to ensure that the proposed architecture is consistent with the company's business objectives.
In fact, it is not easy to achieve this.
2) foresight
The chief architect must have a keen insight into the future development trend, but such foresight is often at the same time as the current standard.
This requires a balance between the two, and this balance is very difficult to deal.
3) rhythm
The Rhythm principle ensures that software organizations can regularly choose between artifacts based on predictable speed, content, and quality. In the new
Sometimes, you must make a trade-off between Ying's performance and the specified release date to ensure the release date, but this may be different from the public
What should we do if our senior executives have different ideas?
4) Collaboration
When the chief architect designs the architecture, collaboration is important. We must ensure that the company and the surrounding areas work together.
The author, domain architect, and development team can understand the key ideas of the architecture,
5) simplified
The simplification principle requires clarification and minimization of architecture and creation. When the components developed by two groups overlap
You can consider specifying a shared component. How to simplify it is the most important concern of the Architecture engineer.
This architecture design is of little significance.
These five principles are called vrasp models (vision, rhythm, anticipation, partnering,
Simplification ). This model focuses on the organizational aspects of the framework design.
We once again stressed that the biggest obstacle to the success of the product line architecture is the organization rather than the technology. But I
You don't need to consider questions like senior managers, but you need to look at questions from the architect's perspective.
To find a suitable solution. Next, we will discuss this issue in detail from the perspective of organization.