4 + 1 ing between views and UML

N 4 + 1 view model Overview Kruchten proposes a "4 + 1" view model, which describes the software architecture from five different perspectives: logical attempt, process view, physical view, development view, and scenario view. Each view only cares about one side of the system. The five view attempts to be combined to reflect the entire content of the system's software architecture. For example: NLogic View ) Logic attempts are mainly used Describe the functional requirements of the System That is, the system provides End User In the logic view, the system is divided into a series of functional abstraction, functional decomposition, and functional analysis, which are mainly from the problem domain (problem definition ). In object-oriented technology, through abstraction, encapsulation, and inheritance, the object model can be used to represent the logical view. Class digraphs can be used to describe the logical view. For example: Component (Components): Class, Class service, parameterized Class, Class Level Connector (Connectors): Association, including aggregation, use, inheritance, and instantiation N Development View (Development/module view) The development view is mainly used Describe the organization and management of software modules (Through libraries or subsystems ). Serving Software Programmers To facilitate subsequent design and implementation. It is described through the model diagram and subsystem diagram of the system input/output relationship. Consider the internal requirements of software: the difficulty of development, the possibility of reuse, versatility, limitations, and so on. The style of the development view is usually a hierarchical structure. The lower the level, the better the versatility (the underlying Library: Java SDK and image processing software package ). For example: Component : Module, subsystem, Layer Connector : Reference correlation, module/process call n Process view The process tries to focus on the System Running Features Focus on non-functional requirements (performance and availability ). Serving on System integration personnel To facilitate subsequent performance tests. It emphasizes concurrency, distribution, integration, robustness (fault tolerance), scalability, and throughput. Define the specific operation of each class in the logic view in which thread is executed. For example: Component Process, simplified process, and cyclic process Connector : Unspecified, message, Remote Procedure Call (RPC), bidirectional message, event broadcast N Physical View Main Physical attempts Description hardware configuration . Serving on System Engineering Personnel To solve the topology, system installation, and communication problems of the system. The main consideration is how to map software to hardware, as well as system performance, scale, and reliability. It can be mapped with the process view. For example: Component : Processors, computers, and other devices Connector : Communication protocols N Scenario (scenarios) Scenario used Describe the relationship between components And organically associate the four views. You can describe the component relationships in a specific view or the component relationships between different views. Text and graphic representation. N Summary The logical view and development view are mainly used to describe the static structure of the system. Process view and physical view are mainly used to describe the dynamic structure of the system. Not every system must draw five views, but each has its own focus. For example, the MIS system focuses on the logic view and development view, while the real-time control system focuses on the process view and physical view.

We usually choose UML to present various views. The following lists the UML ing between UML and various views.

4 + 1ViewUML

Scenario view use case

Logical view class diagram

Development View class diagram, component Diagram

The process view does not have a full correspondence

Deployment View

In architecture design stability, a large number of case descriptions are usually not provided, which are defined in demand stability. However, some use cases are often selected in the architecture document and included in the document. These use cases are used together with some non-functional requirements to prove the effectiveness and correctness of the architecture. In the logical view, the implementation of use cases is indispensable, although the architecture design focuses more on non-functional requirements.

Thoughts on integrating with MDA

It is often difficult to distinguish between the logical view and the development view. The logical view contains more analysis models and implementation technologies, such as the business object model and its extension. The development view is closely related to the implementation technology.

With the promotion of the idea of MDA, the writing of architectural design documents has also had an impact. It is not difficult to associate the PIM of MDA with the logical view, in contrast, we associate the SMS in the MDA with the development view.

When writing a logical view, we should describe the model irrelevant to the technical platform, while the Development View describes the Model Related to the implementation technical platform.

For example, some entity classes displayed in the logical view, we will switch to the EJB component (Entity Bean) in the development view ).

This approach not only helps us to write architecture design documents, but also provides a good architectural design thinking process.

4 + 1 ing between views and UML