Visual Studio 2010 Architecture Guidance – What is a 4+1 View?

  • Article

Many of the guidance core scenarios refer to a 4+1 view … why 4+1 … why not just a 5 view?

What is the 4+1 View all about?

The 4+1 view model, was designed by a Canadian engineer Philippe Kruchten. In essence the intent is to describe your system’s architecture using four views (logical, development, process and physical), plus an additional scenarios view.

The views, as illustrated above, are:

  • Logical
    • Focus: Functionality of the system.
    • Contents: Class diagrams, Sequence diagrams, Communication diagrams, Layer diagrams.
  • Development (Implementation)
    • Focus: Developer’s perspective.
    • Contents: Component diagram, Package diagrams.
  • Process
    • Focus: Runtime behaviour of the system, such as the system processes and communication, concurrency, performance and scalability.
    • Contents: Activity diagrams
  • Physical (Deployment)
    • Focus: System Engineer’s perspective, looking at the system topology, deployment and communication.
    • Contents: Deployment diagrams
  • Scenarios
    • Focus: Use cases which not only describe the system scenarios and behaviour, but which play an important role in the illustration and validation of the overall architecture.
    • Contents: Use case diagrams

The suggested UML Model layout in the guidance, uses these views:

Why is the guidance referring to the 4+1 view?

The scenarios covered in the guidance are focused on the organization of the architecture artefacts. The 4+1 model view is not the silver bullet, but is mentioned as a possible example to assist you to organise the design artefacts and an organized solution structure.

Off-the-topic … but relevant … what are Anti-Patterns?

Patterns are commonly used to counter-act anti-patterns, such as:

  • Copy and paste programming
  • Hard coding … embedding constants and other assumptions
  • Bloated interfaces … the interfaces with all the methods
  • God objects … which know everything and do everything
  • Reinventing the wheel … instead of re-using and optionally extending existing functionality

I would like to know which team does not and has never used any of the above techniques … but that is opening a can of worms which is best saved for a future post.

Back to the review cycle …