Design Patterns

A good class is a lot like an iceberg: seven-

eights is under water, and you can see only the
one-eight that’s above the surface.

Tempus
McConnell
Course Plan till the end of the semester

Notes:
• Week#13&14 will cover Service-
Oriented Engineering and Service-
Oriented Architecture(SOE/SOA)-
Sommerville Ch18.

• Quiz#2 will take place on Wednesday

Invited
21st of May from 13:00-13:45 at LH
Speaker 218. The quiz qualifies for 5 marks of
your course work
SOE/SOA D5 announ. D4
submission
• D5 will cover Component diagrams and
SOE/SOA Quiz#2 D5 Restful APIs (GET and POST)
submission

No Last day • There won’t be a lecture on Tuesday

Lecture of classes 27th of May (last week of classes)
Recall: Architectural Styles/Patterns

• The Model-View-Controller (MVC) pattern

• The Layered architecture pattern
• The Repository pattern
• The Client–server pattern
• The pipe and filter pattern
The Model-View-Controller (MVC) pattern
Name MVC (Model-View-Controller)

Description Separates presentation and interaction from the system data. The system is
structured into three logical components that interact with each other. The
Model component manages the system data and associated operations on
that data. The View component defines and manages how the data is
presented to the user. The Controller component manages user interaction
(e.g., key presses, mouse clicks, etc.) and passes these interactions to the
View and the Model. See Figure 6.3.
Example Figure 6.4 shows the architecture of a web-based application system
organized using the MVC pattern.
When used Used when there are multiple ways to view and interact with data. Also used
when the future requirements for interaction and presentation of data are
unknown.
Advantages Allows the data to change independently of its representation and vice versa.
Supports presentation of the same data in different ways with changes made
in one representation shown in all of them.
Disadvantages Can involve additional code and code complexity when the data model and
interactions are simple.
14/06/2025 Chapter 6 Architectural Design 5
The organization of the Model-View-Controller

14/06/2025 Chapter 6 Architectural Design 6

Web application architecture using the MVC pattern

14/06/2025 Chapter 6 Architectural Design 7

The organization of the Model-View-Controller: Three
layered

14/06/2025 Chapter 6 Architectural Design 8

What is the difference between MVC and Layered Architecture?
What is the difference between MVC and Layered Architecture?
What is the difference between MVC and Layered Architecture?
Architectural views

14/06/2025 Chapter 6 Architectural Design 12

4 + 1 view model of software architecture

A logical /conceptual view, which shows the key abstractions in the

system as objects or object classes.
A process view, which shows how, at run-time, the system is
composed of interacting processes.
A development view, which shows how the software is
decomposed for development.
A physical view, which shows the system hardware and how
software components are distributed across the processors in the
system.
14/06/2025 Chapter 6 Architectural Design 13
UML Models to represent system architectures

A logical /conceptual view -> Block diagrams

A process view -> Activity diagrams
A development view -> Component diagrams
A physical view -> Deployment diagrams

14/06/2025 Chapter 6 Architectural Design 14

Architecture Development View: UML Component Diagram

• One kind of structural diagram in UML that shows how the

components of a system are arranged and relate to one another is
termed a component-based diagram, or simply a component
diagram.
• System components are modular units that offer a set of interfaces
and encapsulate implementation.
• These diagrams illustrate how components are wired together to
form larger systems, detailing their dependencies and interactions.
• Component-Based Diagrams are widely used in system design to
promote modularity, enhance understanding of system architecture.

14/06/2025 16
Components of Component-Based Diagram:
Component

Represent modular parts of the system that

encapsulate functionalities. Components can be
software classes, collections of classes, or
subsystems.
• Symbol: Rectangles with the component stereotype
(«component»).
• Function: Define and encapsulate functionality,
ensuring modularity and reusability.

14/06/2025 Chapter 6 Architectural Design 17

Components of Component-Based Diagram: Interfaces

Specify a set of operations that a component offers or requires,

serving as a contract between the component and its
environment.
• Symbol: Circles (lollipops) for provided interfaces and half-circles
(sockets) for required interfaces.
• Function: Define how components communicate with each other,
ensuring that components can be developed and maintained
independently.

14/06/2025 Chapter 6 Architectural Design 18

Components of Component-Based Diagram: Interfaces

14/06/2025 Chapter 6 Architectural Design 19

Components of Component-Based Diagram: Relationships

• Symbol: Lines and arrows.

• Dependency (dashed arrow): Indicates that one component relies on another.
• Association (solid line): Shows a more permanent relationship between
components.
• Assembly connector: Connects a required interface of one component to a
provided interface of another.
• Function: Visualize how components interact and depend on each
other, highlighting communication paths and potential points of
failure.

14/06/2025 Chapter 6 Architectural Design 20

Components of Component-Based Diagram: Relationships

14/06/2025 Chapter 6 Architectural Design 21

Components of Component-Based Diagram: Ports

Role: Represent specific interaction points on the boundary of a

component where interfaces are provided or required.
• Symbol: Small squares on the component boundary.
• Function: Allow for more precise specification of interaction
points, facilitating detailed design and implementation.

14/06/2025 Chapter 6 Architectural Design 22

Components of Component-Based Diagram: Ports

14/06/2025 Chapter 6 Architectural Design 23

Components of Component-Based Diagram: Artifacts

Represent physical files or data that are

deployed on nodes.
• Symbol: Rectangles with the artifact
stereotype («artifact»).
• Function: Show how software
artifacts, like executables or data files,
relate to the components.

14/06/2025 Chapter 6 Architectural Design 24

Components of Component-Based Diagram: Nodes

Represent physical or virtual execution environments where

components are deployed.
• Symbol: 3D boxes.
• Function: Provide context for deployment, showing where
components reside and execute within the system’s
infrastructure.

14/06/2025 Chapter 6 Architectural Design 25

Steps to Create Component-Based Diagrams

Step 1: Identify the System Scope and Requirements

Define the boundaries: Determine what parts of the system will be
included in the diagram.
Step 2: Identify and Define Components
• List components: Identify all the major components that make up the
system.
• Detail functionality: Define the responsibilities and functionalities of
each component.
• Encapsulation: Ensure each component encapsulates a specific set of
functionalities.

14/06/2025 Chapter 6 Architectural Design 26

Steps to Create Component-Based Diagrams

Step 3: Identify Provided and Required Interfaces:

• Provided Interfaces: Determine what services or functionalities each
component provides to other components.
• Required Interfaces: Identify what services or functionalities each component
requires from other components.
• Define Interfaces: Clearly define the operations included in each interface.
Step 4: Identify Relationships and Dependencies:
• Determine connections: Identify how components are connected and interact
with each other.
• Specify dependencies: Outline the dependencies between components,
including which components rely on others to function.
14/06/2025 Chapter 6 Architectural Design 27
Steps to Create Component-Based Diagrams

Step 5: Identify Artifacts: Identify the physical pieces of information

(files, documents, executables) associated with each component.
Step 6: Identify Nodes:
• Execution environments: Identify the physical or virtual nodes where
components will be deployed.
• Define nodes: Detail the hardware or infrastructure specifications for each
node.
Step 7: Draw the Diagram using a UML tool
Step 8: Review and Refine the Diagram

14/06/2025 Chapter 6 Architectural Design 28

Example of Component Based Diagram

14/06/2025 Chapter 6 Architectural Design 29

Example of Component Based Diagram

OnlineStore Component: This is the main component encapsulating

the entire system. It includes three internal
components: Order, Customer, and Product.
Order Component: This component handles order-related operations
within the Online Store. It is connected to:
• The Product component (which likely manages details of products in each
order).
• The Customer component (for associating orders with customers).
• External access points via delegates (marked by <<delegate>> notation),
which indicate that certain internal actions can be routed to other parts

14/06/2025 Chapter 6 Architectural Design 30

Example of Component Based Diagram

Customer Component: This component manages customer-related

data and activities.
• It’s connected to the Order component to handle customer orders.
• The Account component (outside of OnlineStore) is connected
to Customer through a delegate, suggesting that customer-related actions
in OnlineStore might involve account information from another system.

Product Component: This component manages product-related

functions within the Online Store.
• It’s linked to the Order component, allowing orders to reference available
products.

14/06/2025 Chapter 6 Architectural Design 31

Example of Component Based Diagram

Account Component: This component is located outside

the OnlineStore boundary, indicating it may be a separate
system or module. It connects to Customer through a dotted line
with a delegate, showing that OnlineStore can delegate certain
account-related functions to this external Account component.

14/06/2025 Chapter 6 Architectural Design 32

Architectural views

14/06/2025 Chapter 6 Architectural Design 33

Architecture Physical View: UML Deployment Diagram

A Deployment Diagram is a type of Structural UML Diagram that

shows the physical deployment of software components on
hardware nodes. It illustrates the mapping of software
components onto the physical resources of a system, such as
servers, processors, storage devices, and network infrastructure.
This diagram helps visualize how the software will operate across
different devices
Key elements of a Deployment Diagram

• Nodes: Physical hardware entities where software components are deployed, such as
servers, workstations, routers, etc.
• Components: Represent software modules
• Artifacts: These can include executable files, scripts, databases, and more.
• Dependencies: Relationships or connections between nodes and components
• Associations: Show relationships between nodes and components
• Deployment Specification: This outlines the setup and characteristics of nodes and
components, including hardware specifications, software settings, and communication
protocols.
• Communication Paths: Represent channels or connections facilitating
communication between nodes and components and includes network connections,
communication protocols, etc.
UML Deployment Diagram: Component

A component represents a modular and reusable part of a system,

typically implemented as a software module, class, or package. It
encapsulates its behavior and data and can be deployed
independently.
UML Deployment Diagram: Artifact

An artifact represents a physical piece of information or data that is

used or produced in the software development process. It can
include source code files, executables, documents, libraries,
configuration files, or any other item.
UML Deployment Diagram: Interface

An interface defines a contract specifying the methods or operations

that a component must implement. It represents a point of interaction
between different components or subsystems.
Represented as a circle or ellipse labeled with the interface's name.
Interfaces can also include provided and required interfaces, denoted
by "+" and "-" symbols, respectively.
UML Deployment Diagram: Node

A node represents a physical or computational resource, such as a

hardware device, server, workstation, or computing resource, on
which software components can be deployed or executed.
Represented as a box with rounded corners, usually labeled with
the node's name. Nodes can also include nested nodes to
represent hierarchical structures.
UML Deployment Diagram: Communication path

A straight line that represents

communication between two device
nodes. Dashed lines in deployment
diagrams represents relationships or
dependencies between elements,
indicating that one element is related
to or dependent on another.
Use Cases of Deployment Diagrams

• Deployment diagrams help plan how software systems will be set up on

different devices.
• They help design the hardware needed to support the software. By showing
which software parts go where, they help decide what devices and networks
are needed.
• Deployment diagrams make sure each part of the software has enough
resources, like memory or processing power, to run well.
• They show how different parts of the software depend on each other and
on the hardware.
• By seeing how everything is set up, teams can find ways to make the
software run faster and smoother.
Steps for creating a Deployment Diagram

Step1: Identify Components

Step 2: Understand Relationships
Step 3: Gather Requirements: Collect details about hardware,
network setups, and any special rules for deployment.
Step 4: Draw Nodes and Components: Start by drawing the
hardware devices (nodes) and software parts (components) using
standard symbols roughly at first improvise it and draw the final
one.
Steps for creating a Deployment Diagram

Step 5: Connect Nodes and Components: Use lines or arrows to

show how nodes and components are linked.
Step 6: Add Details: Label everything clearly and include any extra
info, like hardware specs or communication protocols.
Step 7: Documentation: Write down any important decisions or
assumptions made while creating the diagram.
Deployment Patterns

• Deployment patterns are standardized methods for efficiently

installing software on hardware infrastructure.
• They offer guidance for organizing and deploying software
components, addressing challenges like scalability, reliability and
performance.
• Examples are: Three-Tier Architecture, Microservices
Architecture, Containerization (using Docker), Cloud Deployment
Deployment Diagram For Mobile Banking Android Services.
Deployment Diagram For Mobile Banking Android Services.

• In this example, one node represents the client’s Android device. The
components represent the software installed on these devices, with
the banking application being the specific component on the Android
device.
• The diagram also shows how the user connects to the banking server through
the web.
• This means the user opens the banking app on their Android device, which
then talks to the application server online to carry out tasks like checking
account balances or transferring money.
• Overall, the deployment diagram visually illustrates how software
components are set up on hardware nodes and how they interact to
provide the necessary functions to the user.
 Thank you for
your attention.

Tempus