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 usedDescribe the functional requirements of the SystemThat is, the system providesEnd UserIn 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

NDevelopment View (Development/module view)
The development view is mainly usedDescribe the organization and management of software modules(Through libraries or subsystems ). Serving SoftwareProgrammersTo 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, LayerConnector: Reference relevance, module/process call
NProcess view

The process tries to focus on the SystemRunning FeaturesFocus on non-functional requirements (performance and availability ). Serving onSystem integration personnelTo 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:ComponentProcess, simplified process, and cyclic process

Connector: Unspecified, message, Remote Procedure Call (RPC), bidirectional message, event broadcast

NPhysical View 　
Main Physical attemptsDescription hardware configuration. Serving onSystem Engineering PersonnelTo 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








NScenario (scenarios) 　
Scenario usedDescribe the relationship between componentsAnd 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.

NSummary
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 + 1 View UMLScenario view Use Case Logic View class diagram Development View class diagram. Component diagram process view does not have a full correspondence with deployment view deployment diagram. Generally, many use case descriptions are not provided in stable architecture design, these 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 MDAIt 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.