Although I generally agree with Bart van Ingen Schenau’s answer, I think a few points need additional elaboration.

Th advantage of the 4+1 View Model is that it maps stakeholders to the type of information that they need, without requiring specific modeling notations to be used. The emphasis is on ensuring that all groups have the information to understand the system and continue to do their job.

The 4+1 View Model of Software Architecture was described in Philippe Kruchten’s paper Architectural Blueprints – The “4+1” View Model of Software Architeture that was originally published in IEEE Software (November 1995). This publication doesn’t make specific references to UML. In fact, the paper uses the Booch notation for the logical view, extensions to the Booch notation for process view and development view, calls out the use of “several forms” of developing a physical view, and a new notation for scenarios.

Instead of trying to map each of the views to particular types of diagrams, consider who the target audience of each view is and what information they need. Knowing that, look at various types of models and which one(s) provide the required information.

The logical view is designed to address the end user’s concerns about ensuring that all of their desired functionality is captured by the system. In an object-oriented system, this is often at the class level. In complex systems, you may need a package view and decompose the packages into multiple class diagrams. In other paradigms, you may be interested in representing modules and the functions they provide. The end result should be a mapping of the required functionality to components that provide that functionality.

The process view is designed for people designing the whole system and then integrating the subsystems or the system into a system of systems. This view shows tasks and processes that the system has, interfaces to the outside world and/or between components within the system, the messages sent and received, and how performance, availability, fault-tolerance, and integrity are being addressed.

The development view is primarily for developers who will be building the modules and the subsystems. It should show dependencies and relationships between modules, how modules are organized, reuse, and portability.

The physical view is primarily for system designers and administrators who need to understand the physical locations of the software, physical connections between nodes, deployment and installation, and scalability.

Finally, the scenarios help to capture the requirements so that all the stakeholders understand how the system is intended to be used.

Once you understand what each view is supposed to provide, you can choose what modeling notations to use and at what level of detail is required. Bart’s last paragraph is especially true – you can show various levels of details in your UML models by focusing on particular design elements or combining various types of diagrams into a set. In addition, you may want to consider going beyond UML to other modeling notations to better describe your system architecture – SysML, Entity-Relation modeling, or IDEF.

The reason that you can’t find a one-to-one mapping between the views of the 4+1 Architectural Model and the various UML diagrams is because such a mapping doesn’t exist.

What all those authors are trying to tell with their ‘mappings’ is that for each view, there is a different set of UML diagrams that can be useful to convey the information that you want to tell in that view.

Additionally, some UML diagrams can be used in different ways, by emphasizing different elements in the diagram, which makes them useful for multiple views. But even if one UML diagram type can be used in multiple views, you would draw a different diagram (or set of diagrams) for each view.

Although I agree with Thomas Owens answers approach to cater for your end-users needs, one thing that is failed to be mentioned is that the reason why the original definition of the “4+1 View Model Architecture” by Kruchten doesn’t make any specific references to UML is because the article was written in 1995 (as the answer states), but UML wasn’t really adopted as a standard until 1997.

The continuous use of the Booch Notation in the article suggests that relating each of the models views to a specific UML diagram could be appropriate, since Grady Booch was one of the people involved in the development of UML.

It is because of this that so many different authors consider different UML diagrams to be applicable to each view, since multiple UML diagrams could be considered in some amount “abstractions” of the Booch Notation that the original definition of the 4+1 model relies on to represent each view.

Hope this clears things up a bit more for anyone else looking into this.

Do you still use VCR that you bought back in 1995.? 4 + 1 was applicable back then when software was in it’s infancy. But even then, nobody ever used more than 2 or 3 “views”. In the last 20 years software engineering changed. Nowadays, scope/context and conceptual and logical and physical and … are all differentiated. A lot of COTS solutions have to be integrated, and so on. Today, we are talking about landscape maps, service realizations and dozens of other views and viewpoints.
The best way to look at it is through a simple taxonomy framework like Zachman: 6 views and 6 viewpoints. Let that be your starting point.
6 views are:
contextual
conceptual or business
logical or system
physical or technology
delivery or artifacts
functioning enterprise

6 viewpoints are:
data or What
function or How
network or Where
people or Who
time or When
motivation or Why

Let’s look an example. If we are interested only in data, we will start with the scope view and say, “Our scope is CRM”. In the conceptual view for data viewpoint we’ll come up with some semantic model for CRM. The model will be conceptual, business information concepts rather than data objects.
Next, in the logical view we’ll produce logical data model from our conceptual model of CRM. We may use ER methodology to produce logical data model.
Then, in the physical view, we’ll produce physical data model. Here, we’ll define concrete data types for db platform of our choice, indexes etc.
Finally, in delivery view we’ll have our DDL script, while in the functioning enterprise view we’ll have a binary file deployed on some database server and mapped into internal data structures of the DBMs vendor.
We repeat this for every viewpoint or column. Also, if there is more than one stakeholder we”ll create more than one model for each viewpoint/view combination.
Now that you have this taxonomy in place, you can define your own viewpoints and views and align these into this taxonomy. For example, for enterprise level initiatives the following viewpoints are all important:
actor cooperation
application behavior
application cooperation
application structure
application usage
business function
business process
business process cooperation
implementation and deployment
information structure
infrastructure
infrastructure usage
landscape map
overview
layered
organizational
service realization
etc

Krutchen’s 4+1 could not possibly satisfy all of these needs