Four views of one system, because no single diagram can say everything.
🌍 Where this lives: open the documentation of any large open-source system — Kubernetes, PostgreSQL, the Linux kernel — and you will find exactly this: separate documents for the data structures, the module layout, the interfaces, and the runtime behaviour. Not because a standard demanded it, but because a reader asking "what does the on-disk format look like?" and a reader asking "what happens when a request arrives?" need different pictures, and a single diagram attempting both serves neither. Search "4+1 architectural view model Kruchten".
The four design elements
The DESIGN MODEL can be viewed in two dimensions.
THE PROCESS DIMENSION indicates the evolution of the design
model as design tasks are executed — it grows in detail as
iterations proceed.
THE ABSTRACTION DIMENSION represents the level of detail as
each analysis-model element is transformed into a design
equivalent. Elements of the design model use many of the same
UML diagrams used in analysis — but refined and elaborated,
and now implementation-specific rather than
problem-descriptive.
FOUR KINDS OF DESIGN ELEMENT:
1. DATA DESIGN ELEMENTS
Creates a model of data and/or information represented at
a high level of abstraction, then refined progressively
toward implementation-specific representations.
At the PROGRAM COMPONENT level → design of data
structures and the algorithms that manipulate them.
At the APPLICATION level → translation of a data model
into a database.
At the BUSINESS level → a data warehouse, enabling data
mining and knowledge discovery.
2. ARCHITECTURAL DESIGN ELEMENTS
The overall layout of the software — a floor plan. Gives
us the OVERALL VIEW. Derived from three sources:
· information about the application domain
· specific requirements-model elements such as data-flow
diagrams or analysis classes, their relationships and
collaborations
· the availability of architectural styles and patterns
3. INTERFACE DESIGN ELEMENTS
Depict information flowing into and out of the system, and
how it is communicated among the components. Three
important elements:
· the USER INTERFACE (UI)
· EXTERNAL INTERFACES to other systems, devices,
networks or producers/consumers of information
· INTERNAL INTERFACES between design components
Modelled with UML collaboration diagrams and component
diagrams showing the interfaces and the operations each
provides.
4. COMPONENT-LEVEL DESIGN ELEMENTS
Describe the internal detail of each software component:
the data structures for all local data objects, and the
algorithmic detail for all processing within the
component, plus the interface permitting access to all
component operations.
Modelled with UML component diagrams, and the internals
with activity diagrams, pseudocode or PDL.
5. DEPLOYMENT-LEVEL DESIGN ELEMENTS
Indicate how software functionality and subsystems will be
ALLOCATED WITHIN THE PHYSICAL COMPUTING ENVIRONMENT that
will support the software. Modelled with UML deployment
diagrams.
DESCRIPTOR FORM during preliminary design, showing the
environment in general terms
INSTANCE FORM as design proceeds, naming specific
named hardware configurations
Mapping analysis to design — a worked transformation
TAKE ONE ANALYSIS CLASS through to design.
ANALYSIS CLASS (problem-domain, from the requirements model):
┌──────────────────────────┐
│ LicenceApplication │
├──────────────────────────┤
│ applicationNo │
│ applicantName │
│ appliedOn │
│ status │
├──────────────────────────┤
│ submit() │
│ approve() │
│ reject() │
└──────────────────────────┘
Notice: NO types, NO visibility, NO implementation
attributes. An analysis class describes the PROBLEM.
DESIGN CLASS (solution-domain, implementable):
┌──────────────────────────────────────────────┐
│ LicenceApplication │
├──────────────────────────────────────────────┤
│ - applicationNo : String {12 digits, immutable}
│ - applicantName : String {1..120 chars} │
│ - appliedOn : LocalDate │
│ - status : Status {enum} │
│ - version : int ← added for
│ optimistic locking
│ - auditTrail : List<StatusChange> │
├──────────────────────────────────────────────┤
│ + submit() : void throws InvalidStateEx │
│ + approve(officer : OfficerId) : void │
│ + reject(officer : OfficerId, reason : String)│
│ + currentStatus() : Status │
│ - assertTransition(to : Status) : void │
└──────────────────────────────────────────────┘
WHAT THE REFINEMENT ADDED, and why each is design not analysis:
types and multiplicities implementation needs them
visibility (+ / − / #) information hiding, made explicit
exceptions the failure interface
`version` a SOLUTION-domain attribute — the
problem domain has no concept of
optimistic locking; it exists
purely to handle concurrent edits
`auditTrail` satisfies a non-functional
(regulatory) requirement, not a
user-stated function
`assertTransition` private — it is a design decision
about where the state machine
lives, hidden from callers
THE FOUR CHARACTERISTICS OF A WELL-FORMED DESIGN CLASS:
COMPLETE AND SUFFICIENT contains the complete encapsulation
of all attributes and methods
reasonably expected of the class —
and NOTHING MORE
PRIMITIVENESS each method focuses on accomplishing
ONE service
HIGH COHESION a small, focused set of
responsibilities, applying attributes
and methods single-mindedly to
accomplish them
LOW COUPLING collaboration kept to an acceptable
minimum; if a design class
collaborates with all others, the
system is difficult to implement,
test and maintain
FIVE TYPES OF DESIGN CLASS, by layer:
USER INTERFACE classes abstractions for human-computer
interaction
BUSINESS DOMAIN classes refinements of the analysis classes
— the elements that implement
business requirements
PROCESS classes lower-level business abstractions
required to fully manage the domain
classes
PERSISTENT classes data stores persisting beyond
software execution
SYSTEM classes management and control functions
enabling the system to operate and
communicate
Which diagram answers which question
A practical routing table. The mistake to avoid is drawing the
diagram you find easiest rather than the one that answers the
question being asked.
QUESTION DIAGRAM
─────────────────────────────────────────────────────────────
What things exist and how CLASS DIAGRAM
are they related? (structure, static)
What data is stored and ER DIAGRAM / data model
how is it keyed?
What are the parts of the COMPONENT DIAGRAM
system and what interfaces
do they offer?
Where does each part run? DEPLOYMENT DIAGRAM
(nodes, artefacts, protocols)
What happens, in order, SEQUENCE DIAGRAM
when a request arrives? (interaction, dynamic)
Which objects talk to which, COLLABORATION /
regardless of order? COMMUNICATION DIAGRAM
What states can one object STATE MACHINE DIAGRAM
be in, and what triggers
transitions?
What is the flow of one ACTIVITY DIAGRAM
process, including parallel
branches?
Who uses the system, and USE CASE DIAGRAM
for what? (scope, boundary)
STRUCTURE vs BEHAVIOUR is the primary split. Class, component,
deployment and ER diagrams are STRUCTURAL — they show what
exists. Sequence, collaboration, state and activity diagrams
are BEHAVIOURAL — they show what happens. A design with only
structural diagrams has not been thought through, because
nobody has traced a request end to end.
HOW MUCH MODELLING IS ENOUGH? The test: draw a diagram only if
it answers a question somebody is actually asking, or resolves a
disagreement. A diagram that merely restates the code in boxes
is documentation debt — it will drift out of date and then
actively mislead.
The `version` attribute in the worked example is the clearest illustration of the analysis/design boundary. No stakeholder ever asked for optimistic locking; it exists purely because two officers might edit the same application simultaneously. Solution-domain attributes appear in design and never in analysis — and if your "design class diagram" looks identical to your analysis class diagram, no design has happened.
🌍 Go further: Kruchten's 4+1 view model is the canonical formalisation of "one system, several pictures": the logical view (for end-users, the class structure), the process view (for integrators, concurrency and performance), the development view (for programmers, module organisation), the physical view (for engineers, deployment topology), and the +1 — scenarios — which stitch the other four together by walking key use cases through all of them. That last one is the insight: the scenarios are what prove the four views describe the same system rather than four wishes. Search "Kruchten 4+1 view model architecture".
💡 Exam angle: list the design elements — data, architectural, interface, component-level, deployment-level — and say what each models and with which UML diagram. Give the four characteristics of a well-formed design class (complete and sufficient, primitiveness, high cohesion, low coupling) and the five types of design class (user interface, business domain, process, persistent, system). Be ready to refine an analysis class into a design class, adding types, visibility and solution-domain attributes — and to say which additions are design rather than analysis.
Syllabus points
Elements of the design model
Create a free account to tick topics off, take notes as you read, watch the video lessons and get a day-by-day study plan built around your exam date.