4+1 View Model Viewpoints
type: Ontology
imports: core#
license: http://creativecommons.org/licenses/by/4.0/
preferred namespace prefix: fourplus1vp
description: Viewpoint definitions for the 4+1 Architectural View Model. These are language-agnostic viewpoints — they specify concerns and stakeholders but do not prescribe which modeling language to use. A custom metamodel attaches concrete element types via arch:includesConcept.
created: 2026-05-06
modified: 2026-05-06
creator: Kalin Maldzhanski
publisher: Linked.Archi
publisher: linked.archi
version IRI: 0.1.0#
version info: 0.1.0
source: 220018231 The 41 View Model of Architecture

4+1 Viewpoint Catalog
type: ConceptScheme
definition: The five viewpoints from Kruchten's 4+1 model, defined as arch:Viewpoint individuals. Language-agnostic — attach concrete element types from your chosen modeling language via arch:includesConcept.
has top concept: Logical Viewpoint
has top concept: Process Viewpoint
has top concept: Development Viewpoint
has top concept: Physical Viewpoint
has top concept: Scenarios Viewpoint (+1)

End User
type: Stakeholder
definition: Users of the system whose functional needs drive the Logical View.

Software Architect
type: Stakeholder
definition: Responsible for overall system structure and quality attribute trade-offs.

Developer
type: Stakeholder
definition: Builds and maintains the software modules.

System Engineer
type: Stakeholder
definition: Responsible for deployment topology, infrastructure, and operations.

Project Manager
type: Stakeholder
definition: Manages scope, schedule, and team allocation.

Functionality
type: Concern
definition: What services the system provides to its users.

Performance & Concurrency
type: Concern
definition: Runtime behavior, throughput, latency, scalability, and fault tolerance.

Software Management
type: Concern
definition: Module organization, build structure, reuse, team allocation, and development tooling.

Deployment & Operations
type: Concern
definition: Mapping software to hardware, topology, availability, and installation.

Validation & Consistency
type: Concern
definition: Ensuring the four views are consistent and the architecture satisfies key scenarios.

Logical Viewpoint
type: Viewpoint
definition: Specifies the functional decomposition of the system — key abstractions, their responsibilities, and relationships. Answers: what does the system do and how is it structured logically?
viewpoint frames concern: LogicalView
targets stakeholder: End User
targets stakeholder: Software Architect
viewpoint frames concern: Functionality
viewpoint has purpose: Designing
view type: Diagram
in scheme: 4+1 Viewpoint Catalog
top concept of: 4+1 Viewpoint Catalog
scope note: Populate arch:includesConcept with your metamodel's structural elements — e.g., UML Class/Interface/Package, ArchiMate ApplicationComponent/ ApplicationService/DataObject, or custom domain classes.

Process Viewpoint
type: Viewpoint
definition: Specifies the runtime behavior — processes, threads, communication, synchronization, and how the system handles concurrency and distribution. Answers: how does the system behave at runtime?
viewpoint frames concern: ProcessView
targets stakeholder: Software Architect
targets stakeholder: System Engineer
viewpoint frames concern: Performance & Concurrency
viewpoint has purpose: Designing
view type: Diagram
in scheme: 4+1 Viewpoint Catalog
top concept of: 4+1 Viewpoint Catalog
scope note: Populate arch:includesConcept with behavioral elements — e.g., UML Activity/StateMachine/Interaction, BPMN Process/Gateway/Event, ArchiMate ApplicationProcess/ApplicationEvent, or custom flow elements.

Development Viewpoint
type: Viewpoint
definition: Specifies the organization of the software in its development environment — modules, packages, layers, subsystems, build structure, and team ownership. Answers: how is the codebase organized?
viewpoint frames concern: DevelopmentView
targets stakeholder: Developer
targets stakeholder: Project Manager
viewpoint frames concern: Software Management
viewpoint has purpose: Designing
view type: Diagram
in scheme: 4+1 Viewpoint Catalog
top concept of: 4+1 Viewpoint Catalog
scope note: Populate arch:includesConcept with packaging/module elements — e.g., UML Component/Package, C4 Container/Component, Backstage Component/System, or custom module types.

Physical Viewpoint
type: Viewpoint
definition: Specifies the mapping of software to hardware — nodes, networks, deployment topology, and resource allocation. Answers: where does the software run?
viewpoint frames concern: PhysicalView
targets stakeholder: System Engineer
viewpoint frames concern: Deployment & Operations
viewpoint has purpose: Designing
view type: Diagram
in scheme: 4+1 Viewpoint Catalog
top concept of: 4+1 Viewpoint Catalog
scope note: Populate arch:includesConcept with infrastructure elements — e.g., UML Node/Artifact, ArchiMate Node/Device/SystemSoftware/CommunicationNetwork, C4 DeploymentNode/InfrastructureNode, or custom infra types.

Scenarios Viewpoint (+1)
type: Viewpoint
definition: The unifying viewpoint — key use cases or scenarios that trace through all four views, validating that the architecture supports the most important user goals. Answers: does the architecture work end-to-end?
viewpoint frames concern: ScenariosView
targets stakeholder: End User
targets stakeholder: Software Architect
targets stakeholder: Developer
viewpoint frames concern: Validation & Consistency
viewpoint frames concern: Functionality
viewpoint has purpose: Deciding
view type: Diagram
in scheme: 4+1 Viewpoint Catalog
top concept of: 4+1 Viewpoint Catalog
scope note: Populate arch:includesConcept with scenario/use-case elements — e.g., UML UseCase/Actor, ArchiMate Stakeholder/Goal/Requirement, or custom scenario types. Scenarios should reference elements from all other four viewpoints.