What is software architecture view
So, what is a software architecture view? Philippe Kruchten wrote in his book "Introduction to the Rational Unified Process":
An architectural view is a simplified description of the system seen from a certain perspective or a certain point. The description covers a specific aspect of the system and omits entities that are not related to this aspect.
In other words, there are too many contents and decisions to be covered by the architecture, which exceeds the human brain's ability to "overcome in one go". Therefore, the "divide and conquer" method is used to design from different perspectives; Archiving provides convenience.
It is worth mentioning that most books emphasize that the multi-view method is the method of software architecture archiving, but it is not. The multi-view method is not only an archiving technology for architecture, but also a way of thinking that guides us in architecture design.
4 + 1 view method proposed by Philippe Kruchten
In 1995, Philippe Kruchten published a paper entitled "The 4 + 1 View Model of Architecture" in "IEEE Software", which caused great concern in the industry and was finally adopted by RUP. as shown in picture 2.
Figure 2 The 4 + 1 view method proposed by Philippe Kruchten
The different architectural views of the method carry different architectural design decisions and support different goals and uses:
Logical view: When the object-oriented design method is adopted, the logical view is the object model.
Development view: describes the static organization of software in the development environment.
Processing view: Describes the design of the concurrency and synchronization aspects of the system.
Physical view: Describes how software is mapped to hardware and reflects the design of the system in terms of distribution.
Use the 4 + 1 view method: design architecture for different needs
As mentioned earlier, it is not easy to develop software that satisfies users. The software architect must fully grasp the various contradictions between the various needs and weigh the requirements, and classify the different needs one by one. Satisfy.
The 4 + 1 view method proposed by Philippe Kruchten provides a good foundation for software architects to "conquer requirements one by one", as shown in Figure 3.
Figure 3 Using the 4 + 1 view method to design architecture for different needs
Logical view. The logical view focuses on functions, including not only functions that are visible to users, but also "auxiliary function modules" that must be provided to implement user functions; they may be logical layers, function modules, and so on.
Development view. The development view focuses on the package, including not only the source program to be written, but also the third-party SDK and ready-made frameworks and class libraries that can be used directly, and the system software or middleware on which the developed system will run. There may be a certain mapping relationship between the development view and the logical view: for example, the logical layer is generally mapped to multiple packages.
Process the view. The processing view focuses on runtime concepts such as processes, threads, and objects, as well as related concurrency, synchronization, and communication issues. The relationship between processing views and development views: Development views generally focus on the static dependencies of packages at compile time, and these programs will appear as objects, threads, and processes after running. The processing view is more concerned with the interaction of these runtime units problem.
Physical view. The physical view focuses on how the "target program and its dependent runtime and system software" are eventually installed or deployed to the physical machine, and how to deploy the machine and network to match the requirements of the software system's reliability and scalability. The relationship between the physical view and the processing view: the processing view pays special attention to the dynamic execution of the target program, while the physical view attaches importance to the static position of the target program; the physical view is an architectural view that comprehensively considers the interaction between the software system and the entire IT system.
Equipment debugging system case overview
The following part of this article will study a case: a certain type of equipment debugging system.
By using the system, the equipment debugger can check the equipment status (the equipment status information is collected in real time by a dedicated data collector) and send debugging commands. The system use case diagram is shown in Figure 4.
Figure 4 Use case diagram of equipment debugging system
After close cooperation between the developer and the client, the finalized requirements can be summarized in Table 2.
Table 2 Requirements of equipment debugging system
The following uses the 4 + 1 view method recommended by RUP to design architecture from different views to meet different needs one by one.
Logical view: designing an architecture that meets functional requirements
First of all, according to the functional requirements for preliminary design, the division of responsibilities with large granularity. As shown in Figure 5.
The application layer is responsible for the display of device status and provides a simulation console for users to send debugging commands.
The application layer uses the communication layer and the embedded layer to interact, but the application layer does not know the details of the communication.
The communication layer is responsible for implementing a set of dedicated "application protocols" on top of the RS232 protocol.
When the application layer sends a protocol packet containing debugging instructions, the communication layer is responsible for passing it to the embedding layer according to the RS232 protocol.
When the embedded layer sends the original data, the communication layer interprets it as an application protocol packet and sends it to the application layer.
The embedding layer is responsible for the specific control of the debugging equipment, and reading the device status data from the data collector frequently.
The physical specifications of the device control instructions are encapsulated inside the embedding layer, and the specific details of reading the data collector are also encapsulated inside the embedding layer.
Figure 5 Logical view of device debugging system architecture
Development view: design an architecture that meets quality attributes during development
The development view of the software architecture should provide practical guidance for developers. Any design decisions that affect the overall situation should be completed by the architectural design. If these decisions "leak" to the back, they will only be discovered in the stage of large-scale parallel development, which may cause a large number of "programmers to make temporary decisions". Software quality It will inevitably decline or even cause the project to fail.
Among them, which ready-made frameworks, which third-party SDKs, and even which middleware platforms should be considered should be determined by the development view of the software architecture. Figure 6 shows (part of) the software architecture development view of the device debugging system: the application layer will be designed and implemented based on MFC, and the communication layer uses a third-party SDK for serial communication.
Figure 6 Development view of device debugging system architecture
Talking about binding requirements. Constraints should be some design constraints that each architectural view should focus on and observe. For example, considering the constraint that "some developers do not have embedded development experience", it is necessary for the architect to clearly state how the system's target program is compiled: Figure 7 shows the target program pc- on the desktop part of the entire system How moduel.exe and embedded module rom-module.hex are compiled. This global description undoubtedly provides a real sense for inexperienced developers, which is helpful for a more comprehensive understanding of the system's software architecture.
Figure 7 Development view of device debugging system architecture
Processing view: design an architecture that meets runtime quality attributes
Performance is a level of quality that is demonstrated during the operation of a software system and is generally measured by system response time and system throughput. In order to achieve high performance requirements, software architects should analyze and design the software's runtime conditions. This is what we call the processing view of software architecture. The processing view focuses on runtime concepts such as processes, threads, and objects, as well as related concurrency, synchronization, and communication issues. Figure 8 shows the processing view of the device debugging system architecture.
It can be seen that the architect adopted a multi-threaded design in order to meet the high performance requirements:
The thread in the application layer represents the running of the main program, and it directly utilizes the main window thread of MFC. Whether it is user interaction or serial port data arrival, asynchronous events are used to deal with it, which eliminates any "busy waiting" time-consuming and shortens the system response time.
The communication layer has an independent thread to control the "up and down" data, and a data buffer is set up to make the data reception and data processing relatively independent, so that data reception will not be stalled due to temporary busy processing, increasing the system Throughput.
In the design of the embedded layer, the corresponding processing logic is stimulated by the clock interrupt and the RS232 port interrupt, respectively, to achieve the purpose of polling and sending and receiving data.
Figure 8 Processing view of device debugging system architecture
Physical view: architectural decisions related to deployment
The software must eventually reside, install, or deploy to the hardware to run, and the physical view of the software architecture focuses on how the "target program and its dependent runtime and system software" are ultimately installed or deployed to the physical machine, and how to deploy the machine and network Cooperate with the requirements of software system reliability and scalability. The physical architecture view shown in FIG. 9 expresses the mapping relationship between device debugging system software and hardware. It can be seen that the embedded part resides in the debug machine (the debug machine is a dedicated single-board computer), and the PC is a common form of desktop executable program.
Figure 9 Physical view of device debugging system architecture
We may also express the specific target module and its communication structure more clearly through the physical architecture view according to the needs of the specific situation, as shown in Figure 10.
Figure 10 Physical view of device debugging system architecture
Summary and description
The so-called Daosheng. In-depth understanding of the complexity of software requirements classification, clearly distinguishing different types of requirements, such as functional requirements, constraints, runtime quality attributes, and development quality attributes, is the "book", because the impact of various requirements on architectural design is very different. Through the analysis of specific cases, this article shows how to use RUP's 4 + 1 view method to design architectures for different needs, so as to ensure that important needs are met one by one.
This article focuses on the explanation of the method, so it omits the explanation of many specific problems in the architecture design. At the same time, the model that describes the architecture design scheme provided in this article has also been simplified. Readers' attention.
Reprinted from: http://www.uml.org.cn/zjjs/201412262.asp
