Unified Modeling Language [UML]

Unified Modeling Language is a modeling language for Software

systems.
It is a way of interaction between different stakeholders of a system.
It is developed for specifying, visualizing, constructing and documenting
the artifacts of a system.
Basic Building Blocks of Unified Modeling Language [UML]
Things
Relationships
Diagrams
Things are the most important building blocks of UML. Things can be

 Structural
 Behavioral
 Grouping
 Annotational

Structural Things define the static part of the model. They represent the
physical and conceptual elements.

UML Class Diagrams

A class represents a logical entity.

A class is a collection of Properties and Methods

Class Name
Attributes
Operations
Attributes : A significant piece of data containing values that describe
each instance of that class. Also called fields, variables, properties.

Methods : Also called Operations or Functions.

Allow you to specify any behavioral feature of a class.

Example of defining a class in UML.

Animal
- name : string
- id : string
- age : string
- setName()
- eat()

Visibility

-private : They can’t be accessed by any other class or sub class. In

UML private visibility is denoted as -

+public : An Attribute or Method is public, which can be accessed by

any other class. In UML public visibility is denoted as +

#protected : An Attribute or Method is protected. These can be accessed

by the same class or sub – classes. In UML protected visibility is
denoted as #.

~package / default : This sets the visibility to package or default, which

means it can be used by any other class.
Example of defining a Employee class in UML.
Employee
- name : string
- empid : int
- phone : string
- department :
string
+ updatePhone()

In the above example, name, empid, phone, department are declared as

Attributes for a class called Employee and they are declared as private.

updatePhone() is a method of a class Employee and it is declared to be

public.

Different relationships exists between classes.

Inheritance
Animal
- name : string
- id : string
- age : string
- setName()
- eat()

Tortoise Otter
This is an Inheritance relationship.

These sub – classes will inherit all the attributes and methods of the
super class. These sub – classes will use the name, id, and age that are
available in the super class.

If we want to add one more attribute, that is if we want to add an

attribute “weight” inside all the sub – classes, we’re just declaring in the
super class named Animal and we’re accessing it.

Inheritance
Animal
- name : string
- id : int
- age : int
- weight : int
- setName()
- eat()

Tortoise Otter

Association / Multiplicity

Associations shows relationships between classes.

Two types of Associations namely : Unary Associations and Binary

Associations.

Unary Associations

Class A Class B
Between the classes we’ve a single line with one arrow.
Class A knows about Class B.
Class B knows nothing about Class A.
Example :

Person Address

There is an Association between Person and an Address.

Sometimes, people think as “has – a” relationship in contrast the “is –
a” relationship of Inheritance.
So, we could say “Person has a Address”.
Example :

has - a
Person Address

Person knows its address.

Address doesn’t who is living there.
Class Address doesn’t know about class Person.
 Class A Class B

+doSomething() +actionB()

-myB
Here, Class A has a method ‘doSomething()’ and Class B has another
method which is action().
We’re also presenting the Association with name called “myB”.

Class A Class B
-myB : Class B
+doSomething() +actionB()

In Class A also added a value in the attributes field. Here, we’ve an

attribute it’s called myB and it is of type Class B.

Representation A

Class A Class B

+doSomething() +actionB()

-myB
We can look at both representations. Representation A has the emphasis
on the relationship between the Class A Class B.
It has that Association drawn with the arrow.

Representation B
Class A Class B
-myB : Class B
+doSomething() +actionB()

Representation B has the fact that Class A has a attribute of type Class B
written in the attribute.
Those two representations are identical.
Unary Associations and attributes are the same.
Which version should you use, depends on where your emphasis is.
If you’re going to emphasize the relationship of Class A to Class B, the
arrow is a great way to emphasize that.
Example

Person Address
-name : string -street : string
+doSomething() -city : string
-zip : string
+toString() :
-address string
Class Person has 2 attributes one is address of type Address, and the
other attribute is name which is of type string.
Both types of representations are used in the same diagram.
This is frequently done and it is perfectly fine as long as the attributes
are different. So, we don’t have any duplications.
3 types of Unary Associations
Association – Most general
Aggregation  Describe whole – part relationship.
Composition  Describe whole – part relationship.
Aggregation  Aggregations are associations with a whole – part
relationship.
Example :

Class A Class B

The hollow diamond is next to the class that represents the whole.
Class B is part of Class A.
Example

Lake Slide

Lake has a slide.

Notice, the hollow diamond is next to the class that represents the whole.
Lake is the whole, Slide is the part.
Composition : Compositions are aggregation where the life cycle of the
part class depends on that of the whole class.

UML distinguishes between composition and aggregation. (These are often

synonymous terms.)

That means the construction and destruction of the part depends on the
whole.
Use Case Diagram : In this we will be dealing with systems.

Actors

Usecases
---- Relationships
Systems  A system is whatever you’re developing such as website,
software component, business process, application, etc.
System is represented with rectangle.

This rectangle helps to find the scope of the system.

Anything within this rectangle happens within the ‘Banking App’ as
we’re building a simple ‘Banking Application’.
Anything outside of this rectangle doesn’t happen in the ‘Banking App’.
Actors  An actor is depicted as follows.
An actor is going to be someone or something that uses our system to
achieve a goal. That could be a Person, an Organization, another System
or an External device.
Who or where is going to be using our ‘Banking App’.
Another actor in this diagram will be the Bank. The Bank is going to
provide information that feeds into the ‘Banking App’ like transactions,
and account balances.
A things to be noted when dealing with Actors :
First, it is important to note that these actors are external objects. They
always need to be placed outside the system.
Actors need to be thought of as types or categories.
For our ‘Banking App’, an actor isn’t going to be a specific individual or
specific organization.
We wouldn’t label our actors as ‘ABC’ & ‘XYZ Bank’. We want to
keep things categorical.
So, right now we’re saying that both customer’s and banks are going to
use our app and this brings the topics : Primary Actors and Secondary
Actors.
Primary Actor : A Primary actor initiates the use of a system while the
Secondary actor is more reactionary.
Primary Actor : Customer
Secondary Actor : Bank
The Customer is going to initiate the use of our system. They’re going to
pull out their phone, open our ‘Banking App’ and do something with it.
Bank on the other hand is a Secondary actor. The Bank is going to act
once the Customer does something.
If the Customer goes on the app to see how much money is in their
account, only then does the Bank engage with our system to provide the
balance.
Primary actors should be to the left of the system and Secondary actors
should be to the right.

This just visually reinforces the fact that Customer engages with
‘Banking App’ and then the Bank reacts.
The next element is the Use Case and this is where you really start to
describe what your system does.
A Use Case is depicted with Oval shape and it represents an action that
accomplishes some sort of task within the system.
They’re going to be placed within the rectangle because they’re actions
occur within the ‘Banking App’.
Our ‘Banking App’ is going to allow a Customer to log in, check their
account balance, transfer funds between accounts, and make payments
towards bills.
So, if this is what our ‘Banking App’ does, we’re going to have Use
Cases that describe each of those actions.
We’ll have a Use Case called ‘LogIn’, ‘Check Balance’, ‘Transfer
Funds’, ‘Make Payment’.

You can see that each of these Use Cases starts with a verb and
reinforces an action that takes place . we also want them to be
sufficiently descriptive.
Finally, it’s a good practice to put your Use Cases in a logical order
when possible.
That’s why we put ‘LogIn’ at the top.
That’s the first thing that will happen when a Customer uses our
‘Banking App’.
The final element in Use Case Diagrams are Relationships.
An actor, by definition is using our system to achieve a goal. So, each
actor has to interact with at least one of the Use Cases within our system.
In our example, a Customer is going to ‘LogIn’ to our ‘Banking App’.
So, we draw a solid line between the actor and the Use Case to show the
relationship.

This type of relationship is called as ‘Association’ and it just signifies a

basic communication or interaction.
They’re going to ‘Check Balance’, ‘Transfer Funds’, and ‘Make
Payment’, as we’ve drawn solid lines to those Use Cases.
So, which Use Case will the Bank interact with?
When a Customer wants to Check their balance on the app, the bank is
going to provide the correct amount.

Similarly, when a Customer wants to ‘Transfer Funds’ or ‘Make

Payment’, the bank is going to follow through with these transactions.
We don’t need to draw a line to LogIn, because that process happens
within the ‘Banking App’. There’s no need for the bank to actually get
involved with the Login process.
There are 3 other types of relationships in addition to association.
Include, Extend and Generalization
When a Customer types in their login information, our ‘Banking App’ is
going to verify the password, before completing the login process. But if
the password is incorrect, the ‘Banking App’ is going to display an error
message.
So, let’s create 2 new Use Cases for ‘Verify Password’ and ‘Display
Login Error’.
When a customer wants to ‘Transfer Funds’ or ‘Make Payment’, our
‘Banking App’ is going to make sure that there’s enough money to
complete these transactions.
So, we’ll create another Use Case called ‘Verify Sufficient Funds’.
Finally, when a Customer wants to make a payment, our ‘Banking App’
is going to give them the option of paying from either their Checking
Account or their Savings Account.
So, we’ll create 2 more Use Cases called ‘Pay from Checking Account’
and ‘Pay from Savings Account.
How does ‘Verify Password’ relate to the rest of the diagram?
Neither our actors are directly initiating this action. It’s just immediately
going to happen within our ‘Banking App’ every time there’s an attempt
to login.
This is an Include relationship.

An Include relationship shows dependency between a base use case and

an included use case.
Every time the base use case is executed, the included use case is
executed as well.
Another way to think of it is that the base use case requires an included
use case in order to complete.
When you have an included relationship, you draw a dashed line with an
arrow that points towards the included use case.

In this example, ‘LogIn’ is the Base Use Case and ‘Verify Password’ is
the Included Use Case.
Every time a Customer logs in our ‘Banking App’ will automatically
‘Verify Password’. This ‘LogIn’ Use Case won’t be complete unless
‘Verify Password’ is complete.
Extend : An Extend relationship has a Base Use Case and an Extend Use
Case. When the Base Use Case is executed, the Extend Use Case will
happen sometimes, but not every time.
The Extend Use Case will only happen if certain criteria are met.
Another way to think of it is that you have the option to extend the
behavior of the Base Use Case.
When you have an extend relationship, you draw a dashed line with an
arrow that points towards the base use case.
In our example, LogIn is a base use case and Display Login Error is an
extended use case.
Our ‘Banking App’ won’t display login error message every time a
Customer logs in. This will only happen once in a while when the
Customer accidentally enters an incorrect password.
Generalization : Also called as Inheritance.
When you make a payment from our ‘Banking App’, you can do so from
either your ‘Checking Account’ or your ‘Savings Account.
In this scenario, ‘Make Payment’ is a general Use Case and ‘Pay from
Checking’ and ‘Pay from Savings’ are specialized Use Cases.
You could use the terms parent and children.
Each child shares the common behaviors of the parent, but each child
adds something more on its own.
To show that this is a Generalization, it is denoted as follows:

Extension Points : Extension Points are just a detailed version of extend

relationships.
This Use Case shows us that a Customer can set up their profile in our
‘Banking App’, and then these extension points shows us that when a
Customer is setting up their profile, they’ll have the option to navigate to
a couple of different screens.
If a Customer is confused, they can go to Profile help and if they want
details regarding private information, they can go to ‘Privacy Info’.
Those extension points branch off to extended Use Cases: Go to Profile
Help and Show Privacy Info.
We can even add a note to show that some sort of conditions would lead
to these extension points.
Sequence Diagrams
Sequence diagrams are a part of UML diagrams that show how objects
in a system or classes within code interact with each other.
Particularly, these diagrams show interactions in the order they take
place in other words, they show the sequence of events.
They’re primarily used by developers and business professionals to
document processes or understand the requirements of a new program.
Example : Diagram the interaction that happens at an ATM.
Is to think of the parts that make up whatever your topic is.
If you’re diagramming a system, that would mean all the parts of that
system.
If you’re diagramming a code, that would mean all of the classes that
make up the program.
So, in our case, what are the parts involved in an ATM transaction.
A person goes to an ATM to get money.
The ATM communicates with a ‘Bank Server’ and that person’s ‘Bank
Account’ is then accessed.
The ATM, Bank Server and Bank Account are all part of the ATM
system.
These 3 items are objects. The person on the other hand is external to the
system.
Therefore, they’re an actor, actors are always outside the scope of the
system in a diagram.
In a Sequence diagram, actors are represented by stick figures and
objects are represented by rectangles.

Actor

Rectangles.

So, first of all we’ll drag out an actor and place them on the left. This
represents the person trying to get money.
Then we’ll add our objects alongside it.
Lifelines are the vertical dashed lines that show the existence of an
object or actor over time.
Moving down the Lifeline means that more time is passing.
To start, think of all the steps that happen when you go to get cash at an
ATM.
The first thing, you’ll need to do when get to an ATM is insert your
card. That will be our first message.
Messages show the information between objects Sequence diagrams
show the order of interactions or sequences and they do this by moving
down the life line with each message.

Activity Diagram
One of the another important diagrams in UML is the Activity Diagram
which shows a dynamic view of the system.
The Activity Diagram is a flowchart to represent the flow of control
among the activities in a system.
Simply, it’s a operation of the system shown in the diagrammatical form
where it shows all the control flow from one operation to another.
In the Activity Diagram shows the message flow from one activity to
another.
The flow of operation can be sequential, branched or concurrent. The
activity diagram is sometimes considered as the flowchart.
Although the diagrams looks like flow chart, but they are not.
Different notations used in Activity Diagram
Start Node : The small black filled circle is the standard notation for an
initial state before an activity takes place.

This start node represents the start of the activity.

Final Activity Node : The black circle that looks like selected radio
button is the symbol for the end state of the activity.

In the flow chart we represent in oval shape label with the end/ stop in it,
whereas in the Activity diagram we represent with small fill circle
include borderline.
Activity : The Activity symbols are the basic building blocks of an
activity diagram and usually have a short description of the activity they
represent.
Control Flow : A solid line with an arrow represent the direction flow of
the activities. The arrow points in the direction of progressing activities.

Join Node : A Join combines 2 concurrent activities back into a flow

where only one activity is happening at a time

Fork Node : A Fork splits single activity flow into 2 concurrent activities
which are represented as.
For example, an online flight reservation system. The activity starts and
needs to enter arrival and departure dates.
After that there needs to perform two activities 1. Search Availability
2. Personal Detail
Which are represented by fork symbol.
Similarly these 2 activities join together and flow another activity like
select flight which can be shown by join symbol.
Decision Symbol  It is similar to the flow chart which is represented
by the diamond shape where two paths coming out of a decision and the
condition text lets you know which options are mutually exclusive.

Condition  Condition text is placed next to decision maker to let you

know under what condition an activity flow should split off in that
direction.
Merge Node  Merge is similar to the join where two activities are
merged with the condition and only one activity flows forward.

Example : While sending Email, if the Email is private, encrypted it

before sending it while if not private send as regular mail.
These 2 activities are merged with the Merge node which is the same as
the decision represented by a diamond shape.
In Decision one activity as input and there will be 2 output according to
condition, whereas in Merge 2 activities are input and output only one
activity.
Final Flow Node : It represents the end of a specific process flow which
is denoted by a circle with cross lines inside the circle.

The difference between final activity and final flow node is that the
Final Flow node denotes the end of a single control flow, whereas
activity Final node denotes the end of all control flows within the
activity.
Partition : Activity Diagram partition is also known as Swim lanes
which are used to represent or group actions carried out by different
actors in a single thread.

Note or Comment : This is similar to the Sequence diagram used to add

relevant comments to elements that are represented by one corner folded
symbol.

Signal Sending  Used to represent the action of sending a single to an

accepting activity.
Signal Receipt  Which is used to represent that signal is received.

Example : Borrowing book in the Library System case study.

There may be 2 types of members new member and old or register
member. If not a member, follow the registration activity whereas if
already a member check if any book needs to return.
Next activity, is searching which is for Book, newly registered member
as well as for the old one.
Collaboration / Communication Diagram
Collaboration and Communication diagram both are same.
Communication / Collaboration diagram is used to show how objects
interact to perform the behavior of a particular use case or a part of a use
case.
Expanded use case description is a two – way interaction steps written
between the actor and the system how that particular use case will
execute.
It is a step – by – step execution as we are drawing the design in Object
– Oriented way.
A Collaboration diagram describe a pattern of interaction among objects.
It shows the objects participating in the interaction by their links to each
other and the message that they send to each other.
That means we are going through a programming concept.
Actually Collaboration / Communication diagrams are used by designers
to define and clarify the role of the objects that performs a particular
flow of events of the use cases. They are the primary source of
information used to determine class responsibilities and interfaces.
After Collaboration / Communication diagram we will also get the
number of classes and their names which needs to be defined in the
application and its respective objects.
We will know how these objects of different classes will interact and
flow message with each other in stepwise. Also, in these kinds of
information in the diagram is the Collaboration diagram. Its main
purpose is to visualize the interaction behavior of the system.
We all know that objects of the class communicates by sending and
receiving messages.
Example :
class A
{
methodA()
{
}
}
Here is class A with method named as ‘methodA()’ which will perform
certain tasks.
class B
{
methodB()
{
}
}
Another class B with method name as ‘methodB()’.
class c
{
main()
{
A a = new A();
B b = new B();
a.methodA();
answer = b.methodB();
}
}
Another class c which is the main class or a controller class. Here in
controller class in main class new object a of class A is defined. Also
new object b of class B is defined.
a.methodA() where c says to a that method should be executed.
answer = b.methodB(); where c says that b.methodB() should be
executed and B returns the results to c which is stored in ‘answer’
variable.
In this way, objects of the classes communicate by sending and
receiving messages.
How to draw a Collaboration / Communication diagram?
Collaboration diagram is derived from the high – level or expanded use
case description of the use case.
Go through a use case description and list the domain classes.
In Communication / Collaboration diagram we consider how objects of
these domain classes contribute to and are affected by the use case .
Are any objects created / modified / deleted?
Does the process obtain any data from any of these objects?
The major class which needs to be defined while executing the use case
are the domain classes.
How to find Domain classes?
It’s a College student record system application where Student can
enroll online in the college themselves from home.
The high level and expanded use case description of the use case ‘Enroll
Student’ .
In expanded we write the interactive description between actor and a
system.
Typical course of Events
Actor Action :
1. A new student provides personal details for enrollment.
System Response
2. Preference for course options.
Actor Action
 3. Choose best course among the available courses.
System Response
4. System provides a confirmation message of enrollment to students.
Now, find the ‘nouns’ from the description and list those which are
important to the processing.
If the system has to process data about the type of a person or object
name then this is probably a relevant class of objects like student data
needs to store course option should be provided and chosen course data
need to process.
The possible classes for the use case “Enroll Students” are.
Student, Course and Enrollment.
How are these involved in the Enroll Student process?
Consider what might happen when our new student enrolls.
1. An object of class Student will be created to store the student’s
information.
2. One of the more objects of class Course will be read so that the list
of courses can be presented to the Student so that the student can
make a choice of courses.
3. One of the more objects of class Enrollment will be created to store
information showing which student has enrolled in which course,
and perhaps including other information like join date, etc.
Steps for drawing Collaboration diagram.
1. Find the Domain classes.
2. Draw an object of the Domain classes
3. Drawing control object
Add a control object in the diagram. Note that the name of the control
object is the same name as the use case name.
Example of ‘Enroll Student’ use case, so the controller object name must
be also “EnrollStudent’.
Drawing boundary object. Boundary object will also have the same
name as the use case name with the additions of UI at last. Like
“EnrollStudentUI”.
Drawing actor just beside the boundary object, because actor interacts
with the system interface.
Add associations
State Chart Diagram
State Chart diagram is used to describe the states of different objects in
its life cycle. Emphasis is placed on the state changes upon some interval
or external events.
Events may take place, it may be within the system boundary internal
events or some external events may take place and depending upon that
the state of an object may have a transition from one state to another
state.
These states of objects are important to analyze and implement them
accurately.
This particular dynamic view of the system will help the developer to
develop the code accordingly.
State Chart diagrams are very important for describing the states . States
can be identified as the condition of objects when a particular event
occurs.
Depending upon the event occur, the state of an object will be decided.
Before drawing a state chart diagram we should clarify the following
points.
Identify the important objects to be analyzed.
Identify the states of that object.
Identify the events for which the state transition take place.
Identify the important objects to be analyzed.
State Chart Diagram shows the life cycle of a single object, from the
time it is created until it is destroyed.
These diagrams are a good way to model the dynamic behavior of a
class.
State : A State is one of the possible conditions in which an object may
exist.
Activity : An activity is some behavior that an object carries out while it
is in a particular state.
For example, when an account is in the closed state, the account holders
signature card is pulled. An activity is an interruptible behavior.
That means the respective activity can be interrupted by the respective
event generated.
Denotes Start State

Denotes stop state

Denotes state
Denotes State Transition

Whenever this transition is originally from one state and terminating to

the same state. Then it can also be called as reflexive transition.
Entry Action : An Entry Action is a behavior that occurs while the
object is transitioning into the state. Unlike an activity, an entry action is
considered to be uninterruptible. That means, when the state chart
diagram is getting started.
Exit Action : An Exit Action occurs as part of the transition out of a
state. When it is coming out from the respective state.
Transition : A Transition is a movement from one state to another.
Reflexive transition is having arrow starting and ending on the same
state.
Event : An Event is something that occurs that causes a transition from
one state to another.
Action : An Action is an uninterruptible behavior that occurs as part of
the transition.
Component Diagram
Component Diagrams are used to visualize the organization and
relationships among components in a system.
How the components are getting organized and what are the
relationships between these components in a system?
These diagrams are also used to make executable systems.
This is one component diagram for Order Management System.
There is one another component called Order System and Inventory
System, because Order System is actually using this Inventory System
while doing the ordering of the items.

What is a Component?
A Component can be a file, package, library, Activex component, applet,
dll, executable program and application.
If I want to make one running application, one application which will
execute in those cases, this particular component diagram can easily be
used.
In the above component diagram, we’re having one Controller, this
Controller is having view system which is interacting with the view, so
that the user can see the output of the application on their screen, which
will be containing ‘User Interface Files’.
How the user will be interacting with the Software? What will be the
interface with the help of which the user can interact?
The user interface system might be the GUI interface, so that will be
depicted in the respective component.
“Controller” which is the ‘Administrator’ of the system. These
Controllers is interacting with some set of modules.
The modules may be the “Retailer”, “Goods”, “Customer”, “Supplier”.
These modules are interacting with the database server to access
database for the read / write operations on the database.
This Controller is interacting with this Modules and these Modules are
ultimately interacting with this database server for the retrieval and
storing of information successfully and efficiently.
This is actually denoting the Software architecture of this respective
application and these Components might be localized in a single
machine, might be distributed into multiple machines and those
machines are connected by some Computer.
That’s why this Component Diagram will also depict that how these
Components are interacting and how they are interfacing with each
other.
Which Component is comprising of which Module and it will actually
depict the Software architecture.
Each and every UML diagram has their own purpose for that
application. So, Component diagram is that very UML diagram where
the System architecture, the Software system architecture, what are the
different components are requiring they are interacting with each other.
Purpose Of Component diagram
Component diagram is a special kind of diagram in UML. The purpose
is also different from all other diagrams.
It does not describe the functionality of the system but it describes the
Components used to make those functionalities.
Regarding the functionalities, Component diagram is not meant for that.
But what are the different Components that will be used to implement
those functionalities that will be described in the Component diagram.
Thus from that point of view, Component diagrams are used to visualize
the physical components in a system. These components are libraries,
packages, files, etc.
Component diagrams can also be described as a static implementation
view of a system.
Static implementation represents the organization of the components at a
particular moment.
A single Component diagram cannot represent the entire system but a
collection of diagrams is used to represent the whole.
The purpose of component diagram can be summarized as follows:
Visualize the Components of a system. Some diagrammatic notations
are there with the help of which we can visualize what are the
components we’re going to use.
Construct executables by using forward and reverse engineering.
Describe the organizations and relationships of the components.
Deployment Diagram
In Component diagram we’ve discussed what are the Components and
artifacts which will be required for the Software development and how
they will get organized and what will be the relationship between them.
But, in case of Deployment diagram we’re not bothering for the
Components, we’re bothering that how this Components will get
deployed on different physical devices and what will be the topology of
those physical devices?
What will be the hardware architecture, networking architecture on
which my Software will be running for that purpose.
Only this Deployment diagram has got its birth.
Deployment diagram are used to visualize the topology of the physical
components of a system, where the Software components are deployed.
Deployment diagrams are used to describe the Static deployment view
of a system.
Deployment diagrams consists of nodes and their relationship, respective
connections and respective ordering.
In this Deployment diagram, we will discuss about the physical
components which will be required for the smooth running of the
application.
How to draw a Deployment diagram?
Deployment diagram represents the deployment view of a system.
It is related to the Component diagram, because the Components are
deployed using the Deployment diagrams.
A Deployment diagram consists of Nodes.
Nodes are nothing but physical hardware used to deploy the application.
Why this Deployment diagram is so important?
What are the different factors which will be decided on this Deployment
diagram when having this set of some parameters.
Deployment diagrams are useful for system engineers. An efficient
Deployment diagram is very important as it controls the following
parameters:
Performance
Scalability
Maintainability
Portability
The above are the features which will be obtained and which will be
analyzed going through the Deployment diagram.
Before drawing Deployment diagram, the following artifacts should be
identified.
Nodes
Relationships among Nodes : The relative connectivity and the mode of
connectivity.
Deployment diagram shows all the nodes of the network, the
connections between them and the process that will run on each one.
Processor : A Processor in any machine that has processing power.
The servers, workstations and other machines with processors are
included in this category. The scheduling field documents the type of
process scheduling used by the Processor. They are.
Preemptive : Indicates that the high priority processes can preempt low
priority processes.
Non – Preemptive : Indicates that the processes have no priority. The
current process executes until it is finished, at which time the next
process begins.
Cyclic : Indicates that the control cycles between the processes; each
process is given set amount of time to execute, then control passes to the
next process.
That means, a time quantum or time slice will be given to each and
every process and when this quantum will expire then the quantum will
be allocated to another process in round – robin scheduling way.
Executive : Indicates that there is some sort of computational algorithm
that controls the scheduling.
Manual : Indicates that the processes are scheduled by the user.

This respective device, it may be a card reader, it may be a printer which

is not doing any processing, so that’s why it is a mirror device which is
not executing any code but this processor is having the capability to do
the processing and it can make our program get executed.
Device : A Device is a machine or piece of hardware without processing
power. Devices include item such as dumb terminals, printers or
scanners, card readers, card punctures and son on.
Connection : A Connection represents some type of hardware coupling
between 2 entities.
An entity is either a Processor or Device.
The hardware coupling can be direct such as an RS – 232 cable or
indirect such as Satellite – to – ground connection.
Connections are usually bi – directional.