In pursuit of long-term development, software enterprises usually adopt product line model and system evolution strategy, which is essentially to build product line with architecture technology, and on this basis, continue to evolve with reuse technology, and constantly launch new products to meet the market demand for product upgrading.
1 Reuse and product line
A software product line is a set of software-intensive systems that share a common, manageable set of features, meet the specific needs of a particular market or task, and are developed in a prescribed way with common core assets. That is to manage, reuse and integrate new systems around the core asset base.
The core asset library includes software architecture and its clipable elements, and more broadly, design scenarios and their documentation, user manuals, project management histories (such as budgets and schedules), software test plans, and test cases. Reusing core assets (especially software architectures), product lines will dramatically improve productivity, reduce production costs, and reduce time-to-market.
Creating a successful product line depends on the coordination of software engineering, technical management, and organizational management, and only software architecture is discussed here.
The “software” product line, based on commonality between products, represents an innovative and evolving concept in software engineering.
The essence of the software product line is to reuse assets in a disciplined, strategic way when producing a family of products. There is a wide range of reusable assets, including the following.
- Requirements: Many of the requirements are the same or partially the same as the systems developed earlier, such as online banking and counter banking transactions.
- Architecture design: the original system spent a lot of time and energy in the architecture design, the system successfully verified the rationality of the architecture, if the new product can reuse the existing architecture, it will achieve good benefits.
- Elements: Element reuse is more than simple code reuse. It is about capturing and reusing what works in your design and avoiding (not repeating) design failures.
- Modeling and analysis: all kinds of analysis methods (such as performance analysis) and all kinds of solution models (such as fault tolerance solution, load balancing solution) can be reused in products.
- Testing: the use of product lines can accumulate a large number of testing resources, that is, when considering testing, not the project as a unit, but the product line as a unit, so that the whole test environment can be reused, such as test cases, test data, test tools, and even test plans, processes, communication channels can be reused.
- Project planning: Use experience to forecast project costs, budgets, schedules, and development team arrangements, i.e. not having to create a work breakdown structure every time.
- Processes, methods, and Tools: With the product line banner, an enterprise can establish product-line level workflows, specifications, standards, methods, and tool environments for reuse across all products in the product line. Coding standards are an example.
- Personnel: Personnel trained by the product line, suitable for the development of various products throughout the series.
- Sample system: Use deployed (production) products as high quality demonstration and engineering design prototypes.
- Defect elimination: The accumulated defect elimination activities during product line development can benefit the new system, especially the one-time solution of performance, reliability and other problems in the whole product family, which can achieve high returns. At the same time, it also makes developers and customers have a “bottom” in mind.
2 Architecture based on product line
- Software product line architecture is a general architecture designed for a series of products. Based on this, modules shared by a series of products are realized in advance for direct reuse. The architecture is implemented as a framework for custom use. This is often referred to as a “platform”.
Product line architectures are different from individual product architectures in the following three aspects: (1) Product line architectures must account for a series of explicitly licensed variations; (2) The product line architecture must be documented; (3) Product line architectures must provide a “product Creator’s guide” (development guide) describing the architecture’s instantiation process.
The software architecture of the product line should address the unchanging aspects of the product line (it is because of the unchanging aspects that the product line comes into being), while identifying permitted changes and providing mechanisms to implement them. In general, three aspects should be considered. (1) Identifying change points: Identifying change is an ongoing activity that can be identified at any point in the development process. (2) Support point of change: Support for change can take many forms, as shown below. Include or omit elements: such as conditional compilation. Contains different numbers of replication elements: for example, by adding more servers to produce high-volume variants. The selection of versions of elements that have the same interface but different behavior or quality characteristics: such as the use of static libraries and dynamically linked libraries. In an object-oriented system, change is achieved by specialization or generalization of a particular class. Change is implemented through parameter configuration. (3) Evaluate the suitability of the product line architecture. Assessment content: The assessment must be focused on the point of change to ensure that it provides sufficient flexibility to cover the expected scope of the product line; They enable rapid building of products. Time for evaluation: Instances or variations of the architecture used to build one or more products in the product line should be evaluated. The results of a product architecture evaluation often provide useful feedback to drive architecture improvements. When a proposed new product is not within the scope of the original product line, the product line architecture can be re-evaluated to see how it accommodates the new product or whether a new product line is necessary.
3. Development model of product line
There are two models to develop (determine) product lines: (1) “forward-looking” product line: product line design based on experience in the application field, understanding of market and technology development trends and business judgment, which reflects the strategic decision of the enterprise. The product line approach is usually top-down. (2) the “reactive” model: The enterprise builds its product family based on previous products and expands its architecture and design scheme as new products are developed. Its core asset base is built based on “proven” elements that are shared rather than “pre-planned” elements that are shared. A product line approach is usually taken bottom-up.
Once a product line is identified, it enters its evolution phase, which is the continuous development process of the product line.
4 Domain-specific software architecture
The essence of architecture lies in its abstraction. It includes two aspects of abstraction: business abstraction and technical abstraction. Business abstraction is oriented to specific application domains.
Domain Specific Software Architecture (DSSA) can be seen as a method (or theory) for developing product lines, whose goal is to support the generation of multiple applications in a Specific Domain.
The necessary characteristics of DSSA are: (1) a strictly defined problem domain or solution domain; (2) universality, so that it can be used for the development of a specific application in the field; (3) The appropriate degree of abstraction for the whole field; (4) Have the fixed and typical reusable elements in the development process of the field.
There are two ways to understand the meaning of domain in DSSA from the perspective of functional coverage: (1) vertical domain. Defines a specific family of systems and derives a common software architecture that can be used as a viable solution for systems in that domain. (2) Horizontal domain. Defines the common parts of functional areas in multiple systems and multiple system families, covering specific parts of the functions of multiple systems (families) at the subsystem level.
The phases of DSSA activity are as follows. (1) Domain analysis: The main goal is to obtain domain model. That is, by analyzing the requirements of the systems in the domain (domain requirements), determine which requirements are widely shared by the systems in the domain, so as to establish the domain model. (2) Domain design: The goal of this stage is to obtain DSSA, which is a high-level design that can adapt to the needs of multiple systems in the domain. Because domain requirements in a domain model are somewhat variable, DSSA needs to be correspondingly variable, and it can do so by representing multiple, alternative solutions, and so on. (3) Domain realization: The main goal is to develop and organize reusable information based on domain model and DSSA. This reuse information can be extracted from existing systems or through new developments. This phase can be viewed as the implementation phase of the reuse infrastructure. In the above work, obtaining domain model is the foundation and key. Domain modeling focuses on analyzing the problem domain itself, discovering important business domain concepts, and establishing relationships between business domain concepts. Generally, domain models can be represented by UML class diagrams and state diagrams.
For projects of moderate complexity, about 50 to 100 classes should be found in the domain model of the system.
The main functions of domain model are as follows: (1) Domain model defines domain knowledge and domain vocabulary for requirements, which has a better overall view than single project requirements; (2) Software interface design is often closely related to domain model; (3) The rationality of domain model will seriously affect the scalability of software system; (4) Under the guidance of hierarchical architecture, the domain model becomes the skeleton of the business layer after refinement; (5) Domain model is also the basis of its data model; (6) The domain model is the basis for team communication, because it specifies an important domain vocabulary and the definitions of these vocabularies are strict and agreed upon.
5 Architecture and system evolution
Although the architecture provides a certain degree of freedom for system changes, large changes in the system inevitably lead to changes in the architecture. Architecture (system) evolution is controlled change directed in a given direction. Architecture (systems) evolution can lead to product lines, and architecture (systems) can, in turn, evolve within planned product lines.
The architecture (system) evolution process consists of seven steps, as shown in Figure 1. (1) Demand change classification. First, the changes in user requirements must be categorized so that they correspond to existing artifacts. Changes that cannot be found should also be marked, and in subsequent work, new components will be created to meet the changing requirements of this part. (2) Formulate the framework evolution plan. Before changing the original structure, the development organization must develop a thorough architectural evolution plan as a guide for subsequent evolutionary development efforts. (3) Modify, add or delete components. Based on the evolution plan, developers can decide whether to modify or delete existing artifacts and add new ones based on the classification of requirements changes obtained in step (1). Finally, the modified and added artifacts are functional tested. (4) Interaction of updated components. As artifacts are added, deleted, and modified, the flow of control between artifacts must be updated. (5) Component assembly and testing. Through assembly support tools to assemble the implementation of these components, complete the connection and synthesis of the whole software system, forming a new architecture. Then, the overall function and performance of the assembled system are tested. (6) Technical review. Confirm the above steps and conduct technical review. Review whether the assembled architecture reflects changes in requirements and meets user requirements. If not, you need to iterate between steps (2) and (6). (7) Generate an evolved architecture. All changes made on the original system must be integrated into the original architecture to complete an evolutionary process.
