Use the rup4 + 1 view method for Software Architecture Design

Page 1

 

It is not easy to develop software that is satisfactory to users. Software architects must fully grasp the possible conflicts between various requirements and weigh requirements, different requirements are met in different categories. This article starts from understanding the complexity of the requirement types and demonstrates how to design the architecture based on different requirements through the 4 + 1 View of the RUP, this ensures that important requirements are met one by one.

Multiple View methods for Architecture Design

A flash of inspiration, I came up with a way to put an elephant in the refrigerator, which is naturally good. But it is unrealistic to expect every architectural design strategy to rely on inspiration-we need guidance from system methods.

The multi-view method that requires architectural design is fundamentally caused by the complexity of the types of requirements. Let's start with an example in the engineering field. For example, to design a cross-river bridge: we will consider "connecting North-south highway traffic" and "functional requirements", so as to initially design an idealized Highway Bridge with Pier support; then, we need to consider the "constraints" facing bridge construction. This constraint may be "cannot affect the passing of a ten-ton wheel bridge from the bridge". Therefore, we need to refine the design scheme, specify the distance between the height of the pier and the distance between the pier. In addition, we must take into account the "quality attributes of the Bridge during use", for example, to "maintain stability in the busy River ", the bridge pier can be deeply built on the upper layer and integrated with the earth. In fact, "quality attribute During Construction" is also worth considering, for example, some measures of "convenient construction" should be considered during the design of the bridge.

Similar to functional requirements, constraints, quality attributes during use, and quality attributes during construction in the engineering field, the types of requirements for software systems are also quite complex, as shown in type 1.

Figure 1 complexity of software requirement Classification

Supermarket system case: understanding the complexity of demand types

The example is the best teacher. To better understand the complexity of software requirement types, let's analyze a practical example. In table 1, we list the demand subsets of a typical supermarket system. From this example, we can clearly see that the requirements can be divided into two categories: functional requirements and non-functional requirements.

Table 1 supermarket system case study: understanding the complexity of demand types

Simply put, the functional requirement is "what is the use of the software and what the software needs to do ". At the same time, it is the best practice to grasp the hierarchy of functional requirements. Take the supermarket system as an example:

* Supermarket owners hope to "improve the cash register efficiency" through software ".
* Then, you may need to provide the cashier with a series of functions to facilitate this purpose, for example, the "any item can be canceled separately" function provided by the cashier is conducive to providing cash register efficiency (I have had a painful experience in the supermarket where I was forced to cancel the whole order and then rescan the charges for a car of goods ).
* Depending on the supermarket system, the system analyst may decide the specific function to provide: through the key combination of the cashier terminal, you can enable the cashier process to go from "entry status one by one" to "select cancel status" to cancel a commodity.

From the above examples, we are surprised to find that non-functional requirements-one of the most frequently overlooked requirements-include very wide and extremely important content. Non-functional requirements can be divided into the following three types:

* Constraints. It is not easy to develop software that is satisfactory to users. A thorough understanding of the constraints on the software system to be designed can lead you to a step toward success. Binding requirements include enterprise-level commercial considerations (such as "limited project budget") and actual conditions at the end user level (such as "low average user computer operation level "); it may include clear technical requirements (for example, "requirements can be run on Linux "), you may also need to consider the real situation of the development team (for example, "developers are scattered in different locations "). Of course, these binding requirements have a great impact on the architecture design. For example, if the project budget is limited, architects should not choose expensive technologies or middleware, considering that developers are scattered in different locations, we should pay more attention to the rationality and loose coupling of software module responsibility division.
* Quality attribute during runtime. This type of requirement mainly refers to the quality level of the software system during operation. Runtime quality attributes are critical because they directly affect customers' satisfaction with software systems, and most customers will not accept software systems with poor runtime quality attributes. Common runtime quality attributes include ease of use, performance, scalability, continuous availability, robustness, and security of the software system. In the case of our supermarket system, users have put forward specific requirements for high performance (the real performance requirements should be quantified, which is not reflected in table 1 ), they cannot tolerate a latency of more than 2 seconds in total.
* Quality attributes during development. Some of these non-functional requirements are hard to remember. Unfortunately, many people are not aware of the differences between the "quality attribute during development" and "quality attribute during runtime" on architecture design. Developers are most concerned about the quality attribute during the development period. The goal should be determined based on the specific circumstances of the project, and overengineering will incur additional costs.

 

Page 2

 

What is the software architecture view?

So what is the software architecture view? Philip kruchten wrote in his book "Introduction to the Rational Unified Process:

An architecture view is a simplified description of a system from a certain perspective or point. The description covers a specific aspect of the system, the entity irrelevant to this aspect is omitted.

That is to say, the architecture has to cover too much content and decision-making, which is beyond the capabilities of the human brain. Therefore, the "divide and conquer" approach is used to design separately from different perspectives. At the same time, it also facilitates the understanding, communication and archiving of the software architecture.

It is worth noting that most books emphasize that the multi-view method is the archive method of the software architecture. The multi-view method is not only an architecture archiving technology, but also a method of thinking that guides us in architecture design.

4 + 1 view method proposed by Philip kruchten

In 1995, Philip kruchten published a paper entitled the 4 + 1 view model of architecture in IEEE software, which attracted a lot of attention in the industry and was finally adopted by RUP. 2.

Figure 2 4 + 1 view method proposed by Philip kruchten

Different architecture views of this method bear different architectural design decisions and support different objectives and purposes:

* Logical view: When an object-oriented design method is used, the logical view is the object model.
* Development View: Describes the static organization of the software in the development environment.
* Processing view: describes the system's concurrency and synchronization design.
* Physical view: describes how software is mapped to hardware, reflecting the system's distributed design.

Use the 4 + 1 view method: design the architecture based on different requirements

As mentioned above, it is not easy to develop software that satisfies users. Software architects must fully grasp various requirements and weigh the potential contradictions between requirements, different requirements are met in different categories.

The 4 + 1 view method proposed by Philip kruchten provides a good foundation for software architects to "conquer needs one by one", as shown in figure 3.

Figure 3 Architecture Design Based on different requirements using the 4 + 1 View

Logic view. The focus of the logical view includes not only the visible functions of the user, but also the "auxiliary function modules" that must be provided to implement the user's functions. They may be logical layers and functional modules.

Development View. The development view focuses on packages, including not only source programs to be compiled, but also third-party sdks, ready-made frameworks, and class libraries that can be directly used, and the system software or middleware on which the developed system runs. There may be a certain ing relationship between the Development View and the logical view. For example, the logical layer is usually mapped to multiple packages.

Processing view. The processing view focuses on processes, threads, objects, and other runtime concepts, as well as related concurrency, synchronization, and communication issues. Relationship between the processing view and the development view: the development view focuses on the static dependency of the package during the compilation period. After these programs run, they will be represented as objects, threads, and processes, the view processing focuses on the interaction of these runtime units.

Physical view. The physical view focuses on how to install or deploy the target program and its dependent runtime libraries and system software to the physical machine, and how to deploy machines and networks to meet the reliability and scalability requirements of software systems. Relationship between the physical view and the processing view: the processing view focuses on the dynamic execution of the target program, while the physical view focuses on the static location 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.

 

Page 3

 

Overview of device debugging system Cases

The following section describes a Case Study: A debugging system for a certain device model.

By using this system, device administrators can view the status of the device (the status information of the device is collected in real time by a dedicated Data Collector) and send Debugging commands. Figure 4 shows the example of the system.

Figure 4 example of a device debugging system

After close cooperation between the developer and the entrusting party, the final requirements can be expressed in table 2.

Table 2 Requirements of the device debugging system

The following uses the 4 + 1 view method recommended by RUP to design architectures from different views to meet different requirements in different categories.

Logic view: design an architecture that meets functional requirements

First, we will conduct a preliminary design based on the functional requirements and divide responsibilities at a large granularity. 5.

* The application layer displays the device status and provides a simulated console for users to send Debugging commands.
* The application layer interacts with the embedded layer, but the application layer does not know the communication details.
* The communication layer is responsible for implementing a dedicated "application protocol" over the RS232 protocol ".
* When the application layer sends a protocol package containing debugging instructions, the communication layer is responsible for transmitting the package to the embedded layer according to the RS232 protocol.
* When the embedded layer sends raw data, the communication layer interprets it as an application protocol package and sends it to the application layer.
* The embedding layer is responsible for controlling the debugging device and reading the device status data from the data collector at high frequency.
* The physical specifications of Device Control commands are encapsulated in the embedded layer, and the details of reading the data collector are also encapsulated in the embedded layer.

Figure 5 logic view of the device debugging system architecture

Page 4

 

Development View: design an architecture that meets the quality attributes of the development phase

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 architecture design. If these decisions are "missed", they will not be discovered until they reach the large-scale parallel development stage, there may be a large number of "Temporary decisions made by programmers", and the software quality will inevitably decline or even lead to project failure.

The ready-made frameworks, third-party sdks, and even middleware platforms should be determined by the development view of the software architecture. Figure 6 shows the (Part) Software Architecture Development View of the device debugging system: the application layer is designed and implemented based on MFC, and the communication layer uses a third-party SDK for serial communication.

Figure 6 Development View of the device debugging system architecture

Let's talk about binding demands. Constraints should be some design restrictions that every architecture view should pay attention to and comply. For example, considering the constraint "Some developers have no embedded development experience", it is necessary for the architect to clearly explain how the system's target program is compiled: Figure 7 shows the target program pc-moduel.exe on the entire system and the embedded module Rom-module. how Hex is compiled. This global description undoubtedly provides a sense of experience for inexperienced developers, facilitating a more comprehensive understanding of the system's software architecture.

Figure 7 Development View of the device debugging system architecture

Processing view: design an architecture that meets the quality attributes during runtime

Performance is a quality level shown during the running of the software system, which is generally measured by the system response time and system throughput. To meet the high performance requirements, the software architect should analyze and design the Running Conditions of the software. This is what we call the processing view of the software architecture. The processing view focuses on processes, threads, objects, and other runtime concepts, 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 adopts a multi-threaded design to meet high-performance requirements:

* The thread in the application layer represents the running of the main program. It uses the main window thread of MFC directly. Both user interaction and serial data Arrival Process asynchronous events to eliminate unnecessary time consumption and shorten system response time.
* The communication layer has independent threads that control "Up and down" data and set a data buffer to make data receiving and processing relatively independent, therefore, data reception does not stop due to temporary busy processing, increasing the system throughput.
* In the design of the embedded layer, the corresponding processing logic is stimulated by clock interruption and RS232 port interruption to achieve polling and data sending and receiving.

Figure 8 processing view of the device debugging system architecture

 

Page 5

 

Physical view: Architecture decisions related to deployment

The software can run only when it is resident, installed, or deployed to the hardware, the physical view of the software architecture focuses on how to install or deploy the target program and its dependent runtime libraries and system software to the physical machine, and how to deploy machines and networks to meet the reliability and scalability requirements of software systems. The physical architecture view shown in Figure 9 shows the ing between the software and hardware of the device debugging system. It can be seen that the embedded part is resident in the debugging machine (the debugging machine is a dedicated single board machine), while the PC is a common form of desktop executable program.

Figure 9 physical view of the device debugging system architecture

We may also use the physical architecture view to clearly express the specific target module and its communication structure as needed, as shown in figure 10.

Figure 10 physical view of the device debugging system architecture

Summary and description

The so-called primary school student. A deep understanding of the complexity of software requirement classification, and a clear distinction between functional requirements, constraints, runtime quality attributes, development quality attributes, and other different types of requirements is "this ", because various requirements have different influences on the architecture design. Through case studies, this article shows how to design the architecture based on different requirements through the 4 + 1 view method of RUP, so as to ensure that important requirements are met one by one.

This article focuses on the explanation of the method. Therefore, many specific problems in the architecture design are omitted. At the same time, the model of the architecture design scheme described in this article is simplified.