SoftwareArchitecture-Ch-3-v4.pdf

Software Architecture & Design, Chapter III: Architectural modelling
© 2023, UKH, Dr.Ibrahim Ismael Hamarash, ibrahim.hamad@ukh.edu.krd
Software Architecture and Design
Chapter III
Architectural modelling
Professor Dr Ibrahim Hamarash
ibrahim.hamad@ukh.edu.krd

Software Architecture, Different diagrams and visualization

What is modelling?
Architecture is about making the principal design decisions about
your system. And when you make all these decisions, you collect them
into a model.
Case Study: You want to build a Web application, you need to do the
browser front end; you need to have the server and you need to have
a database. But if the web application is mostly static, maybe you
don’t need a database. Instead, you can use Jenkins to generate the
site from a database. The database is used at compile time but
doesn’t need to be there when you run the application. Just when you
build it.

What is modelling?
➢ An architectural model is an artefact
that captures some or all of the design
decisions that comprise a system’s
architecture.
➢ Architectural modelling is the
reification and documentation of those
design decisions.

Abstraction and
Interpretation
The architecture models
only some interesting
aspects of a software
system.

Solving Problems with Models
Abstract models help to find solutions to
difficult engineering problems.

Case Study: Zoom In and Out Model Strategy
(Overview first, zoom and filter, then details-on-demand)
Imagine you have new developers joining the team.
They have to get on board on their first day. How
are you going to explain your software without
spending years in training or having them go through
the entire commit history log? There should be a
model, providing a general overview and then as you
get questions you can zoom in and show as many
details as necessary.

The View
The idea of views comes from the fact that software
is a complex, multi-faceted digital artefact. Both
considering its code, but also beyond code, there’s
just so much complex information that you cannot
capture it all in one place, with a single model.
If you want to organize the model of a software
system, you want to decompose the model according
to different viewpoints or perspectives. Each of
those is concerned with different aspects of the
software.
A view is a set of design
decisions related by
common concerns (the
viewpoint)

➢ Each view can be used to talk to different people:
a view that is used by marketing people to sell
your software (e.g., a colourful PowerPoint slide),
or the big picture view used for onboarding.
Another view can be so detailed that can be used
to automatically generate the code from it by
developers.
➢ Various parts of the architecture (or views) may
have to be modeled with a different: Notation,
Level of detail, and Target Audience.

Multiple Views
Views are projections of
your architectural model into
multiple viewpoints. You can
have as many as necessary.

How many Views?
➢ We consider our model as a set of design decisions for which
we picked one alternative for the corresponding design issue.
➢ Since there are so many of them, we can try to group them
together.
➢ For example, all decisions that have to do with the structure
of the system in one view. All decisions that have to do with
the interaction between different parts. Decision on how we
deploy the system. These are all decisions that can be
grouped together in the same view.
➢ There is one model, one set of decisions, which we project or
subdivide into multiple views.

Examples of views:
• System Context
• Functional
• Logical
• Physical
• Deployment
• Development
• Information
• Process
• Operational
• Security
• Performance and Scalability
• Availability and Reliability
• Evolution
• Teachability
• Marketing
• Business Impact
…
.. And more

Now we have the views, we need to model
them. Domain and Design Models

Domain Model
➢ Refutable truths about the real-world
➢ Outside your control
➢ Your system will be evaluated against it
➢ Architecturally significant requirements
➢ Problem domain description:
• Information (invariants,
navigation, snapshots)
• Functionality (use-case
scenarios, feature models)
➢ Define shared vocabulary and
understanding towards your customer
and domain expert.
• After you produce a
solution by writing
some software, the
domain model can be
used to put it through
acceptance testing.
• Users and customers
will evaluate it and see
if it’s good enough for
them as it fits their
requirements.

The domain knowledge should be like a
contract stating all the goals that we need
to achieve. This is a list of all the
architecturally significant requirements.
If they’re not architecturally significant,
they are second-order requirements. You
can give them directly to the developers,
as they won’t affect the architecture.

Case Study
➢ If you would architect an application for a bank, you would need to interact
with the foreign exchange desk of the finance department. With your IT
background, you probably do not grasp most of the concepts of how
currency markets work.
➢ Your goal is to discover what is relevant to your domain model. Collect
working definitions of data items, clarify the lifecycle of the main objects, and
know what information is supposed to be captured so that you have a clear
picture of what you are supposed to do with it as you design the application.
➢ In the same way, you do not complete the design process instantaneously,
you cannot discover and learn everything about the domain model in one
shot. It’s a gradual process, which – as we discussed before – goes hand in
hand with the design.

Example: Domain Model
The software: Music Player
✓ Music songs are organized in albums
✓ The same song can be authored by many
artists
✓ Listening to each song costs 0.99 $, but short
samples can be heard for free
✓ Songs can be downloaded and also live
streamed
✓ Songs are stored in files of standard MP3
format

Design Model
➢ Refutable truths about your system
➢ Within your control
➢ Prescriptive: Your system will be built based on it
➢ Descriptive: Your system is represented by it
➢ Interfaces (externally visible behavior, data
interchange)
➢ Quality Attributes (how to achieve them)
➢ Structural decomposition, component assembly
➢ Define shared vocabulary and understanding within
the development team

Example: Design Model,
Interfaces
➢ Streamed songs should begin to
play after a max delay of 5
seconds
➢ Payment messages should be
transferred with an encrypted
standard protocol
➢ Songs are stored in files of
standard MP3 format
➢ Playlists cannot be modified while
they are being played
Example: Design Model,
Implementation
➢ Playlists are programmed as a
double-linked list
➢ The playback thread should
have a high priority
➢ Sound decoder component
built with a MP3 library
➢ Payment messages should be
validated before processing
them

Domain Modeling Notations
➢ Use Case Scenarios
➢ Feature Models
Modeling Notations
Design Modeling Notations
➢ C4: Context, Containers,
Components, Classes
➢ 4+1: Logical, Process,
Development, Physical (and Use
Cases) How

Use Case Scenarios
& Feature Models

Domain Modeling Notation: Use Case Scenarios
The model of the architecture can be broken down in scenarios,
each illustrated using the other views.
Scenarios help to ensure that the architectural model is
complete with respect to requirements
Scenarios can be prioritized to help drive the development of
the system (most critical for success, most expensive to build,
most useful, most risky) according to different stakeholders
Expectations.

Example Music Player Scenarios
▪ Browse for new songs
▪ Search for interesting songs
▪ Play the song sample
▪ Pay to hear the entire song
▪ Download the purchased song on the device
▪ Play the song
▪ Play multiple songs on a predefined playlist
▪ Play multiple songs in random order
▪ Share songs with friends
▪ Make a backup of the device's content
▪ Suggest related songs
▪ Display album cover image

Case Study:
Software
Architecture and
Design: Note Taking
App

Note taking Application

Functional Requirements
➢ We need to build a note-taking app.
➢ Users can create and edit text-based
notes. A note may also include images or
hand-drawn sketches.
➢ Sensitive notes should be protected
from prying eyes using a password.
➢ The app automatically uploads changes to
pre-configured servers. We should
support all major platforms: Dropbox,
iCloud and Google Drive.

Non-functional Requirements
➢ Release our app for iOS first. We'll support
iOS 14 and iOS 15 versions.
➢ The app needs to run on the iPhone and the
iPad and Apple Mac computers well.
➢ We will create a dedicated support web site
and we'll also include the link in the app's
description and it’s "About" page.

Epics or multiple user stories that describe
common functionality.
Epic number one: "Note creation and
editing".
1. As a user, I want to create and edit notes
so that I can quickly jot down my
thoughts.
2. As a user, I want to attach photos to a
note so that I can keep my memories in
one place.
3. As a user, I want to add handwritten
sketches so that I can insert funny toons
into my notes.

Epic number two: "Privacy".
As a user, I want to create private notes so
that only I can access them.
As a user, I want to protect my sensitive notes
with a password.

Epic number three: "Sync'ing to Cloud
Server".
1. As a user, I want to sync my notes across
my iOS devices, so that my data is up-to-
date on all of them.
2. As a user. I want my notes automatically
uploaded to cloud servers (Dropbox, Google
Drive or iCloud), so that I have a backup of
all my data.

Let’s go ahead and map these user
stories to actual use cases.

Use Case Diagram
The actor is the user of this app.
Next, I add the use-cases: “Create
Note” and “Edit Note”.
Epic #1: Note creation and
editing
-As a user, I want to create
and edit notes so that I can
quickly jot down my
thoughts.
(next slide)
- As a user, I want to attach
photos to a note so that I
can keep my memories in one
place.
- As a user, I want to add
handwritten sketches so
that I can insert funny
drawings into my notes.

We also need an “Attach Photo” and
“Add Handwritten Sketch” use case.
Now, these are not standalone use-
cases. We can’t attach a photo or add a
handwritten sketch without creating or
editing a note. Thus, I represent them
as included in the “Create Note” and
“Edit Note” use-cases.

We need an actor; it’s the user as usual. The creation of
private notes is a special case of note creation. We can
represent the “Create Private Note” as an extension of
the regular “Create Note” use-case.
Epic #2: Privacy -
Protecting User Data -
As a user, I want to
create private notes so
that only I can access
them.
- As a user, I want to
protect my sensitive
notes with a password.

The third epic is about synchronizing data with a server.
This server is another actor, a non-human one. W’ll
represent it on the right side of the diagram using this
special format.
Epic #3: Syncing to cloud
servers - As a user, I want to
sync my notes across my iOS
devices so that my data is up-
to-date on all of them. - As a
user, I want my notes
automatically uploaded to
cloud servers (Dropbox,
Google Drive or iCloud) so that
I have a backup of all my data.

Use-
Case
Diagram

Domain Model: Feature Models
➢ Decompose complex functional or extra-functional
requirements into features (required vs optional)
➢ Represent valid feature combinations for product lines
➢ Constrain the set of all possible products and control
feature interactions
➢ Determine which feature configuration is found in an
actual product
➢ Compare competing products (commodity vs
differentiating features)

Example: Feature Model

Feature Model Constraints

Example: Constrained Feature Model

Example: Feature Configuration

C4 Model

Design Model: Context-Container-Component-
Code (C4 Model)
➢ It is a meta-model for representing the structure of a software
architecture.
➢ It uses a hierarchical representation where you start from the
outside (representing the context) and then refine it into the runtime
environment with the containers, inside which you deploy components.
➢ What’s the next level of granularity? What do you find inside
components? Classes. This is where we start to program the code,
whose fine-grained structure – for some object-oriented programming
languages – can be represented using class diagrams.

1. Context: A System Context diagram provides a starting
point, showing how the software system in scope fits into
the world around it.
2. Containers: A Container diagram zooms into the software
system in scope, showing the high-level technical building
blocks (containers) and how they interact.
3. Components: A Component diagram zooms into an
individual container, showing the components inside it.
4. Code: A code (e.g. UML class) diagram can be used to
zoom into an individual component, showing how that
component is implemented. Simon Brown
www.structurize.com
Design Model: Context-Container-Component-
Code (C4 Model)

Static Structure
A software system is made up of
one or more containers (web
applications,
mobile apps, desktop applications,
databases, file systems, etc), each
of which contains one or more
components, which in turn are
implemented by one or more code
elements (e.g. classes, interfaces,
objects, functions, etc). And people
use the software systems that we
build.

www.structurizr.com

C4 model

Components: Zoom and filter
As developers, we often need more detail, so we’ll then zoom into each
(interesting) container in turn and show the “components” inside it.
This is where we show how each application has been decomposed into
components, along with a brief note about key responsibilities and
technology choices of those components.
Hand-drawing the diagrams can become tedious, which is why sometimes
you should ideally look at tooling (DSL for example) to help automate it
instead.

Code: Details on demand
We might optionally progress deeper into the hierarchy to
show the code-level elements (e.g. classes, interfaces,
objects, functions, etc) that make up a particular component.
Ultimately though, this detail resides in the code and, as
software developers, we can get that on demand
via our IDEs.

➢ Successful software has millions of users, so
you do not want to list all of them in your model,
but somehow abstract the types of targeted
user (or persona): These are the skills that I
imagine for this user, the needs that the user
has, their requirements to be satisfied.
➢ The users in the context are directly connected
to the use case scenarios that you already have
elicited in the domain model.

System Context View

System Context View
➢ User roles, personas - who do you expect will use the
system?
➢ Are the users all the same? How many users can share
the system at the same time?
➢ Dependencies - which external systems need to be
integrated with the system? are there some open API
that let other (unknown or known) systems interact
with the system?

Let’s look at the context of the music player example.
➢ We have customers who listen to the music, but we also have artists
that provide the content.
➢ By itself, the player is useless unless there is a reliable supply of
music.
➢ What is the incentive for artists to create it unless consumers can
reward them with their attention and their wallets?
➢ Listeners buy music through the system. Now if you want artists to
make money with it, and you as a middleman to take a reasonable cut,
you need to rely on some kind of existing payment system.

Level 1: System Context diagram
A System Context diagram can be a useful
starting point for diagramming and documenting
a software system, allowing you to step back
and look at the big picture.
Intent
A System Context diagram helps you to answer
the following questions.
1. What is the software system that we are
building (or have built)?
2. Who is using it?
3. How does it fit in with the existing
environment?
Motivation, Why it’s useful:
▪ It makes the context and
scope of the software system
explicit so that there are no
assumptions.
▪ It shows what is being added
(from a high-level) to an
existing environment.
▪ It’s a high-level diagram that
technical and non-technical
people can use as a starting
point for discussions.
▪ It provides a starting point for
identifying who you potentially
need to go and talk to as far as
understanding inter-system
interfaces is concerned.

Structure
➢ Draw a block diagram showing your software system as a box in the
center, surrounded by its users and the other software systems that
it interacts with.
➢ Detail isn’t important here as this is your zoomed-out view showing a
big picture of the software system and the immediate world around it.
➢ The focus should be on people (actors, roles, personas, etc) and
software systems rather than technologies, protocols and other low-
level details.
➢ It’s the sort of diagram that you could show to non-technical people.

Example:
This is a System Context diagram for
a fictional Internet Banking System.
It shows the people who use it,
and
the other software systems that the
Internet Banking System has a
relationship with.

Elements of System Context Diagram
People
These are the people who use your software
system. Whether you model them as individual
people, users, roles, actors or personas is your
choice. Typically we’ll capture the following
information about people:
Name: The name of the person, user, role,
actor or person.
Description: A short description of the person,
their role, responsibilities, etc.

Elements of System Context Diagram, cont.
Software systems
These are the other software systems that your software system interacts with. Typically
these software systems sit outside the scope or boundary of your own software system, and
you don’t have responsibility or ownership of them.
Note:
The Internet Banking example is very clear in this respect. As a team building the Internet
Banking System, we don’t own or have any responsibility over the bank’s existing
Mainframe Banking System, or the E-mail System. For this reason, they are included on the
diagram to illustrate that they are dependencies of the Internet Banking System, and not
something we are building ourselves.
We’ll capture the following information about each software system:
Name: The name of the software system.
Description: A short description of the software system, its responsibilities, etc.

Enterprise boundary
Optionally, we may want to capture some
information about the location of people
and/or software systems relative to my point
of reference.
If we are building a software system inside an
organizational/enterprise boundary, that
software system may interact with people and
software systems outside that boundary. In
this slightly modified example, the dashed line
represents the boundary of the bank, and is
used to illustrate what’s inside vs what’s
outside of the bank.

Interactions
Try to annotate every interaction between
elements on the diagram with some
information about the purpose of that
interaction.
This avoids creating a diagram where a
collection of boxes are somehow connected
via a set of ambiguous lines. Again, try to
keep this relatively high-level, and don’t feel
that you need to include lots of technical
details (e.g. protocols, data formats, etc).

➢ Audience: Technical and non-technical
people, CEO, CIO, CTO, inside and
outside of the immediate software
development team, product owner,
project manager
➢ Required or optional? All software
systems should have a System Context
diagram.

Level 2: Container Diagram
Container View
➢What are the main logical execution
environments in which the system can run?
➢Containers can be deployed separately and
independently evolved

Container diagram
Once you understand how your software system fits in to
the overall environment with a System Context diagram,
a useful next step is to illustrate the high-level
technology choices with a Container diagram.
Intent:
A container diagram helps you answer the following
questions:
1. What is the overall shape of the software system?
2. What are the high-level technology decisions?
3. How are responsibilities distributed across the
system?
4. How do containers communicate with one another?
5. As a developer, where do I need to write code in order
to implement features?
Motivation, Why it’s useful:
Where a System Context
diagram shows your software
system as a single box, a
Container diagram opens this
box up to show what’s inside it.
This is useful because:
▪ It makes the high-level
technology choices explicit.
▪ It shows the relationships
between containers, and how
those containers
communicate.

Structure
Draw a block diagram showing the high-level
technical elements (containers) that your
software system consists of.
How much detail?
If you’re drawing a Container diagram during
an up-front design, you might not have some
of the technical details to hand. That’s fine,
just add what you know.
If you’re drawing a diagram to document an
existing system, it’s more likely that you’ll be
able to add some of the finer details; such as
protocols, port numbers, etc. The choice is
yours, add as much detail as you feel is
necessary.

Example Containers
➢Server-side Web application
➢Client-side Web application
➢Client-side desktop application
➢Mobile app
➢Server-side console application
➢Shell script
➢Microservice
➢Data store (Database, file system, Key-
value, Blob, content, delivery network)

Example:
Container diagram
for an Internet
Banking System.

Elements of container
A container diagram usually includes three types of
elements; people, software systems and containers.
Containers
A container typically represents an application or data
store. W’ll capture the following information about each
container:
Name: The name of the container (e.g. “Internet-facing
web server”, “Database”, etc).
Technology: The implementation technology (e.g. Spring
MVC application on ApacheTomcat 8, ASP.NET web
application on Microsoft IIS 8.5, etc).
Description: A short descriptive statement, or perhaps a
list of the container’s key responsibilities or
entities/tables/files/etc that are being stored.

File systems and log files vs data storage
If we are describing a software system where an application stores business critical data
on a file system, we will include a “File System” container on the diagram, to make this
explicit. In contrast, although many types of containers will write log files to a file system
(and this is undoubtedly important).
Data storage as a service
A frequently asked question is whether services like Amazon S3, Amazon RDS, or Azure
SQL Database should be shown on a container diagram. After all, these are external
services that we don’t own or run ourselves. If you’re building a software system that is
using Amazon S3 for storing data, it’s true that you don’t run S3 yourself, but you do have
ownership and responsbility for the buckets you are using. Similarly with Amazon RDS, you
have (more or less) complete control over any database schemas that you create. For this
reason, I will usually show such containers on a container diagram. They are an integral part
of your software architecture, although they are hosted elsewhere.

Elements of container, cont.
People and software systems
If you look back at the example Container diagram, you’ll
notice that it has the same people and software systems
as the example System Context diagram.
We usually include the same collection of people (users,
actors, personas, etc) and software systems because it
helps to tell the overall story of how the system works
and it provides continuity between the two diagrams.
In effect, a container diagram is very similar to the
System Context diagram, where you’re zooming in to see
what’s inside the software system in scope.

Software system boundary
With this in mind, I recommend drawing
a bounding box around the containers on
your diagram to explicitly show the
system boundary. This system boundary
should correspond with the single box
that appears on the System Context
diagram.

Interactions
Typically, communication between containers is out-of-process (or inter-process). It’s
very useful to explicitly identify this and summarise how these interactions will work.
As with any diagram, I recommend annotating all interactions rather than having a
diagram with a collection of boxes and ambiguous unlabelled lines connecting everything
together.
Useful information to annotate the interactions with includes:
➢ The purpose of the interaction (e.g. “reads/writes data from”, “sends reports to”, etc).
➢ The communication mechanism (e.g. Web Services, REST, Web API, Java Remote
Method Invocation, Windows Communication Foundation, Java Message Service).
➢ The communication style (e.g. synchronous, asynchronous, batched, two-phase commit,
etc).
➢ Protocols and port numbers (e.g. HTTP, HTTPS, SOAP/HTTP, SMTP, FTP, RMI/IIOP,
etc).

Audience
Technical people inside and outside of the
immediate software development team; including
everybody from software developers through to
operational and support staff.
Required or optional?
All software systems should have a Container
diagram.

Level 3: Component diagram
Component View
➢ What is the structural decomposition of the software
with related functionality encapsulated behind a well-
defined interface?
➢ What are the dependencies between components?
➢ Are there shared components that will be deployed in
multiple containers?
➢ What is the technology used to build the components?
(programming languages and framework decisions)

Level 3: Component diagram
Following on from a container diagram showing the
high-level technology elements, the next step is to
zoom in and decompose each container further to
show the components inside it.
Intent
A Component diagram helps you answer the
following questions.
▪ What components is each container made up of?
▪ Do all components have a home (i.e. reside in a
container)?
▪ It is clear how the software works at a high-
level?
Motivation
A Component diagram shows the
components that reside inside an individual
container. This is useful because:
▪ It shows the high-level decomposition
of a container into components, each
with distinct responsibilities.
▪ It shows where there are relationships
and dependencies between components.
▪ It provides a high-level summary of the
implementation details, including any
frameworks or libraries being used.
▪ If the components shown on the
diagram can be explicitly mapped to the
code, you have a good way to really
understand the structure of a
codebase.

How much detail?
If you’re drawing a component diagram during an up-front design, you might
not have some of the technical details to hand. Once again, don’t worry, add
what you know.
If, on the other hand, you’re drawing a diagram to document an existing
system, you’ll have those finer details to hand; such as the frameworks you
are using to help implement a component. As with many other aspects of the
diagrams, the choice of how much detail to include is yours.

Elements of Component Diagram
A Component diagram can include four types of elements;
people, software systems, containers and components.
Components
Components are the coarse-grained building blocks of your
software system that live inside of a container. We’ll
capture the following information for each component:
Name: The name of the component.
Technology: The implementation technology for the
component (e.g. Plain Old [Java|C#|Ruby|etc] Object,
Enterprise JavaBean, Windows Communication Foundation
service, etc).
Description: A short description of the component, usually
a brief sentence describing the component’s
responsibilities.

Elements of Component Diagram, cont.
People, software systems and containers
As with the container diagram, it can be useful to
include people, software systems and other
containers to help put some context around the
container you’ve zoomed in upon.
Container boundary
If you’re going to include people, software systems
and containers on a Component diagram
(and, again, you should), I recommend drawing a
bounding box to explicitly show the
boundary of the container.

Example

Audience
Technical people within the software development team.
I don’t typically draw a Component diagram for data storage containers (e.g.
databases,file systems, content stores, etc), or for those containers that are very
simple in nature (e.g. microservices). For monolithic applications, you might consider
creating a Component diagram, especially during an up-front design process.
In real world use, many teams find this an optional level of detail for long-lived
documentation, because of the potentially high degree of effort involved in creating
the diagrams, and keeping them up to date. Also, once you have more than a handful
of components, you’ll find that the diagram starts to get very cluttered very quickly,
which reduces the usefulness of the diagram.

Level 4: Code-level diagrams
The final level of detail is one or
more code-level diagrams showing the
implementation details of an
individual component.
Intent
The intent of a code-level diagram is
to illustrate the structure of the
code and, in this case, how a
component is implemented.
Motivation
Having this final level of
abstraction provides a way to
map the high-level, coarse-
grained components into real-
world code elements.
It helps to bridge what are
sometimes seen as two very
different worlds; the
software architecture and the
code.

Structure
If you’re using an object oriented
programming language, probably the best
way to do this is to use a UML class
diagram, either by generating it
automatically from the code or by
drawing it freehand.

Audience
Technical people within the software development
team, specifically software developers.
Since this level of detail lives in the code,
software developers can get this detail on demand
from the code itself. Therefore, this is definitely
an optional level of detail, and generally not
recommended.
We don’t typically draw class diagrams for
anything but the most complex of
components, or as a template when we want to
describe a pattern that is used across a codebase.

Example:
Let’s look at an example by zooming in
on the “Mainframe Banking
System Facade” component from the
Internet Banking System “API
Application” container.

Notations
1. Titles
2. Keys and legends
3. Elements
4. Description/Responsibilities
5. Color
6. Shape

Examples of Notations
Titles
Include a short and meaningful title on every diagram, I also recommend including the
diagram type in the title. For example, something like:
➢ System Context diagram for Financial Risk System
➢ [System Context] Financial Risk System
Keys and Legends
There’s nothing wrong with inventing your own notation, but make sure that you give
everybody an equal chance of understanding it by including a key/legend somewhere on
or nearby the diagram. Here are the things that you might want to include explanations of:
➢ Shapes
➢ Line styles
➢ Colours
➢ Borders
➢ Acronyms

You can often make assumptions and
interpret the use of diagram elements
without a key. For example, for example I
can imagine that:
“the grey boxes seem to be the existing
systems and the blue boxes are the new
systems”

Notation, Example
Adding more text onto diagrams
can help provide a really useful “at
a glance” view of what the
software system does and how it’s
been structured.

Example
AutoCab application
Context
AutoCab which is in traditional Taxi business (where
Taxi can booked by calling call center) now wants to
expands its business to self driving Taxi’s
Once these self driving taxi’s are launched
customer can do a taxi booking via AutoCab web or
mobile application.
The self driving taxi will confirm the trip, will pick
up the customer and once trip is finished and
customers pays online, The tip is considered as
complete and taxi is ready for next pick up.

Requirements
AutoCab expects the application to be up 24*7.
➢ Self driving Taxis is going to generate loads
of data, and these data need to be analysed
for performance, engine health
➢ The application should be able to handle
millions of customers
➢ All the transactions need to be in secure
manner.
➢ All Transactions need to be Audited

Additional Info
➢ AutoCab wants to launch the application in a one city
first and plan to expand rest of the country by end of
the year.
➢ Support Push capabilities of messages and updates to
Customer application and Self Driving taxi.
➢ The user interface of application should be
straightforward and simple to use.
➢ The Payment is using an existing gateway system.
➢ Funding is not problem , VC’s are exited with this idea
, so budget is not a constraint.

Context Diagram
A context diagram
helps stakeholders
understand where
the software system
fits in the world.

Container Diagram

Software isn’t static though and needs to be executed
in order to actually do something useful. For this
reason, it can be useful to create diagrams that
illustrate what happens at runtime (a “dynamic view”)
for important use cases, user stories or scenarios. To
do this, we simply take the concept of sequence and
collaboration/communication diagrams from UML and
apply them to the static elements in the C4 model.

Example: Music Player System
The context of the music player
➢ We have customers who listen to the music, but we also
have artists that provide the content.
➢ By itself, the player is useless unless there is a reliable
supply of music.
➢ What is the incentive for artists to create it unless
consumers can reward them with their attention and
their wallets?
➢ Listeners buy music through the system. Now if you want
artists to make money with it, and you as a middleman to
take a reasonable cut, you need to rely on some kind of
existing payment system.

The context of the music player, cont.
➢ Typically you would not usually come up with your own cyber
currency for a music player application. Unless you want to keep
the system self-contained. If so, you will end up implementing
many more use cases related to securing financial transactions,
tracking exchange rates, filing tax returns, and safeguarding
against double spending than originally planned.
➢ In terms of use case scenario prioritization, this context
diagram indicates that there will be competing interests. The
artist want to make money and they have to upload the content
and the customer will then download the content, listen to it
and pay for it.

System Context View

The Container of the Music Player
➢ Here we focus inside the box and we start to
decompose the system from the runtime environment
point of view.
➢ Before we can talk about the actual software we need
to talk about the hardware on which it will run.
➢ Before we can think of what programming language are
we going to use, we need to decide: How many containers
are we going to need? To answer it, we need to compose
the runtime environment out of different types of
containers in which we can pour our software and our
data.

The Container of the Music Player, cont.
➢ The term container has a technical connotation, but we
define it as an architectural concept, Containers are
separate units of deployment that can be
independently evolved.
➢ How do you know if you have separate containers? You
can start or stop them independently. When one is
running, the other may not necessarily have to be.

x
System Container View

x
The Components of the Music Player
➢ The software architecture has a structural
decomposition, which uses more than one piece as every
component encapsulates different functionality, and
different states, and makes it accessible through a
well-defined interface.
➢ Components are also related to each other. They need
each other. They establish complex relationships. One
component will call the other one. Another pair will
share and exchange data.
➢ Do you put multiple components in the same container?
or do you have a super simple solution where within each
container you deploy exactly one component?

➢ Once you have a structural decomposition of logical components, you can start to
decide which language are you going to use to program them. Should all of the
components be written in the same language? or each component in a different
language? or polyglot components, with multiple languages within the same
component?
➢ The language decision depends on if you have access to developers that can write
code in different languages or all developers that you have only speak the same
language, so there is no alternative to consider.
➢ Once you pick the language for a component, then you can pick the corresponding
framework, libraries, compilers, and development tools. Or maybe you don’t have to
write the component at all. Instead of coding it from scratch, you can recycle
existing code or just buy an existing reusable component.

System Container View

Connectors View (C5 or C4+1)
➢ How are component interfaces
interconnected?
➢ What kind of connector(s) are
chosen?
➢ What is the amount of coupling
between components?
➢ These decisions may depend on the
deployment configuration

4+1 View Model

Link:
https://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-architecture.pdf

Slide Revisiting

The need for more than one view
Imagine you are a software engineer working to
create a piece of software for a client.
➢ Your client already has an idea in mind that the
software has a certain purpose. But other
than the purpose, the software may be
implemented any way you decide.
➢ In order to assess the success of your
software, it must have certain features, and
that can be determined in certain ways.

Software Project Stakeholders
➢ Customer (End User)
➢ Programmer (Developer)
➢ Management team
➢ System Engineer
➢ Product Manager
➢ Tester, … etc.
A single representation of an architectural view ( an
aspect of information) of an application cannot meet
the eyes of all associated various skilled
stakeholders.

For me, as a softwareman, the fundamental
organization of a software system can be
represented by:
➢ Structural elements and their interfaces
that comprise or form a system
➢ Behavior represented by collaboration among
the structural elements
➢ Composition of Structural and Behavioral
elements into larger subsystems
But this is not for all stakeholders.
Software Architecture is the
fundamental organization of a
system, embodied in its
components, their relationships to
each other and the environment,
and the principles governing its
design and evolution.
IEEE definition

Architecture means different things to different stakeholders.
For example,
➢ A Network Engineer would only be interested in the hardware
and network configuration of the system.
➢ A Project Manager would only be interested in the key
components to be developed and their timelines.
➢ A Developer would only be interested in classes that make up a
component.
➢ A tester would only be interested in scenarios.
So we need multiple views for distinct stakeholders’ needs,
showing what is relevant while masking the details that are
irrelevant.

1. Logical View
To represent the structural decomposition of the architecture in
components and determine their dependency relationships. Architects
use this view for functional analysis.
➢ Logical View captures the functional requirements of the application
as decomposition of structural elements or abstractions.
➢ Elements Decomposition is the art of decomposing the application
behaviour into classes and package.
UML Class Diagrams and UML Package Diagrams, C4 Component
Diagrams can be used to represent classes and packages
respectively.

How are we going to represent the logical view?
➢ We have a logical view with different
components.
➢ Usually components have a name and the name
should mean something in relation to their
purpose.
➢ The components on the left are disconnected
because there is no relationship between them.
➢ Pairs of components can also be connected
together. The simplest type of connection is just
shown by drawing a line between them. So, in
this case, the components on the right are
connected.

How are we going to represent the logical
view?
Can we make the dependency relations more
precise? Yes, if we establish some kind of
asymmetric direction between the two
components.
One component offers access to his services to
another component that needs them, that is
dependent on them. As you can see the edge, the
edge that we have on the right is drawn using
these shapes. So we say that a component
provides an interface for the rest of the world to
reuse and to integrate with, and you have a
component that is dependent on this interface
that requires it to work correctly.

Depending on the type of connector, you can
expect at runtime one component is going
to call the other. Or when you build the
system, you need to get the dependencies and
link them together with the component it
needs them.
Two components connected need
each other to properly function.
Components disconnected or independent are
without any coupling: For example, if you
change component zero, since it is
disconnected, the other components will not
be affected.

Modelling Logical View With UML
1. Start with class diagrams to model the
component.
2. Use package diagrams to logically group
diagrams.
Optional use
3. Object diagrams when relationships
between classes need to be explained
through instances.
4. State Charts when internal states of a
specific class are to be explained
5. Composite Structures when parts of a class
and relationships between parts are to be
modelled.

Example: The Music Player
➢ We have a song repository where we store all the songs. We have the player itself, responsible for
transforming the bits into the music that you listen to. There is a connection between them because
of the use case scenario ”play the song”: the player has to fetch the MP3 data from the song
repository.
➢ We also have the user interface which will provide access to the user to control what the player is
doing. Also, the UI needs to find the metadata about the songs so the user can for example search
or browse them and select which one they want to play. This is why we have these two connections.
So this will be sufficient for satisfying the use case where the user can manage his own music and
listen to it.
➢ However, there is another type of user – the artists – who want to make money with this system and
therefore the song cannot start playing unless the user paid for them.
➢ In this case we also introduce a customer database component which keeps track of the access
rights: which songs can be played for which user. In case the user wants to buy a new song, it will
transfer the payment credit card information to a payment service to charge the user for
downloading a certain song.

Example: The Music
Player: Logical View

➢ When you are about to draw a new box, ask yourself these questions:
▪ What is the purpose of the component?
▪ To which use case, to which functionality does it correspond?
➢ And then You should keep a mapping between the requirements and components,
where the domain drives your design decisions.
➢ The main concern for the logical view is to make sure that you have a correct and
complete system when it comes to fulfilling the requirements.
➢ The main audience for this type of view are developers who should understand the
structure of the system, but also the users they might want to make a choice of
which component they want to actually deploy.

➢ UML also provides profiles for data
modelling using Entity Relationship
(ER) Diagrams.
➢ ER Diagrams can also be considered as
another form of Logical View. Some
Architects prefer to capture ER
Diagrams in a separate view called
Data View.

2. The Process View
➢ Models the dynamic aspects of the architecture.
➢This view considers non-functional aspects such as performance,
concurrent threads, scalability and throughput.
➢A software system is partitioned into sets of tasks. Each task is a
thread of control that executes with collaboration among different
structural elements (from the Logical View).
➢Process View also encompasses re-usable interaction patterns to solve
recurring problems and to meet non-functional service levels.

Modelling Process View With UML
1. Use either Sequence or Communication Diagrams
for modelling simple interactions in use case
realizations.
Optional use
2. Add Activity diagrams to realize scenarios
where business logic is a sequence of actions and
involves branching and parallel processing.
3. Add timing diagrams when modelling for
performance .

Example: Music Player,
Process View

3. Development (implementation) View
➢ This view focuses on actual software module
organization in the development environment.
The software is actually packaged into
components that can be developed and tested
by the development team.
➢ For example you can decide: which kind of
software code artifacts are you going to have?
which kind of programming languages will you
write the component in? in which repository
you store the code? will you create a dedicated
IDE project for each component?

3. Development View
➢ Component Diagrams and notes together are used to
represent the development View.
➢ These diagrams show different components, the ports
available and the dependencies on the environment in
terms of provided and required interfaces.
➢ As there is no standard notation to capture the decisions
that you make in the development view, Sometimes we just
use sticky notes to associate the decisions with the various
components. You can also just write these notes down in a
spreadsheet.

➢ In this view, there are all decisions that impact how you’re
going to build the software and where you can run it.
➢ The more languages, the more repositories will make it more
complex the build process. Different languages will make it
more or less easy to deploy the result of the build in different
execution environments.
➢ Before planning how to develop and build each component, you
should decide whether you want to build it in the first place.
Maybe you can reuse a component that already exists. Some
components you don’t have to build at all, you just have to buy
them.

Example: Music Player, The development view

4. Physical View (Deployment view)
➢ Define the hardware environment (hosts, networks, storage, etc.) where the
software will be deployed.
➢ This view encompasses the nodes that form the system’s hardware topology on
which the system executes; it focuses on distribution, communication and
provisioning.
➢ This view accommodates the non-functional requirements such as availability,
reliability, performance, throughput and scalability.
➢ This view provides all possible hardware configurations and maps the
components from the Development View to these configurations.
➢ Deployment Diagrams show the physical disposition of the artefacts in the
real-world setting.

4. Physical View (Deployment view)

➢ The deployment view is the connection between the logical view, listing
the components that you have and where do you want to place them in the
given physical view.
➢ The deployment view is more interesting: there you have to decide where
to deploy and run each of your logical components.
➢ However, if the data that we need to play is far away, we have a problem,
because there might be some lag or there might be some gaps in the
playback. So to improve that aspect we make a decision to keep a local
copy of the song repository. So in this case we need to duplicate a
component which is a single one from a logical point of view, but it gets
instantiated twice when we deploy it. We decide to make a copy of two
instances of this component. One will store a cache of the music and the
other one will store the whole dataset. So we introduce partial replication
of the data.

5. Scenarios (putting all together)
The scenarios view encompasses the use cases that
describe the behaviour of the system as seen by its
end users and other stakeholders.
Although traditionally discussed as the last view,
this is the first view created in the system
development lifecycle.
This view represents the scenarios that tie the four
views together, and forms the reason why all the
other views exist.
UML provides the Use Case Diagrams to represent
this view. Activity Diagrams can also be used to
represent scenarios and business processes.

4+1 model view and UML
diagrams

➢ The Logical View and the Process View are at a conceptual level
and are used from analysis to design.
➢ The Development View and the Deployment View are at the
physical level and represent the actual application components
built and deployed.
➢ The Logical View and the Development View are tied closer to
functionality. They depict how functionality is modelled and
implemented.
➢ The Process View and Deployment View realize the non-
functional aspects using behavioural and physical modelling.

Final remarks, cont.
➢ Use Case View leads to structural elements being
analysed in the Logical View and implemented in the
Development View. The scenarios in the Use Case
View are realized in the Process View and deployed
in the Physical View.
➢ Architects have additional diagrams to model the
functional and non-functional aspects and
communicate them to the teams. Typically, the views
in the 4+1 View approach are sufficient to model the
Application Architecture. Additional views such as
Security View and Data View could be added based
on the specific application’s requirements.

Example: Logical View Using plantUML

Example: Process View Using plantUML

Example: Deployment view Using plantUML

User Interface (UI)

User Interface (UI) and User Experience (UX)
Note: Chapter IV is an overview of UI design, self
study part

Content is more important
than representation
➢ No matter which notation and how many viewpoints you use, what is really
important are the decisions that you make, whether they are correct and it
doesn’t matter as much the way that you represent them.
➢ You should learn how to think about your software architecture, how to design
it, how to reason about the implications of your decisions. Pick the
representation which doesn’t get in your way while doing so.
➢ Pick the most suitable representation so you can clearly communicate your
decisions with it.
➢ Make the right decisions, but do not worry if the notation that you use to
capture them is not standard. If the notation is understandable by the people
whom you want to communicate your decisions with, then this is enough.

Model Quality
Ambiguity
▪ A model is ambiguous if it leads to more than one
Interpretation.
▪ Incomplete models can be ambiguous: different
people will
▪ Fill in the gaps in different ways.
Accuracy
▪ A model is accurate if it is correct, conforms to
the fact, or deviates from correctness within
acceptable limits.
Precision
▪ A model is precise if it is sharply exact or
clearly delimited.

Model Quality – Advice
➢ Make sure your architecture is accurate (a wrong,
inconsistent or conflicting architectural decision
is a recipe for disaster)
➢ Sometimes you can even make it complete (but it
will be more expensive, so only do it for a critical
aspect of the system)
➢ Precision helps, but avoid over-specifying and
over-designing the architecture, especially if the
architecture is inaccurate,
➢ adding details will not fix it. (developers may be
trusted to add missing details)

Resources
1. Simon Brown, 2022. The C4 model for visualizing software architecture, Lean
publishers.
2. Joseph Ingeno, 2018. Software Architect's Handbook, Packt Publishing.
Website:
https://philippe.kruchten.com
Watching list:
https://www.youtube.com/watch?v=yp2-
_YbCuyM&list=PLKY5eEvz9PTh9xMPMDlouYEoRCTrfbj2I

Questions?

SoftwareArchitecture-Ch-3-v4.pdf

Recommended

Recommended

More Related Content

Similar to SoftwareArchitecture-Ch-3-v4.pdf

Similar to SoftwareArchitecture-Ch-3-v4.pdf (20)

Recently uploaded

Recently uploaded (20)

SoftwareArchitecture-Ch-3-v4.pdf