Software architecture style of software exam system architect series knowledge points (5)

Continuing from the previous article: Examination of System Architecture Designer Series Knowledge Points: Software Architecture Style (4)

This Eleven is destined to be an Eleven that cannot be relaxed and remains "tight". Since I have signed up for the National Computer Technology and Software Professional and Technical Qualification (Level) Examination, the exam will be held on November 4th, so the 8-day holiday must not be wasted and must be utilized well. Now refine and record each core knowledge point one by one.

Chapter:

Chapter 7. Basic knowledge of system architecture design

        Section 3. Software architectural style

2. Segmentation

(5) Independent component architecture style

The independent component architecture style mainly emphasizes that each component in the system is a relatively independent individual and does not communicate directly between them to reduce coupling and improve flexibility.

The independent component architecture style mainly includes :

Process communication architectural style and event system architectural style .

  • Process communication architectural style

In the process communication architecture style, components are independent processes and connectors are message passing . The characteristic of this style is that the components are usually named processes , and the message delivery method can be point-to-point , asynchronous or synchronous, and remote procedure calls .

  • Event system architectural style

Event system style The idea of ​​the event-based implicit calling style is that the component does not directly call a procedure, but triggers or broadcasts one or more events . Processes in other components in the system are registered in one or more events. When an event is triggered, the system automatically calls all processes registered in this event . In this way, the triggering of an event causes the call of a procedure in another module.

Architecturally speaking, the components of this style are modules , which can be either a process or a collection of events. Procedures can be called in a general way, or you can register some procedures in system events, and when these events occur, the procedures are called.

The main feature of the event-based implicit calling style is that the triggerer of the event does not know which components will be affected by these events , which makes it impossible to assume the processing order of the components, or even know which procedures are called. Therefore, many implicit calls The system also includes explicit calls as a complementary form of component interaction.

There are many application systems that support event-based implicit calls. For example, it is used to integrate various tools in the programming environment; to ensure data consistency constraints in the database management system; to manage data in the user interface system; and to support syntax checking in the editor. For example, in a certain system, the editor and variable monitor can register breakpoint events of the corresponding Debugger. When the Debugger stops at a breakpoint, it declares the event and the system automatically calls the handler. For example, the editor can scroll (return) to the breakpoint, and the variable monitor refreshes the variable value . The Debugger itself only declares events and does not care about which processes will be started or what processing these processes do.

Guess you like

Origin blog.csdn.net/phmatthaus/article/details/133513749