What is UML ?

Describe Use of UML, Diagram and Goals of UML

Unified Modeling Language (UML) is a general purpose modelling language. The main
aim of UML is to define a standard way to visualize the way a system has been designed. It
is quite similar to blueprints used in other fields of engineering.
UML is not a programming language, it is rather a visual language. We use UML diagrams
to portray the behavior and structure of a system. UML helps software engineers,
businessmen and system architects with modelling, design and analysis. The Object
Management Group (OMG) adopted Unified Modelling Language as a standard in 1997. Its
been managed by OMG ever since. International Organization for Standardization (ISO)
published UML as an approved standard in 2005. UML has been revised over the years and
is reviewed periodically.

1stStructural Diagrams – Capture static aspects or structure of a system. Structural

Diagrams include: Component Diagrams, Object Diagrams, Class Diagrams and
Deployment Diagrams.
2ndBehavior Diagrams – Capture dynamic aspects or behavior of the system. Behavior
diagrams include: Use Case Diagrams, State Diagrams, Activity Diagrams and
Interaction Diagrams.
The image below shows the hierarchy of diagrams according to UML 2.2

1stClass – A class defines the blue print i.e. structure and functions of an object.
2ndObjects – Objects help us to decompose large systems and help us to modularize our
system. Modularity helps to divide our system into understandable components so
that we can build our system piece by piece. An object is the fundamental unit
(building block) of a system which is used to depict an entity.
3rdInheritance – Inheritance is a mechanism by which child classes inherit the
properties of their parent classes.
4thAbstraction – Mechanism by which implementation details are hidden from user.
5thEncapsulation – Binding data together and protecting it from the outer world is
referred to as encapsulation.
6thPolymorphism – Mechanism by which functions or entities are able to exist in
different forms.
7thClass Diagram – The most widely use UML diagram is the class diagram. It is the
building block of all object oriented software systems. We use class diagrams to
depict the static structure of a system by showing system’s classes,their methods and
attributes. Class diagrams also help us identify relationship between different classes
or objects.
8thComposite Structure Diagram – We use composite structure diagrams to represent
the internal structure of a class and its interaction points with other parts of the
system. A composite structure diagram represents relationship between parts and their
configuration which determine how the classifier (class, a component, or a
deployment node) behaves. They represent internal structure of a structured classifier
making the use of parts, ports, and connectors. We can also model collaborations
using composite structure diagrams. They are similar to class diagrams except they
represent individual parts in detail as compared to the entire class.
9thObject Diagram – An Object Diagram can be referred to as a screenshot of the
instances in a system and the relationship that exists between them. Since object
diagrams depict behaviour when objects have been instantiated, we are able to study
the behaviour of the system at a particular instant. An object diagram is similar to a
class diagram except it shows the instances of classes in the system. We depict actual
classifiers and their relationships making the use of class diagrams. On the other
hand, an Object Diagram represents specific instances of classes and relationships
between them at a point of time.
10thComponent Diagram – Component diagrams are used to represent how the
physical components in a system have been organized. We use them for modelling
implementation details. Component Diagrams depict the structural relationship
between software system elements and help us in understanding if functional
requirements have been covered by planned development. Component Diagrams
 become essential to use when we design and build complex systems. Interfaces are
used by components of the system to communicate with each other.
11thDeployment Diagram – Deployment Diagrams are used to represent system
hardware and its software.It tells us what hardware components exist and what
software components run on them.We illustrate system architecture as distribution of
software artifacts over distributed targets. An artifact is the information that is
generated by system software. They are primarily used when a software is being used,
distributed or deployed over multiple machines with different configurations.
12thPackage Diagram – We use Package Diagrams to depict how packages and their
elements have been organized. A package diagram simply shows us the dependencies
between different packages and internal composition of packages. Packages help us to
organise UML diagrams into meaningful groups and make the diagram easy to
understand. They are primarily used to organise class and use case diagrams.
Behavior Diagrams –

1stState Machine Diagrams – A state diagram is used to represent the condition of the
system or part of the system at finite instances of time. It’s a behavioral diagram and
it represents the behavior using finite state transitions. State diagrams are also referred
to as State machines and State-chart Diagrams . These terms are often used
interchangeably.So simply, a state diagram is used to model the dynamic behavior of
a class in response to time and changing external stimuli.
2ndActivity Diagrams – We use Activity Diagrams to illustrate the flow of control in a
system. We can also use an activity diagram to refer to the steps involved in the
execution of a use case. We model sequential and concurrent activities using activity
diagrams. So, we basically depict workflows visually using an activity diagram.An
activity diagram focuses on condition of flow and the sequence in which it happens.
We describe or depict what causes a particular event using an activity diagram.
3rdUse Case Diagrams – Use Case Diagrams are used to depict the functionality of a
system or a part of a system. They are widely used to illustrate the functional
requirements of the system and its interaction with external agents(actors). A use case
is basically a diagram representing different scenarios where the system can be used.
A use case diagram gives us a high level view of what the system or a part of the
system does without going into implementation details.
4thSequence Diagram – A sequence diagram simply depicts interaction between
objects in a sequential order i.e. the order in which these interactions take place.We
can also use the terms event diagrams or event scenarios to refer to a sequence
diagram. Sequence diagrams describe how and in what order the objects in a system
function. These diagrams are widely used by businessmen and software developers to
document and understand requirements for new and existing systems.
5thCommunication Diagram – A Communication Diagram(known as Collaboration
Diagram in UML 1.x) is used to show sequenced messages exchanged between
objects. A communication diagram focuses primarily on objects and their
relationships. We can represent similar information using Sequence
diagrams,however, communication diagrams represent objects and links in a free
form.
6thTiming Diagram – Timing Diagram are a special form of Sequence diagrams which
are used to depict the behavior of objects over a time frame. We use them to show
time and duration constraints which govern changes in states and behavior of objects.
7thInteraction Overview Diagram – An Interaction Overview Diagram models a
sequence of actions and helps us simplify complex interactions into simpler
occurrences. It is a mixture of activity and sequence diagrams.
UML Use Case Diagram
A use case diagram is used to represent the dynamic behavior of a system. It encapsulates
the system's functionality by incorporating use cases, actors, and their relationships. It
models the tasks, services, and functions required by a system/subsystem of an
application. It depicts the high-level functionality of a system and also tells how the user
handles a system.

Purpose of Use Case Diagrams

The main purpose of a use case diagram is to portray the dynamic aspect of a system. It
accumulates the system's requirement, which includes both internal as well as external
influences. It invokes persons, use cases, and several things that invoke the actors and
elements accountable for the implementation of use case diagrams. It represents how an
entity from the external environment can interact with a part of the system.
Following are the purposes of a use case diagram given below:

1stIt gathers the system's needs.

2ndIt depicts the external view of the system.

3rdIt recognizes the internal as well as external factors that influence the system.

4thIt represents the interaction between the actors.

Important tips for drawing a Use Case diagram
Following are some important tips that are to be kept in mind while drawing a use case
diagram:

1stA simple and complete use case diagram should be articulated.

2ndA use case diagram should represent the most significant interaction among the

multiple interactions.

3rdAt least one module of a system should be represented by the use case diagram.

4thIf the use case diagram is large and more complex, then it should be drawn more

generalized.

What is Object and Attribute in UML? Describe different types of Attributes in UML

UML Class Diagram

The class diagram depicts a static view of an application. It represents the types of objects
residing in the system and the relationships between them. A class consists of its objects,
and also it may inherit from other classes. A class diagram is used to visualize, describe,
document various different aspects of the system, and also construct executable software
code.
It shows the attributes, classes, functions, and relationships to give an overview of the
software system. It constitutes class names, attributes, and functions in a separate
compartment that helps in software development. Since it is a collection of classes,
interfaces, associations, collaborations, and constraints, it is termed as a structural
diagram.

Purpose of Class Diagrams

The main purpose of class diagrams is to build a static view of an application. It is the only
diagram that is widely used for construction, and it can be mapped with object-oriented
languages. It is one of the most popular UML diagrams. Following are the purpose of class
diagrams given below:

1stIt analyses and designs a static view of an application.

2ndIt describes the major responsibilities of a system.

3rdIt is a base for component and deployment diagrams.

4thIt incorporates forward and reverse engineering.

Benefits of Class Diagrams
1stIt can represent the object model for complex systems.

2ndIt reduces the maintenance time by providing an overview of how an application is

structured before coding.

3rdIt provides a general schematic of an application for better understanding.

4thIt represents a detailed chart by highlighting the desired code, which is to be

programmed.

5thIt is helpful for the stakeholders and the developers

Relationships
In UML, relationships are of three types:

Dependency: A dependency is a semantic relationship between two or more classes

where a change in one class cause changes in another class. It forms a weaker

relationship.

In the following example, Student_Name is dependent on the Student_Id.

Generalization: A generalization is a relationship between a parent class (superclass)

and a child class (subclass). In this, the child class is inherited from the parent class.

For example, The Current Account, Saving Account, and Credit Account are the

generalized form of Bank Account.

 Association: It describes a static or physical connection between two or more objects.

It depicts how many objects are there in the relationship.

For example, a department is associated with the college.

Multiplicity: It defines a specific range of allowable instances of attributes. In case if a

range is not specified, one is considered as a default multiplicity.
For example, multiple patients are admitted to one hospital.

Aggregation: An aggregation is a subset of association, which represents has a

relationship. It is more specific then association. It defines a part-whole or part-of
relationship. In this kind of relationship, the child class can exist independently of its
parent class.
The company encompasses a number of employees, and even if one employee resigns,
the company still exists.
Composition: The composition is a subset of aggregation. It portrays the dependency
between the parent and its child, which means if one part is deleted, then the other part
also gets discarded. It represents a whole-part relationship.
A contact book consists of multiple contacts, and if you delete the contact book, all the
contacts will be lost.

The class diagram is used to represent a static view of the system. It plays
an essential role in the establishment of the component and deployment
diagrams. It helps to construct an executable code to perform forward and
backward engineering for any system, or we can say it is mainly used for
construction. It represents the mapping with object-oriented languages that
are C++, Java, etc. Class diagrams can be used for the following purposes:

1stTo describe the static view of a system.

2ndTo show the collaboration among every instance in the static view.

3rdTo describe the functionalities performed by the system.

4thTo construct the software application using object-oriented languages
UML-Generalization
In UML modeling, a generalization relationship is a relationship that implements the
concept of object orientation called inheritance. The generalization relationship occurs
between two entities or objects, such that one entity is the parent, and the other one is
the child. The child inherits the functionality of its parent and can access as well as update
it.
Generalization relationship is utilized in class, component, deployment, and use case
diagrams to specify that the child inherits actions, characteristics, and relationships from
its parent.
To meet UML's standard, it necessitates usage of the same types of model elements in the
generalization relationship, i.e., generalization relation can either be used between actors
or between use cases, but not between an actor and a use case.
The generalization relationship is incorporated to record attributes, operations, and
relationships in a parent model element so that it can be inherited in one or more child
model elements.
The parent model element can have as many children, and also, the child can have one or
more parents. But most commonly, it can be seen that there is one parent model element
and multiple child model elements. The generalization relationship does not consist of
names. The generalization relationship is represented by a solid line with a hollow
arrowhead pointing towards the parent model element from the child model element.
 UML-Realization
In UML modeling, the realization is a relationship between two objects, where the client
(one model element) implements the responsibility specified by the supplier (another
model element). The realization relationship can be employed in class diagrams and
components diagrams.
The realization relationship does not have names. It is mostly found in the interfaces. It is
represented by a dashed line with a hollow arrowhead at one end that points from the
client to the server.

Interface Realization
Interface realization is a kind of specialized relation between the classifier and the
interface. In interface realization relationship, realizing classifiers conforms to the contract
defined by the interface.
A classifier implementing an interface identifies the objects that conform to the interface
and any of its ancestors. A classifier can execute one or more interfaces. The set of
interfaces that are implemented by the classifier are its given interfaces. The given
interfaces are the set of services offered by the classifiers to its clients.

The interface realization relationship does not contain names, and if you name it, then the
name will appear beside the connector in the diagram.
The interface realization relationship is represented by a dashed line with a hollow
arrowhead, which points from the classifier to the given interface.

Types of realization:
1. Canonical form: In UML, the canonical form realizes the interfaces across the system.
An interface stereotype is used for creating an interface, and a realization relationship is
employed to realize (implement) a specific interface. In this, the realization relationship is
represented by a dashed line with a hollow arrowhead, and the interface is implemented
using an object.
From the diagram given below, it can be seen that the object Account Business
Rules realizes the interface Iruleagent.
2. Elided form: It is that kind of realization relationship in which the interface is
represented by a circle, also known as a lollipop notation. When an interface is realized
employing anything present in the system, then an elided structure is created.
Here the interface Iruleagent is denoted by an elided form, which is realized by
acctrule.dll.
 Association, Composition and
Aggregation in Java
Association is a relation between two separate classes which establishes through their
Objects. Association can be one-to-one, one-to-many, many-to-one, many-to-many. In
Object-Oriented programming, an Object communicates to another object to use
functionality and services provided by that object. Composition and Aggregation are the
two forms of association.
 Aggregation

It is a special form of Association where:

It represents Has-A’s relationship.
It is a unidirectional association i.e. a one-way relationship. For example, a
department can have students but vice versa is not possible and thus unidirectional in
nature.
In Aggregation, both entries can survive individually which means ending one
entity will not affect the other entity.

Concept 3: Composition

Composition

Composition is a restricted form of Aggregation in which two entities are highly dependent
on each other.
It represents part-of relationship.
In composition, both entities are dependent on each other.
When there is a composition between two entities, the composed object cannot
 exist without the other entity.

Aggregation vs Composition
1. Dependency: Aggregation implies a relationship where the child can exist
independently of the parent. For example, Bank and Employee, delete the Bank and the
Employee still exist. whereas Composition implies a relationship where the child cannot
exist independent of the parent. Example: Human and heart, heart don’t exist separate to a
Human
2. Type of Relationship: Aggregation relation is “has-a” and composition is “part-
of” relation.
3. Type of association: Composition is a strong Association whereas Aggregation is
a weak Association.

UML can be described as the successor of object-oriented (OO) analysis and design.
An object contains both data and methods that control the data. The data represents the state of the
object. A class describes an object and they also form a hierarchy to model the real-world system.
The hierarchy is represented as inheritance and the classes can also be associated in different ways
as per the requirement.
Objects are the real-world entities that exist around us and the basic concepts such as abstraction,
encapsulation, inheritance, and polymorphism all can be represented using UML.
UML is powerful enough to represent all the concepts that exist in object-oriented analysis and
design. UML diagrams are representation of object-oriented concepts only. Thus, before learning
UML, it becomes important to understand OO concept in detail.
Following are some fundamental concepts of the object-oriented world −

Objects − Objects represent an entity and the basic building block.

Class − Class is the blue print of an object.

Abstraction − Abstraction represents the behavior of an real world entity.

Encapsulation − Encapsulation is the mechanism of binding the data together and hiding them
from the outside world.
Inheritance − Inheritance is the mechanism of making new classes from existing ones.

Polymorphism − It defines the mechanism to exists in different forms.

OO Analysis and Design
OO can be defined as an investigation and to be more specific, it is the investigation of objects.
Design means collaboration of identified objects.
Thus, it is important to understand the OO analysis and design concepts. The most important
purpose of OO analysis is to identify objects of a system to be designed. This analysis is also done
for an existing system. Now an efficient analysis is only possible when we are able to start thinking
in a way where objects can be identified. After identifying the objects, their relationships are
identified and finally the design is produced.
The purpose of OO analysis and design can described as −

Identifying the objects of a system.

Identifying their relationships.

Making a design, which can be converted to executables using OO languages.

There are three basic steps where the OO concepts are applied and implemented. The steps can be
defined as
OO Analysis → OO Design → OO implementation using OO languages
The above three points can be described in detail as −

During OO analysis, the most important purpose is to identify objects and describe them in a
proper way. If these objects are identified efficiently, then the next job of design is easy. The
objects should be identified with responsibilities. Responsibilities are the functions performed
by the object. Each and every object has some type of responsibilities to be performed. When
these responsibilities are collaborated, the purpose of the system is fulfilled.

The second phase is OO design. During this phase, emphasis is placed on the requirements and
their fulfilment. In this stage, the objects are collaborated according to their intended
association. After the association is complete, the design is also complete.
 The third phase is OO implementation. In this phase, the design is implemented using OO
languages such as Java, C++, etc.

Role of UML in OO Design

UML is a modeling language used to model software and non-software systems. Although UML is
used for non-software systems, the emphasis is on modeling OO software applications. Most of the
UML diagrams discussed so far are used to model different aspects such as static, dynamic, etc.
Now whatever be the aspect, the artifacts are nothing but objects.
If we look into class diagram, object diagram, collaboration diagram, interaction diagrams all
would basically be designed based on the objects.
Hence, the relation between OO design and UML is very important to understand. The OO design
is transformed into UML diagrams according to the requirement. Before understanding the UML in
detail, the OO concept should be learned properly. Once the OO analysis and design is done, the
next step is very easy. The input from OO analysis and design is the input to UML diagrams.

Subsystems
The subsystem is where work is processed on the system. A subsystem is a single, predefined
operating environment through which the system coordinates the work flow and resource use. The
system can contain several subsystems, all operating independently of each other. Subsystems
manage resources.

All jobs, with the exception of system jobs, run within subsystems. Each subsystem can run unique
operations. For instance, one subsystem may be set up to handle only interactive jobs, while another
subsystem handles only batch jobs. Subsystems can also be designed to handle many types of work.
The system allows you to decide the number of subsystems and what types of work each subsystem
handles.

The run-time characteristics of a subsystem are defined in an object called a subsystem description.
For example, if you want to permanently change the amount of work (number of jobs) coming from
a job queue into a subsystem you only need to change the job queue entry in the subsystem
description.
 The controlling subsystem
The controlling subsystem is the interactive subsystem that starts
automatically when the system starts, and it is the subsystem through which
the system operator controls the system via the system console. It is
identified in the Controlling subsystem/library (QCTLSBSD) system value.
Why consider multiple subsystems
As the number of users on the system increases, a single subsystem for a set
of work is often insufficient. By dividing your users into multiple
subsystems you gain several advantages.
Subsystem description
A subsystem description is a system object that contains information
defining the characteristics of an operating environment controlled by the
system. The system-recognized identifier for the object type is *SBSD. A
subsystem description defines how, where, and how much work enters a
subsystem, and which resources the subsystem uses to perform the work. An
active subsystem takes on the simple name of the subsystem description.
How a subsystem starts
When a subsystem starts, the system allocates several items and starts
autostart and prestart jobs before the subsystem is ready for work

Difference between UML and ER

diagram
Read

Discuss
1. Unified Modelling Language (UML) :
UML is a modelling language that visually represents a software system.

2. ER Diagram :
ER diagram is a pictorial representation of the real-world entities and their relationships with
each other.
Difference between UML and ER Diagram:

S. No. CATEGORY UML ER

diagram

1. Full Form UML stands for ER Diagram

Unified Modelling stands for
Language. Entity
Relationship
Diagram.

2. Definition It is a general It is a
modelling language pictorial
which is used to representatio
visualize the design n of the real-
of a software system. world
entities and
their
relationships
with each
other.
 S. No. CATEGORY UML ER
diagram

3. Relationship It is the parent of ER It is the child

diagram. of UML.

4. Use It is used to design It is used to

the entire software. design only
the
databases.

5. Scale It is mainly used in IT can be

case of large-scale used in case
software of database
development. development
of all scales.

6. Components It has use cases and It has

workflows. entities,
attributes and
relationships.

7. Diagrams involved It involves use case It is itself

diagrams and activity involved in
diagrams. representatio
n.

8. Primary User It is used by It is made for

developers to the
understand flow of understandin
program. g of Stake
holders and
 S. No. CATEGORY UML ER
diagram

enterprise
owners, to
understand
that their
requirements
have been
correctly
met.

9. Depiction Flow of control is Relationships

depicted. are depicted.

10. Modelling It is a form of It depicts static

dynamic modelling modelling (as unlike
as it can depict what UML it does not
activities are being depict state of the
performed at what activities).
time.

11. States It involves a final and It has no state

an initial state. representation.

12. Shapes used It is uses circles, It uses only 3 shapes

rectangles with round (oval, rectangle and
 corners, arrow heads, diamond).
diamonds,
rectangular bars etc.

13. Use of swimlanes It uses swimlanes. It does not use

swimlanes.

14. Time It can represent time It does not depict

taken during time.
activities.

15. Types It is of 2 types,

Structural UML
diagrams and
Behavioral UML
diagrams