Using Rup 4+1 View method to design software architecture __ Software

To develop a user-satisfied software is not easy, the software architect must fully grasp the various requirements, balance the need for potential contradictions between the needs of different categories to meet. From the understanding of the complexity of requirements, this paper demonstrates how to design the architecture of different requirements through RUP's 4+1 view method, so as to ensure that important requirements are met. How to pay more attention to graph method in architecture design

Inspiration Flash, think of the way to put the elephant into the fridge, which is naturally good. But it is unrealistic to expect that every architectural design strategy relies on inspiration-we need guidance from the system approach.

The need for architectural design to focus on the graph approach is fundamentally due to the complexity of the requirements category. Take the example of engineering to clear the area. For example, to design a bridge across the river: we will consider the "connecting north-South Road traffic" This "functional requirements", in order to design the ideal Bridge Pier support plan, and then consider the "constraints", the constraints may be "can not affect the million-ton round from the bridge through", and then refine the design scheme, Specify the height of the piers and the spacing between the piers; In addition, the "Quality properties of the bridge" should be taken into account, for example, in order to "maintain stability in a fast-flowing river", the bridge piers can be built deep above the rock layer and the earth seamless; in fact, "quality properties during construction" is well worth considering, For example, in the design process of the bridge to consider the "construction of convenience" measures.

Similar to the functional requirements, constraints, usage quality attributes, and quality attributes during construction, the requirements of software systems are also quite complex, as shown in Figure 1.

Fig. 1 Complexity of software requirements Classification Supermarket system case: Understanding the complexity of requirements categories

Example is the best teacher. To better understand the complexity of software requirements, let's analyze a practical example. In table 1, we enumerate a subset of the requirements for a typical supermarket system, from which you can see clearly that requirements can be grouped into two broad categories: functional requirements and non-functional requirements.

Table 1 Supermarket system case: Understanding the complexity of requirements categories

In simple terms, functional requirements are "what the software does, what the software needs to do". At the same time, it is the best practice of software requirement to grasp the hierarchy of functional requirements. Take the supermarket system as an example:
Supermarket bosses want to "improve cashier efficiency" through software.

Then, you may need to provide a series of functions for the cashier to facilitate this, such as the "free item can be canceled by the cashier" function to provide cashier efficiency (the author has been in the supermarket has been forced to cancel the whole and then a car to rescan the price of the pain experience).

and specific to this supermarket system, system analyst may decide to provide the specific function: through the register of the key combination, can make the cashier process from "entry state" into the "Select cancellation status", thereby canceling a commodity.

From the above example, we are also surprised to find that non-functional requirements-one of the broad categories of requirements that people most often overlook-are very broad and extremely important. Non-functional requirements can also be divided into the following three categories:

Constraints. It is not easy to develop a user-satisfied software, and a comprehensive understanding of the constraints faced by the software system you want to design can make you a step closer to success. Binding requirements include both enterprise-level business considerations (such as "project budgets are limited"), as well as end-user-level realities (such as "low user average computer operating level"), and may include explicit requirements for specific technologies (such as "Requirements to run on Linux"), You may also need to consider the real situation of the development team (for example, "developers dispersed across different locations"). These binding requirements of course have a great impact on architectural design, for example, the "Project budget Limited" limit, the architect should not choose expensive technology or middleware, and considering the spread of developers in different locations, we should pay attention to the Software Module Responsibility Division of the rationality, loose coupling and so on.

Run-time quality properties. This kind of requirement mainly refers to the quality level that the software system displays during its operation. Runtime quality properties are critical because they directly affect the customer's satisfaction with the software system, and most customers do not accept software systems that have poor run-time quality attributes. Common runtime quality attributes include ease of use, performance, scalability, continuous availability, robustness, and security of software systems. In our supermarket system case, users have specific requirements for high performance (real performance requirements should be quantified, not shown in our table 1), and they cannot tolerate delays that amount to more than 2 seconds in total.

Development period Quality properties. Some of these non-functional requirements people are obsessed with it, but many people do not realize how the impact of the development period quality attribute and the Run-time quality attribute on the architecture design is different. Development-Time quality attributes are a developer's greatest concern, and what is to be achieved depends on the specific circumstances of the project, and the excessive design (overengineering) costs extra. What is a software architecture view

So, what is the software architecture view? Philippe Kruchten wrote in his book, "Introduction to the rational unification process":

A schema view is a simplified description of a system that is seen from a perspective or point that covers a particular aspect of the system and omits entities unrelated to this aspect.
In other words, the framework to cover the content and decision-making too much, more than the human brain "overnight" capacity, so the use of "divide and conquer" approach from different perspectives to design, but also for the understanding of software architecture, communication and archiving provides convenience.

In particular, most books emphasize that the multiple view approach is a way to archive software architectures, but it is not. The multi view method is not only the architecture archiving technology, but also the thinking method of guiding our architecture design.

4+1 View method proposed by Philippe Kruchten

In 1995, Philippe Kruchten published a paper titled "The 4+1 View Model of Architecture" in the IEEE Software, which aroused great concern in the industry and was eventually adopted by RUP. As shown in Figure 2.

Fig. 2 4+1 View method proposed by Philippe Kruchten

The different schema views of this approach carry different architectural design decisions, supporting different goals and purposes:

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.

Working with Views: Describes the design of the concurrency and synchronization aspects of the system.

Physical view: Describes how the software maps to the hardware and reflects the design of the system in terms of distribution.

Using the 4+1 View method: Architecture design for different needs

As mentioned above, to develop user-satisfied software is not an easy task, software architects must fully grasp the various requirements, balance the need for potential contradictions between the needs of different categories to meet.

The 4+1 view approach presented by Philippe Kruchten provides a good foundation for software architects to "conquer the needs of one by one", as shown in Figure 3.

Figure 3 Using 4+1 view method to design architecture for different requirements

Logical view. The logical view focuses on features that not only include user-visible features, but also "accessibility modules" that must be provided to implement user functions; they may be logical layers, functional 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 direct use of the Third-party SDK and ready-made frameworks, class libraries, and the system software or middleware that the system will run on. There may be a mapping relationship between the development view and the logical view: for example, the logical layer typically maps to multiple packages.

Process the view. Processing views focuses on run-time concepts such as processes, threads, objects, and related concurrency, synchronization, and communication issues. Dealing with the relationship between a view and a development view: Development View generally emphasizes the static dependencies of the package at compile time, and these programs run as objects, threads, processes, and the view is more concerned with the interaction of these run-time units.
Physical view. The physical view focuses on how the target program and its dependent runtime and system software ultimately installs or deploys to the physical machine, and how the machines and networks are deployed to match the reliability and scalability of the software system. The relationship between physical view and processing view: The processing view pays particular 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 the architectural view that comprehensively considers the interaction between the software system and the entire IT system. Equipment Debugging System case Overview

The following sections of this article will study a case: a certain type of equipment debugging system.

By using the system, the device debugger can view the state of the equipment (the state information of the equipment is collected in real time by the dedicated data collector) and send the debugging commands. The use case diagram of the system is shown in Figure 4.

Fig. 4 Use case diagram of equipment debugging system

With the close cooperation between the development and the client, the final identified requirements can be expressed in table 2.

Table 2 Requirements for equipment commissioning systems

The following uses the RUP recommended 4+1 view approach to design the architecture from different views to categorize the different requirements. Logical View: Architecture designed to meet functional requirements

First, according to the functional requirements of the preliminary design, a large granularity of responsibility division. As shown in Figure 5.

The application layer is responsible for the display of the device status and provides a simulation console for the user to send debug commands.

The application layer interacts with the communication layer and the embedded layer, but the application layer does not know the details of the communication.

The communication layer is responsible for implementing a dedicated "Application protocol" on top of the RS232 protocol.

When the application layer sends a protocol package containing debugging instructions, the communication layer is responsible for passing it to the embedded layer according to the RS232 protocol.

When the embedded layer sends the original data, it is interpreted by the communication layer as an application protocol packages to the application layer.

The embedded layer is responsible for the specific control of the debugging equipment and the high frequency of reading the device state data from the data collector.

The physical specification of the device control instruction is encapsulated inside the embedded layer, and the specific details of the reader are encapsulated inside the embedded layer.

Figure 5 Logical view of the device Debug system Architecture Development View: Design architecture that meets the quality attributes of the development period

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, these decisions if "leakage" to the back, and finally to the large-scale parallel development phase to discover, may cause "the programmer to meet the provisional decision" of a large number of cases, software quality will inevitably fall or even cause project failure.

Among them, which ready-made framework, which Third-party SDK, and even which middleware platform, should consider whether the development view of software architecture is determined. Figure 6 shows the (partial) software architecture Development view of the device debugging system: The application layer will be implemented on the basis of MFC design, and the communication layer uses the third party SDK of a serial port communication.

Figure 6 Development view of the device Debug system architecture

Talk about binding demand. Constraints should be some of the design constraints that each schema view should focus on and follow. For example, given the constraint that "some developers do not have embedded development experience", it is necessary for the architect to specify how the target program for the system was compiled: Figure 7 shows the target program for the desktop portion of the entire system Pc-moduel.exe, And how the embedded module Rom-module.hex is compiled. This global description undoubtedly provides a sense of experience for inexperienced developers to understand the software architecture of the system more comprehensively.

Fig. 7 The development view of the device debug system Schema processing view: Designing the architecture to meet the Run-time quality attributes

Performance is a quality level displayed during the software system operation, which is generally measured by system response time and system throughput. To achieve high performance requirements, software architects should analyze and design the software's run-time situation, which is what we call the software architecture's processing view goal. Processing views focuses on run-time concepts such as processes, threads, objects, and related concurrency, synchronization, and communication issues. Figure 8 shows the processing view of the device debug system architecture.

As you can see, architects are using multithreaded design to meet high-performance requirements:

The threads in the application tier represent the operation of the main program, which leverages MFC's main window thread directly. Whether the user interaction, or the serial port data arrives, all take the way of asynchronous event processing, eliminate any "busy waiting" unnecessary time-consuming, also shorten the system response time.

The communication layer has a separate thread to control the "up and down" data, and set up a data buffer, so that the data received and data processing relatively independent, so that data reception will not be busy with the temporary processing of stagnation, increased system throughput.

In the design of embedded layer, the corresponding processing logic is stimulated by clock interrupt and RS232 interrupt respectively, which achieves the purpose of polling and sending and receiving data.

Figure 8 Device Debug System Architecture processing View Physical view: Architectural decisions related to deployment

Software ultimately resides, installs, or deploys to hardware to run, and the physical view of the software architecture focuses on how the target program and its dependent runtime and system software ultimately installs or deploys to physical machines, and how to deploy machines and networks to meet the reliability, scalability, and other requirements of the software system. The physical Schema view shown in Figure 9 expresses the mapping relationship between the software and hardware of the device debugging system. As you can see, the embedded part resides in the debugger (the debugger is a dedicated single board machine), and the PC is a common form of desktop executable.

Figure 9 Physical view of the device Debug system architecture

We may also express the specific target module and its communication structure more explicitly through the physical Schema view, as shown in Figure 10, depending on the needs of the situation.

Fig. 10 Summary and description of the physical view of the device Debug system architecture

The so-called Benlidas. Deep understanding of the complexity of software requirements classification, clear distinction between functional requirements, constraints, run-time quality attributes, quality attributes of the development period and other types of requirements are "this", because the impact of different types of requirements on the architecture design is very different. Through the analysis of specific cases, this paper shows how to design the architecture of different requirements through RUP's 4+1 view method, so as to ensure that important requirements are met.

This paper focuses on the explanation of the method, thus omitting the explanation of many specific problems in the architecture design, and the model of the architecture design is simplified. Please note to the reader.

Reprinted from: Http://www.uml.org.cn/zjjs/201412262.asp