15

I'm a bit confused about how the 4+1 architectural view model maps to UML.

Wikipedia gives the following mapping:

  • Logical view: Class diagram, Communication diagram, Sequence diagram.
  • Development view: Component diagram, Package diagram
  • Process view: Activity diagram
  • Physical view: Deployment diagram
  • Scenarios: Use-case diagram

The paper Role of UML Sequence Diagram Constructs in Object Lifecycle Concept gives the following mapping:

  • Logical view (class diagram (CD), object diagram (OD), sequence diagram (SD), collaboration diagram (COD), state chart diagram (SCD), activity diagram (AD))
  • Development view (package diagram, component diagram),
  • Process view (use case diagram, CD, OD, SD, COD, SCD, AD),
  • Physical view (deployment diagram), and
  • Use case view (use case diagram, OD, SD, COD, SCD, AD) which combines the four mentioned above.

The web page UML 4+1 View Materials presents the following mapping:

UML 4+1 View Materials

Finally, the white paper Applying 4+1 View Architecture with UML 2 gives yet another mapping:

  • Logical view class diagrams, object diagrams, state charts, and composite structures
  • Process view sequence diagrams, communication diagrams, activity diagrams, timing diagrams, interaction overview diagrams
  • Development view component diagrams
  • Physical view deployment diagram
  • Use case view use case diagram, activity diagrams

I'm sure further search will reveal other mappings as well.

While various people usually have different perspectives, I don't see why this is the case here. Specially, each UML diagram describes the system from a particular aspect. So, for instance, why the "sequence diagram" is considered as describing the "logical view" of the system by one author, while another author considers it as describing the "process view"?

Could you please help me clarify the confusion?

18

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 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. Don't you find, that if we want to do something for end users we at least must communicate with them and speak one language. Try to show your class diagram to your users and let's see what they will say. – Pavel Jun 5 '16 at 8:34
  • 1
    @JimJim2000 I didn't say that it was for the end user. If you have a set of requirements and you map them to elements in a logical view, you can ensure that there are components (packages, classes, functions) that are designed to address each requirement. I can't think of very many models from any modeling language that I would show to an end user and expect them to get. Maybe an Activity Diagram from UML. – Thomas Owens Jun 5 '16 at 14:01
9

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.

0

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

  • 2
    This answer is very biased and I disagree with your rationale as to why Kruchten 4 + 1 is "too old". 20 years ago was 1999. Software was not in its infancy; Kruchten still talks about 4+1's relevancy, especially in agile environments. There's a reason viewpoints and views have a presence in IEEE standards regarding architectural description. – Zimano Apr 8 at 16:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.