What is a deployment diagram?

In the context of the Unified Modeling Language (UML), a deployment diagram falls under
the structural diagramming family because it describes an aspect of the system itself. In this
case, the deployment diagram describes the physical deployment of information generated by
the software program on hardware components. The information that the software generates
is called an artifact. This shouldn't be confused with the use of the term in other modeling
approaches like BPMN.

Deployment diagrams are made up of several UML shapes. The three-dimensional boxes,
known as nodes, represent the basic software or hardware elements, or nodes, in the system.
Lines from node to node indicate relationships, and the smaller shapes contained within the
boxes represent the software artifacts that are deployed.

Deployment diagram applications

Deployment diagrams have several valuable applications. You can use them to:

 Show which software elements are deployed by which hardware elements.

 Illustrate the runtime processing for hardware.
 Provide a view of the hardware system’s topology.

Deployment diagram elements

A variety of shapes make up deployment diagrams. This list offers an overview of the basic
elements you may encounter, and you can see most of these items illustrated in the image
below.

 Artifact: A product developed by the software, symbolized by a rectangle with the name
and the word “artifact” enclosed by double arrows.
 Association: A line that indicates a message or other type of communication between
nodes.
 Component: A rectangle with two tabs that indicates a software element.
 Dependency: A dashed line that ends in an arrow, which indicates that one node or
component is dependent on another.
 Interface: A circle that indicates a contractual relationship. Those objects that realize the
interface must complete some sort of obligation.
 Node: A hardware or software object, shown by a three-dimensional box.
 Node as container: A node that contains another node inside of it—such as in the example
below, where the nodes contain components.
 Stereotype: A device contained within the node, presented at the top of the node, with the
name bracketed by double arrows.

Deployment diagram symbols and notation

Use these shapes as you build UML deployment diagrams.

 Nodes

There are two types of nodes in a deployment diagram: device nodes and execution
environment nodes. Device nodes are computing resources with processing capabilities and
the ability to execute programs. Some examples of device nodes include PCs, laptops, and
mobile phones.

An execution environment node, or EEN, is any computer system that resides within a device
node. It could be an operating system, a JVM, or another servlet container.

Database

Databases represent any data stored by the deployed system. In some instances, you'll see a
database represented as just another node, but sometimes you will see this shape as a
database.

Other shapes

 Communication path: A straight line that represents communication between two device
nodes.
 Artifacts: A box with the header ">" and then the name of the file.
 Package: A file-shaped box that groups together all the device nodes to encapsulate the
entire deployment.
 Component: An entity required to execute a stereotype function. Take a look at this guide
for UML component notation.

Deployment diagram example

This example shows a basic deployment diagram .There is a web server, a database server,
and the machine where the user views the website. You can add more complexity by showing
the different parts of the web server and the way Javascript works on the UserClient, but this
example gives you an idea of how a deployment looks in UML notation.

Design Patterns

Pattern designing requires a combination of skills, including creativity, attention to detail,

and technical knowledge. A successful pattern designer must be able to visualize the
finished product and translate that vision into a precise and accurate pattern.
A design pattern provides a general reusable solution for the common problems that occur
in software design. The pattern typically shows relationships and interactions between
classes or objects. The idea is to speed up the development process by providing well-
tested, proven development/design paradigms. Design patterns are programming language-
independent strategies for solving a common problem. That means a design pattern
represents an idea, not a particular implementation. By using design patterns, you can make
your code more flexible, reusable, and maintainable.
It’s not mandatory to always implement design patterns in your project. Design patterns are
not meant for project development. Design patterns are meant for common problem-
solving. Whenever there is a need, you have to implement a suitable pattern to avoid such
problems in the future. To find out which pattern to use, you just have to try to understand
the design patterns and their purposes. Only by doing that, you will be able to pick the right
one. 
Example:
In many real-world situations, we want to create only one instance of a class. For example,
there can be only one active president of a country at any given time. This pattern is called
a Singleton pattern. Other software examples could be a single DB connection shared by
multiple objects as creating a separate DB connection for every object is costly. Similarly,
there can be a single configuration manager or error manager in an application that handles
all problems instead of creating multiple managers. 
Types of Design Patterns
There are mainly three types of design patterns: 
1. Creational 
These design patterns are all about class instantiation or object creation. These patterns can
be further categorized into Class-creational patterns and object-creational patterns. While
class-creation patterns use inheritance effectively in the instantiation process, object-
creation patterns use delegation effectively to get the job done. 
Creational design patterns are the Factory Method, Abstract Factory, Builder, Singleton,
Object Pool, and Prototype. 
Use case of creational design pattern- 
1) Suppose a developer wants to create a simple DBConnection class to connect to a
database and wants to access the database at multiple locations from code, generally what
the developer will do is create an instance of DBConnection class and use it for doing
database operations wherever required. This results in creating multiple connections from
the database as each instance of DBConnection class will have a separate connection to the
database. In order to deal with it, we create DBConnection class as a singleton class, so that
only one instance of DBConnection is created and a single connection is established.
Because we can manage DB Connection via one instance, we can control load balance,
unnecessary connections, etc. 
2) Suppose you want to create multiple instances of a similar kind and want to achieve
loose coupling then you can go for Factory pattern. A class implementing a factory design
pattern works as a bridge between multiple classes. Consider an example of using multiple
database servers like SQL Server and Oracle. If you are developing an application using
SQL Server database as the back end, but in the future need to change the database to
oracle, you will need to modify all your code so that factory design patterns maintain loose
coupling and easy implementation, we should go for the factory design pattern in order to
achieve loose coupling and the creation of a similar kind of object.

2. Structural 
These design patterns are about organizing different classes and objects to form larger
structures and provide new functionality. Structural design patterns are Adapter, Bridge,
Composite, Decorator, Facade, Flyweight, Private Class Data, and Proxy. 
Use Case Of Structural Design Pattern- 
1) When 2 interfaces are not compatible with each other and want to establish a relationship
between them through an adapter it’s called an adapter design pattern. The adapter pattern
converts the interface of a class into another interface or class that the client expects, i.e
adapter lets classes work together that could not otherwise because of incompatibility. so in
these types of incompatible scenarios, we can go for the adapter pattern.
3. Behavioral 
Behavioral patterns are about identifying common communication patterns between objects
and realizing these patterns. Behavioral patterns are Chain of responsibility, Command,
Interpreter, Iterator, Mediator, Memento, Null Object, Observer, State, Strategy, Template
method, Visitor 
Use Case of Behavioral Design Pattern- 
1) The template pattern defines the skeleton of an algorithm in an operation deferring some
steps to sub-classes. The template method lets subclasses redefine certain steps of an
algorithm without changing the algorithm structure. For example, in your project, you want
the behavior of the module to be able to extend, such that we can make the module behave
in new and different ways as the requirements of the application change, or to meet the
needs of new applications. However, no one is allowed to make source code changes to it,
i.e you can add but can’t modify the structure in those scenarios a developer can approach
template design patterns.

Advantages of Pattern Designing:

1. Precision: The primary advantage of pattern designing is that it allows for precise and
accurate measurements and calculations, resulting in a well-fitted garment.
2. Efficiency: Creating a pattern saves time and effort in the production process. Once the
pattern is created, it can be used to make multiple garments, reducing the time and
resources needed to create each one.
 Creativity: Pattern designing allows for creative expression and experimentation,
enabling designers to explore different styles, shapes, and techniques.
3. Consistency: A pattern ensures consistency in the production process, resulting in a
uniformity of the finished product, which is essential for large-scale manufacturing.
4. Replicability: Patterns can be replicated and used for different sizes, styles, and fabrics,
making them a valuable asset for designers and manufacturers.

Disadvantages of Pattern Designing:

1. Cost: Pattern designing can be expensive, particularly if it involves specialized software

or equipment.
2. Skill: Pattern designing requires specialized knowledge and skills, which may not be
available to everyone.
3. Time-consuming: Creating a pattern can be a time-consuming process, requiring
attention to detail and numerous adjustments to ensure a proper fit.
4. Limited creativity: Working within the confines of a pattern can limit the designer’s
creativity, making it difficult to create unique or innovative designs.
5. Sustainability: The production of patterns, particularly on paper, can contribute to waste
and harm to the environment.

Singleton Design Pattern

Singleton pattern is a design pattern which restricts a class to instantiate its multiple
objects. It is nothing but a way of defining a class. Class is defined in such a way that only
one instance of the class is created in the complete execution of a program or project. It is
used where only a single instance of a class is required to control the action throughout the
execution. A singleton class shouldn’t have multiple instances in any case and at any cost.
Singleton classes are used for logging, driver objects, caching and thread pool, database
connections.
Singleton Design Pattern

/A singleton class should have public visibility

//so that complete application can use
public class GFG {
    
  //static instance of class globally accessible
  public static GFG instance = new GFG();
  private GFG() {
    // private constructor so that class
    //cannot be instantiated from outside
    //this class
  }
}
Examples of Singleton class
1. java.lang.Runtime : Java provides a class Runtime in its lang package which is
singleton in nature. Every Java application has a single instance of class Runtime that
allows the application to interface with the environment in which the application is
running. The current runtime can be obtained from the getRuntime() method.
An application cannot instantiate this class so multiple objects can’t be created for this
class. Hence Runtime is a singleton class.
2. java.awt.Desktop : The Desktop class allows a Java application to launch associated
applications registered on the native desktop to handle a URI or a file
Applications of Singleton classes
There is a lot of applications of singleton pattern like cache-memory, database connection,
drivers, logging. Some major of them are :-
1. Hardware interface access: The use of singleton depends on the requirements.
Singleton classes are also used to prevent concurrent access of class. Practically
singleton can be used in case external hardware resource usage limitation required e.g.
Hardware printers where the print spooler can be made a singleton to avoid multiple
concurrent accesses and creating deadlock.
2. Logger : Singleton classes are used in log file generations. Log files are created by the
logger class object. Suppose an application where the logging utility has to produce one
log file based on the messages received from the users. If there is multiple client
application using this logging utility class they might create multiple instances of this
class and it can potentially cause issues during concurrent access to the same logger file.
We can use the logger utility class as a singleton and provide a global point of reference
so that each user can use this utility and no 2 users access it at the same time.
3. Configuration File: This is another potential candidate for Singleton pattern because
this has a performance benefit as it prevents multiple users to repeatedly access and
read the configuration file or properties file. It creates a single instance of the
configuration file which can be accessed by multiple calls concurrently as it will
provide static config data loaded into in-memory objects. The application only reads
from the configuration file for the first time and thereafter from second call onwards the
client applications read the data from in-memory objects.
4. Cache: We can use the cache as a singleton object as it can have a global point of
reference and for all future calls to the cache object the client application will use the
in-memory object.

Observer Pattern
Let us first consider the following scenario to understand observer pattern.
Scenario:
Suppose we are building a cricket app that notifies viewers about the information such as
current score, run rate etc. Suppose we have made two display elements
CurrentScoreDisplay and AverageScoreDisplay. CricketData has all the data (runs, bowls
etc.) and whenever data changes the display elements are notified with new data and they
display the latest data accordingly.

Problems with above design:

 CricketData holds references to concrete display element objects even though it needs
to call only the update method of these objects. It has access to too much additional
information than it requires.
 CricketData and display elements are tightly coupled.
 If in future another requirement comes in and we need another display element to be
added we need to make changes to the non-varying part of our code(CricketData).
This is definitely not a good design practice and application might not be able to
handle changes and not easy to maintain.
How to avoid these problems?
Use Observer Pattern
Observer pattern
To understand observer pattern, first you need to understand the subject and observer
objects.
The relation between subject and observer can easily be understood as an analogy to
magazine subscription.
 A magazine publisher(subject) is in the business and publishes magazines (data).
 If you(user of data/observer) are interested in the magazine you subscribe(register), and
if a new edition is published it gets delivered to you.
 If you unsubscribe(unregister) you stop getting new editions.
 Publisher doesn’t know who you are and how you use the magazine, it just delivers it to
you because you are a subscriber(loose coupling).
Definition:
The Observer Pattern defines a one to many dependency between objects so that one object
changes state, all of its dependents are notified and updated automatically.
Explanation:
 One to many dependency is between Subject(One) and Observer(Many).
 There is dependency as Observers themselves don’t have access to data. They are
dependent on Subject to provide them data.
Class diagram:

 Here Observer and Subject are interfaces(can be any abstract super type not necessarily
java interface).
 All observers who need the data need to implement observer interface.
 notify() method in observer interface defines the action to be taken when the subject
provides it data.
 The subject maintains an observerCollection which is simply the list of currently
registered(subscribed) observers.
 registerObserver(observer) and unregisterObserver(observer) are methods to add and
remove observers respectively.
 notifyObservers() is called when the data is changed and the observers need to be
supplied with new data.
Advantages:
Provides a loosely coupled design between objects that interact. Loosely coupled objects
are flexible with changing requirements. Here loose coupling means that the interacting
objects should have less information about each other.
Observer pattern provides this loose coupling as:
 Subject only knows that observer implement Observer interface.Nothing more.
 There is no need to modify Subject to add or remove observers.
 We can reuse subject and observer classes independently of each other.
When to use this pattern?
You should consider using this pattern in your application when multiple objects are
dependent on the state of one object as it provides a neat and well tested design for the
same.