No single diagram can describe a whole architecture, so Kruchten’s 4+1 model splits the description into four views (logical, process, development, physical), each answering one stakeholder group’s questions with its own UML diagrams, plus the scenario (user) view whose use cases tie the four together and validate them. Each view is illustrated with the same ATM system, so the lecture is also a tour of how to read a class, communication, sequence, activity, component, deployment and use case diagram.
What the system does: classes and objects and their relationships. Functional requirements. Class, object, sequence, communication and state diagrams.
How it runs: processes, threads, concurrency and synchronisation. Performance and scalability. Activity diagrams.
How the code is organised: modules, packages, libraries. Package and component diagrams.
Physical: which software runs on which hardware (deployment diagram). +1: use cases that drive and validate the other four.
The 4+1 model is examined every term. Midterm 252 asked which view evaluates scalability and performance (the process view) and had a whole question filling in the view table (description, stakeholders, UML). Quiz 1 261 asked five questions on the views (logical, development, process, physical, and a matching), and Midterm 261 asked whether the “+1” is the database (false: it is the scenarios).
Every original slide is shown unchanged. Yellow marks on a slide point to a numbered note: hover or tap a mark to jump to its note, and hover a note to see its marks. Questions tagged Past exam appeared on a real paper; Prediction questions are likely angles, not confirmed.
Third architecture lecture. Lecture 1 said an architecture needs several views; this one names the standard set of views and shows each on one example system, an ATM.
The four views are logical, process, development and physical.
The “+1” is the user view, also called the scenario view. It is not a fifth independent description but the use cases that connect and check the other four.
No single view can present every aspect of a system. A class diagram says nothing about servers; a deployment diagram says nothing about classes.
So designers organise their architectural decisions as a collection of views. This breaks a complex system into understandable perspectives and manages complexity.
Each view is a partial representation aimed at specific stakeholders (users, analysts, developers…), so every group gets the view that answers its own concerns.
The best-known way to organise those views is the 4+1 view model.
Why are multiple architectural views required in complex systems?
B. Because no single view can represent all system aspects for all stakeholders
The model was introduced by Philippe Kruchten in 1995.
It has four essential views: logical, process, physical and development. Each one has its own stakeholders, concerns and diagrams.
To keep the four consistent with one another, the user’s perspective is captured in use cases that form the user view. Running a use case through every view checks that they all describe the same system.
Who introduced the 4+1 view model, and what is the role of the “+1” view?
Philippe Kruchten (1995). The +1 is the user (scenario) view: use cases that tie the four views together, help discover architectural elements and validate the design.
The logical view decomposes the system into conceptual entities (objects or classes) and the connections between them.
It is an abstraction of the functional requirements: it shows what the system does, in terms of the things it is made of.
Diagrams: static ones (class and object diagrams) for structure, and dynamic ones (interaction overview, sequence, communication, state and activity diagrams) for how those objects behave together.
Its stakeholders are end users, analysts and designers, the people who care about functionality.
Fill in the blank: The 4+1 view that emphasizes the major functional elements of the system and their relationships is the ___ view.
Logical view.
A class diagram shows the classes, their attributes and operations, and the relationships between them. For the ATM: Bank, ATM Info, Customer, Debit Card, Account and ATM Transaction, each box listing attributes (+code, +address) and operations (+manages()).
Directionality: the arrow from ATM Transaction to Account (“Modifies”) means the transaction acts on the account, and not the other way round. A bidirectional association has two arrowheads or none.
Inheritance: the lines ending in a hollow triangle point from subclass to superclass. Current Account and Saving Account are kinds of Account; Withdrawal, Query, Transfer and PIN-validation transactions are kinds of ATM Transaction.
Association names describe the relationship in words: Bank Maintains ATM Info, Customer Owns Account, Debit Card Provides Access to Account.
Multiplicities give how many objects take part: 1 means exactly one, 1..* one or more. One Bank maintains one or more ATMs.
In the ATM class diagram, what do the hollow triangles from Current Account and Saving Account to Account mean, and how is “1..*” read?
Inheritance (generalisation): Current Account and Saving Account are specialised kinds of Account. “1..*” is a multiplicity meaning one or more.
The communication (collaboration) diagram shows the objects that cooperate in one scenario (Bank Client, ATM Machine, Account, Checking Account) as boxes joined by links.
Messages are written along the links with a number that gives their order. Reading the withdrawal scenario:
It focuses on who talks to whom. The same messages appear on the next slide as a sequence diagram, which focuses on when.
How does a communication (collaboration) diagram differ from a sequence diagram?
Both show objects exchanging messages. A communication diagram emphasises the links between objects and shows order only through message numbers; a sequence diagram lays messages out top to bottom along lifelines, so the time order is the main thing shown.
A sequence diagram models the interactions between design units, the messages they exchange, and the time order of those messages.
How to read it:
C : customer, A : ATM, Accnt : Account, and later CKA : Checking Account (object name : class).The class diagram (slide 6) gives the structure; the sequence diagram gives the behaviour over time for one use case, making clear who does what and in which order.
Which logical-view diagram should you use to show the time order of the messages exchanged during an ATM withdrawal?
A. Sequence diagram
The process view covers the dynamic, run-time behaviour of the system.
It is an abstraction of the processes and threads and shows their concurrency (what runs at the same time) and synchronisation (how they share resources and data without interfering).
It contributes to non-functional requirements such as scalability and performance, which depend on how work is spread across processes.
UML support: the activity diagram and the interaction overview diagram.
Stakeholders: developers and integrators, who put the running pieces together.
Which architectural view mainly contributes to evaluating scalability and performance?
C. Process view — The process view covers runtime processes, concurrency and communication, from which performance and scalability are judged. (The physical view also concerns performance, through hardware; when the options include the process view and the question is about runtime behaviour, choose process.)
Which 4+1 view should an architect emphasize when analyzing concurrent execution, communication among running processes, and synchronization?
D. Process view
An activity diagram describes the flow of the system: its operations and processes, in order, with decisions and parallel paths.
Reading the ATM diagram (three swimlanes: customer, ATM machine, bank):
The development view describes the static organisation of the software modules, from the implementation point of view: how the source code is arranged.
Modules here are building blocks that group classes: class libraries, subsystems, packages.
UML support: package diagrams and component diagrams.
It lets you analyse how logical components map onto physical files and directories, which matters for builds, reuse and team ownership.
Stakeholders: programmers and software project managers (who assign modules to teams).
Fill in the blank: The 4+1 view that focuses on the organization of source-code modules, packages, and development units is the ___ view.
Development view (also accepted: implementation).
A component diagram shows the system’s components with their interfaces, ports and the relationships between them.
Reading the banking system:
Reading tip: a circle attached to a component is an interface it provides. In the development view these components are units of code that teams build and package separately.
The physical view represents deployment: how the software is configured and installed on hardware.
UML support: deployment diagrams.
It is the right view to evaluate availability (redundant nodes), performance and scalability (processor speed, bandwidth) and security (firewalls), because all of these depend on the hardware layout.
Stakeholders: system installers, system administrators and system engineers.
A deployment engineer wants to know which software elements run on which servers and hardware nodes. Which 4+1 view is most useful?
D. Physical view
A deployment diagram models the physical structure the software runs on.
The 3-D boxes are nodes (hardware or execution environments): ATM_Machine, Customer Console, Card_Reader, Bank_Database, Web_Page, Client_Desktop, Employee_Console. The lines are communication paths. Most nodes connect to Bank_Database, so it is the node whose failure takes everything down, which is where you would add redundancy for availability.
The user (scenario) view describes the system’s functionality as the user experiences it: how users use the system and what services it provides them.
It provides the foundation for the other four views and lets them work together logically: every view has to support the same use cases.
It is used twice: to discover architectural elements during design (what does this scenario need?) and to validate the design afterwards (walk the scenario through each view).
So it keeps the architecture consistent and validated against both functional and non-functional requirements.
The “+1” view represents the database structure of the system.
False — The +1 is the scenario (use case) view that illustrates and validates the other four; the database is not a view of its own.
A use case diagram is a behavioural diagram that captures, specifies and visualises the required system behaviour from the user’s side.
The stick figure is the actor, Bank Client. The ovals are use cases: Bank ATM Transaction, Checking Tran, Saving Transaction History, Deposit Amount, Withdrawal Amount, Approval process, Invalid pin.
«uses» (include): Bank ATM Transaction always uses the Approval process. «extends»: optional or special-case behaviour added to a base use case, e.g. Deposit and Withdrawal extend the transaction, and Invalid pin extends the approval process.
Logical: what the system should do, the functionality for end users. Class (static), sequence (dynamic) and collaboration diagrams.
Process: how the system works at run time: concurrency, control flow, processes. Activity, interaction overview and state machine diagrams.
Development: how the system is built, its software organisation in code. Package and component diagrams.
Physical: how the software is mapped to hardware (servers, devices), where components run. Deployment diagram.
+1 User (scenario): captures user scenarios and requirements that drive the other four. Use case diagrams and textual scenarios.
Description row. Logical: the objects of the system and their interaction. Process: processes and workflow rules and how they communicate (dynamic). Development: building-block view, the static organisation of modules. Physical: installation, configuration and deployment. Scenario: shows the design is complete by validating and illustrating it.
Stakeholders row. Logical: end users, analysts, designers. Process: integrators and developers. Development: programmers and software project managers. Physical: system engineers, operators, administrators, installers. Scenario: the stakeholders of the other views and their evaluators.
Considers row. Logical: functional requirements. Process: non-functional requirements. Development: software module organisation (reuse, tool constraints). Physical: non-functional requirements tied to the hardware. Scenario: system consistency and validity.
UML row. Logical: class, state, object, sequence, communication. Process: activity. Development: component, package. Physical: deployment. Scenario: use case.
Complete the 4+1 table: for each of the logical, process, development, physical and scenario views, give its description, stakeholders and UML diagrams.
Logical: objects of the system and their interactions / end users, analysts, designers / class, object, state, sequence, communication. Process: processes and how they communicate (dynamic) / integrators, developers / activity. Development: building blocks, static module organisation / programmers, project managers / component, package. Physical: installation, configuration and deployment / system engineers, operators, administrators / deployment. Scenario: validates and illustrates that the design is complete / the other views’ stakeholders and evaluators / use case.
Match each 4+1 view with its primary concern: logical, process, development, physical, scenario/user.
Logical → major functional elements and their relationships. Process → runtime behaviour, concurrency and communication. Development → organisation of software modules and packages. Physical → deployment of software onto hardware nodes. Scenario/User → use cases that illustrate and validate the architecture.
Which UML diagram belongs to the development view?
A. Package diagram
Recap: be able to name each view and give its concern, stakeholders and diagrams from memory. The summary table on slide 18 is the most likely written question from this lecture.