- Software Architecture Reuse
The software product line is a group of industry-intensive systems, which are stipulated to be integrated and developed with common core assets.
Opportunistic and systematic multiplexing.
Opportunity to reuse: Temporary discovery of ingestible assets can be reused immediately.
System reuse: Plan what needs to be reused before development.
Three stages of reuse:
Obtain reused assets, manage these assets, select reused parts from assets according to requirements, and develop a system that meets the requirements.
- Domain Specific Software Architecture
DSSA（Domain specific Software Architectrue）
A collection of standard software that is dedicated to a specific type of task (domain) and can be effectively used throughout the domain.
It is a development basis that supports a set of application reference models, reference requirements , and reference architectures in a specific problem domain , and the target supports the generation of multiple applications in a specific domain.
Vertical Domain: A complete architecture common to a specific domain.
Horizontal Fields: Widgets in the same section between different fields. (such as payment systems for education and shopping)
DSSA has three basic activities
- domain analysis
Get the domain model (requirements). Build a domain model.
- domain design
The purpose is to obtain DSSA (Domain-Specific Software Architecture ), which represents the solution to be solved in the domain model. It is not a single system representation, but a high-level design that can adapt to the requirements of multiple systems in the domain.
- domain realization
The main objectives of the phase are to develop and organize reusable information according to domain DSSA. These reusables may be extracted in the existing system, or they may be newly discovered.
Participating in DSSA has four roles: domain experts, domain analysts, domain design and domain implementation.
Domain experts: experienced users of the system, engineers with experience in system requirements analysis, design and implementation, and project management in the system.
Domain analysts: Experienced system analysts with knowledge background will act.
Domain Designer: Designer.
Domain implementers: Programmers.
The process of establishing a DSSA:
Define the scope of the domain: applications in the domain must meet a series of user needs.
Define domain-specific elements: domain dictionaries, etc.
Define constraints for domain-specific design and implementation requirements.
Define the domain model and schema.
Generate and collect reusable product units.
The above process is concurrent, recursive, iterative, and spiral.
Three-level model:
Domain development environment : Domain architects determine the core architecture and produce reference structures, reference requirements, architectures, domain models, and development tools.
Domain-specific application development environment : Engineers instantiate the core architecture according to the specific environment.
(The previous development environment is the general architecture in the field, and later in the application development environment, it is specially processed according to the actual environment)
Application execution environment : The operator directly operates the instantiated architecture.
- Architecture-Based Software Development
ABSD (Architecture base Software Design): business, quality and functional requirements (emphasis)
The approach is architecture-driven, emphasizing that architecture design is driven by a combination of business, quality, and functional requirements . It emphasizes the use of perspectives and views to describe software architecture , and use cases and scenarios to describe requirements.
Use cases are functional requirements, which are more abstract, and scenarios are instantiated scenarios.
Using the ABSD method, design activities can start from the determination of the overall functional framework of the project. (It means that the software design starts before the requirements acquisition and analysis are completed)
There are three bases for using the ABSD method:
- For the decomposition of functions, the existing module-based cohesive coupling technology is used.
- Achieve quality and business requirements by choosing an architectural style.
- Use of software templates.
The ABSD method is recursive, not a one-shot operation.
Architecture (architecture, architecture)
Architecture-based software development process, six processes.
Architecture Requirements, Architecture Design, Architecture Documentation, Architecture Review, Architecture Implementation, Architecture Evolution .
During the review, if yes, go normally, if no, then redesign.
Every time the architecture is re-evolved, the entire process needs to be re-walked.
- Architecture Requirements
After obtaining the requirements, create a class diagram in three steps, group the classes, and package the classes into components. (These three steps belong to the identification component)
- architecture design
Map the above identification components to components. Design the domain architecture.
- Architecture Documentation
Two types of document architecture specifications and quality design specifications for test architecture requirements are produced .
- Architecture Review
Reviews are attended by outsiders (people independent of the development organization, such as user representatives and domain experts).
If it is passed, it will be implemented normally, if it is not passed, it will be redesigned, and it will return to 2.
- Architecture implementation
Entities to display the schema. Realize the components, and assemble the components into a system.
- architecture evolution
Make changes to the architecture, add and delete components according to requirements, so that the architecture can be reused. (Generally, new requirements are put forward. At this time, evolution is required, whether to add components or delete components)
