Com 213 Uml Lecture Note
Com 213 Uml Lecture Note
1
Importance of modeling
Why do we model?
To help us visualize
To specify structure or behavior
To provide template for building system
To document decisions we have made
Principles of modeling
Four basic principles of modeling
1. The models we choose have a profound influence on the solution we provide
2. Every model may be expressed at different levels of abstraction
3. The best models are connected to reality
4. No single model is sufficient, a set of models needed to solve any nontrivial system
Types of system model
2
What is UML?
UML stands for Unified Modeling Language. It is an industry-standard graphical language for
specifying, visualizing, constructing and documenting the artifacts of software systems.
UML uses mostly graphical notations to express the Object Oriented Analysis and Design of
software projects. It simplifies the complex process of software design.
Purpose of UML
- It uses graphical notation to communicate more clearly than natural language and code
- It helps acquire an overall view of a system
UML diagrams are not only made for developers but also for business users, common people and
anybody interested to understand the system. The system can be a software or non-software
UML is not a development method rather it accompanies with processes to make it a successful
system
UML is a simple modeling mechanism to model all possible systems in todays’ complex
environment
Origin of UML
The 1990s was the era of development of object-oriented languages such as C++. These object-
oriented languages were used to create complex but compelling systems.
As the systems developed were complicated to understand, it led to the design and analysis
problems which were faced after the deployment of the system. It was difficult to explain the
system to others.
As soon as the UML was introduced, many game-changing experiments and approaches were
made for simplifying such difficult tasks of analyzing the system.
3
Each of UML inventors, viz, Grady Booch, Ivar Jacobson, and James Rumbaugh had a fantastic
idea for designing a language which will reduce the complexity.
Booch’s method was very flexible to work with during the design and construction of
objects.
Jacobson’s method provided a great way to work around use-cases. It also has a powerful
approach for high-level design.
Rumbaugh’s method turned out to be very useful while handling sensitive systems.
Later on, behavioral models and state-charts were introduced in the UML which were invented
by David Harel.
UML was recognized as a standard by Object Management Group (OMG) in 1997. Object
Management Group is responsible for managing UML ever since it was adopted as a standard.
In 2005, the International Organization for Standardization approved UML as an ISO standard. It
is used in various industries for creating object-oriented models.
The latest UML version is 2.5.1 which was released in December 2017.
UML Versions
Date Version About
UML was adopted by Object Management Group. This was the first
November 1997 1.1
version of UML.
A minor upgrade was done to the existing model with notable changes
March 2000 1.3
in semantics, notations, and meta-models of UML.
This was the period of the major update to the UML. It scaled UML by
September 2001 1.4 providing various extensions. Visibility, artifact, stereotypes were
introduced in diagrams.
August 2005 2.0 New diagrams such as the object, package, timing, interaction were
added to the UML. New features were added to the activity and
sequence diagrams. Collaboration diagram was renamed as
communication diagram. Multiple features and changes were introduced
4
Date Version About
UML 2.2 was revised, and minor changes were made to the component
May 2010 2.3
diagrams.
Classes, packages, and stereotypes changes were made. UML 2.3 was
August 2011 2.4.1
revised with enhancement features.
UML 2.4.1 was revised with minor changes. UML was made simple
than it was before. Rapid functioning and the generation of more
June 2015 2.5
effective models were introduced. Outdated features were eliminated.
Models, templates were eliminated as auxiliary constructs.
Characteristics of UML
1. It is a generalized modeling language.
2. It is different from software programming languages such as Python, C, C++, etc.
3. It is a pictorial language which can be used to generate powerful modeling elements.
4. It is related to object-oriented designs and analysis.
5. It has unlimited applications even outside the software industry. It can be used to
visualize the workflow of a factory.
UML diagrams can be used as a way to visualize a project before it takes place or as
documentation for a project afterward. But the overall goal of UML diagrams is to allow teams
to visualize how a project is or will be working, and they can be used in any field, not
just software engineering.
Also, it can provide new ideas for how the team needs to collaborate to achieve the goal of the
workflow process.
5
What is UML Diagram?
UML Diagrams are the output of the Unified Modeling Language. It is a pictorial representation
of classes, objects, and relationships between them. UML diagram is a model that describes a
part of a system. It is used to define the functionality or a design of a system. A diagram must be
clear and concise so that the viewer will readily understand it.
UML diagrams are divided into three different categories such as,
Structural diagram
Behavioral diagram
Interaction diagram
Class diagram
Object diagram
Package diagram
Component diagram
Deployment diagram
UML diagrams that deals with the static part of a system are called structural diagrams. UML
diagrams that deals with the moving or dynamic parts of the system are called behavioral
diagrams.
Activity diagram
Use case diagram
State machine diagram
6
Interaction diagrams in UML
Interaction diagram is nothing but a subset of behavioral diagrams. It is used to visualize the
flow between various use case elements of a system. Interaction diagrams are used to show an
interaction between two entities and how data flows within them.
Timing diagram
Sequence diagram
Collaboration diagram
Gliffy
Gliffy is an open-source software that designs UML diagrams, floor plans, Venn diagrams,
flowcharts, and much more. It allows the user to share and edit Gliffy diagrams dynamically.
Features:
o It constitutes a drag and drop interface.
7
o It exports diagrams in various formats that are; PDF, JPEG, PNG, and SVG.
o It is supported by all web browsers such as Google Chrome, Firefox, Safari, and Internet
Explorer 9+.
Lucidchart
Lucidchart is an HTML-5 based UML tool that allows user interaction while drawing, editing,
and sharing diagrams and charts. With Lucidchart, you can create simple flowcharts as well as
complex technical diagrams.
Features:
o It works faster with keyboard shortcuts.
o It constitutes the concept of containerization as the complex diagram involves several
steps and people.
o It manages user account by increasing security.
o It is platform-independent.
MagicDraw
Magic Draw is used to model UML diagrams, SysML, BPMN, and UPDM that supports the
dynamic collaboration of the team. This tool is meant for business analysts, software analysts,
programmers, and QA engineers. It facilitates analyzing and designing object-oriented systems
and databases.
Features:
o It provides round-trip support for programming languages (J2EE, C#, C++, COBRA
IDL), .NET, XML Schema, DDL generation, and database schema.
o It incorporates the concept of reverse engineering.
o It is a domain-specific language.
o It constitutes model decomposition that categorizes the main project into several distinct
independents parts.
o It encompasses model refactoring to improve the existing model.
MS Visio
8
Visio is a part of the Microsoft family, which is a diagramming software. It is helpful in drawing
building plans, floor charts, data flow diagrams, process flow diagrams, business process
modeling, swimlane diagrams, and many more.
Features:
o It connects the diagrams and the flowcharts to real-time data.
o Since it is a platform-independent, it can be accessed from anywhere.
Modelio
Modelio is an open-source UML tool that amalgamates UML2 and BPMN standards to support
an inclusive range of models and diagrams.
Features:
o It provides support to Jython, which is a scripting language.
o It provides a BPMN integrated support with UML.
o It offers XMI import/export.
Nclass
Nclass is an open-source tool, used to create class diagrams that support #C and Java. It requires
a framework of .NET 4.0. It has designed a simple and user-friendly user interface for fast and
easy development.
Features:
o It provides a simple and easy user interface.
o It offers a multilingual user interface.
o It provides mono support for the non-windows user.
o It has come up with inline class editors for fast and easy editing.
o It incorporates source code generation and reverse engineering from .Net assemblies.
9
StarUML
StarUML is a UML diagram modeling tool. It is one of the best UML software that provides
eleven types of diagram. StartUML 2 is compatible with UML 2.x versions.
Features:
This UML diagram software allows you to discover and install third-party extensions.
No limit to using this commercial software for evaluation.
Offers pre-built templates for Class Diagram
It provides multiple diagram options cloud storage
Supports JSON, PNG, HTML and JPEG file formats
It Provides import/export options for PDF, XML, PNG, JPEG, HTML and SVG
Support programming language like C, C++, C#, Java and Python
Provides Custom Uml Profile, Auto Update, Model-driven Development, Fast Modeling,
Dark And Light Themes and Code Markdown Support
Offers Multi-file support, Drag and Drop, and Print option
It provides customer support via Email
Supported Platforms: MacOS, Windows and Linux
Visual Paradigm
Visual Paradigm is a software design tool that is tailored for engine software projects. This UML
editor tool helps the software development team to model business information systems and
development processes.
Features:
It offers a complete tool like for process analysis, system design, database design, etc.
Offers user story feature to capture and maintain users’ needs.
Offers pre-built templates for Social Media, Events, Business, Marketing, Documents,
School, Personal, Infographics, Posters and Gift Card
Seamlessly integrates with Eclipse, NetBeans, IntelliJ IDEA, Visual Studio and Android
Studio
Free plan offers 1GB cloud storage
10
It provides multiple diagram options 1GB cloud storage
Supports JPG, PNG, SVG, TIFF, EMF, PDF and DOC file formats
It Provides import/export options for JPG, PNG, SVG, TIFF, EMF, PDF and XML
Offers 256-bit SSL encryption
Provides Visual Modeling, Enterprise Architecture, Business Analysis & Design, Project
Management, Agile & Scrum Development, Online Diagram Tool, Spreadsheet Tool, and
Team Collaboration
Offers Multi-file support, Drag and Drop, and Print option
It provides customer support via Contact form
Supported Platforms: MacOS, Windows, iOS and Linux
Draw.IO
Draw.IO is a free online UML tool. It is one of the best UML tools that allows users to create
and manage the drawing easily these tools. A lot of the wide and early share is available with this
tool.
Features:
11
It provides customer support via Email and Phone
Supported Platforms: Android, MacOS, Windows, iOS and Linux
12
Conceptual Model
Before beginning with the UML concept, one must understand the basics of the conceptual
model.
A conceptual model is required in UML. You have to understand the entities and relationships
between them before actually modeling the system.
Object: It is a real-world entity. There are multiple objects available within a single
system. It is a fundamental building block of UML.
Class: A class is nothing but a container where objects and their relationships are
maintained.
Abstraction: It is a mechanism of representing an entity without showing the
implementation details. It is used to visualize the behavior of an object.
Inheritance: It is a mechanism of extending an existing class to create a new class.
Polymorphism: It is a mechanism of representing an object having multiple forms which
are used for different purposes.
Encapsulation: It is a method of binding the object and the data together as a single unit.
It ensures tight coupling between the object and the data.
To understand the conceptual model of UML, first we need to clarify what is a conceptual model
and why a conceptual model is required?
A conceptual model can be defined as a model which is made of concepts and their
relationships.
A conceptual model is the first step before drawing a UML diagram. It helps to
understand the entities in the real world and how they interact with each other.
As UML describes the real-time systems, it is very important to make a conceptual model and
then proceed gradually. The conceptual model of UML can be mastered by learning the
following three major elements −
UML building blocks
Rules to connect the building blocks
Common mechanisms of UML
13
Conceptual Model of UML
14
4) Realization 5. Collaboration Diagram. *Tagged Values
6. State Chart Diagram. 1) Names *Constraints
7. Activity Diagram. 2) Scope
9. Deployment Diagram. 3) Visibility
4) Integrity
5) Execution
1. Things
2. Relationships
3. Diagrams
Things
A thing can be described as any real-world entity or an object. Things are divided into various
categories in UML as follows,
Structural things
Behavioral things
Grouping things
Annotational things
Structural things
A structural thing is used to describe the static part of a model. It is used to represent the things
that are visible to human eyes. Structural things in UML are all about the physical part of a
system. It is the noun of a UML model, such as a class, object, interface, collaboration, use case,
component, and a node.
Class:
A class is used to represent various objects. It is used to define the properties and operations of
an object. In UML, we can also represent an abstract class. A class whose functionalities are not
defined is called an abstract class. Any UML class diagram notations are generally expressed as
below UML class diagrams example,
Object:
An object is an entity which is used to describe the behavior and functions of a system. The class
and object have the same notations. The only difference is that an object name is always
underlined in UML.
Interface:
Collaboration:
Use-case:
Use-cases are one of the core concepts of object-oriented modeling. They are used to represent
high-level functionalities and how the user will handle the system.
UML Use Case
Actor:
It is used inside use case diagrams. The Actor notation is used to denote an entity that interacts
with the system. A user is the best example of an actor. The actor notation in UML is given
below.
UML Actor
Component:
A component notation is used to represent a part of the system. It is denoted in UML like given
below,
UML Component
Node:
A node is used to describe the physical part of a system. A node can be used to represent a
network, server, routers, etc. Its notation is given below.
UML Node
Deployment diagram:
1. A node
2. A component
3. An artifact
4. An interface
Deployment Diagram
Behavioral things
They are the verbs of a UML model, such as interactions, activities and state machines.
Behavioral things in UML are used to represent the behavior of a system.
State machine:
It used to describe various states of a single component throughout the software development life
cycle. It is used to capture different states of a system component.
State Machine
Activity diagram:
An activity diagram is used to represent various activities carried out by different components of
a system. It is denoted the same as that of the state machine diagram.
Activity diagram mainly contains initial state, final state, a decision box, and an action notation.
Activity Diagram
Interaction diagram:
Interaction diagrams are used to visualize the message flow between various components of a
system.
Sequence diagram: A sequence diagram shows interactions between one or more lifelines
within real time.
The notation of a sequence diagram is given below,
Interaction Diagram
Grouping things
It is the package which is used to group semantically related modeling elements into a single
cohesive unit. The package is the only grouping thing available in the UML.
UML Package
Annotational things
It is like a note, which may be written to the model to capture some vital information. It is
similar to the yellow sticky note. Here is an example for annotation things in UML:
UML Annotation
Relationships
The relationship allows you to show on a model how two or more things relate to each other. The
relationship in UML will enable you to capture meaningful connections between things. It shows
how each element is associated with each other and how this association describes the
functionality of an application.
Association relationship
Dependency relationship
Generalization relationship
Realization relationship
Association relationship
It is a set of links that connect elements of the UML model. It also defines how many objects are
taking part in that relation. It illustrates how many elements are participating in a particular
interaction.
It is denoted as a dotted line with arrowheads on both sides. Both the sides contain an element
which describes the relationship. A new term multiplicity is introduced that tells us how many
objects of a particular element are associated.
INCLUDEPICTURE "https://www.guru99.com/images/1/041519_1219_UMLNotation15.png"
\* MERGEFORMATINET
INCLUDEPICTURE "https://www.guru99.com/images/1/041519_1219_UMLNotation16.png"
\* MERGEFORMATINET
INCLUDEPICTURE "https://www.guru99.com/images/1/041519_1219_UMLNotation17.png"
\* MERGEFORMATINET
INCLUDEPICTURE "https://www.guru99.com/images/1/041519_1219_UMLNotation18.png"
\* MERGEFORMATINET
1. Class diagram
2. Object diagram
3. Component diagram
4. Composite structure diagram
5. Use case diagram
6. Sequence diagram
7. Communication diagram
8. State diagram
9. Activity diagram
10. Deployment diagram
11. Package diagram
12. Timing diagram
13. Interaction overview diagram
A class diagram shows a set of classes, interfaces, and collaborations and their
relationships. These diagrams are the most common diagram found in modeling object-oriented
systems. Class diagrams address the static design view of a system. Class diagrams that include
active classes address the static process view of a system. Component diagrams are variants of
class diagrams.
An object diagram shows a set of objects and their relationships. Object diagrams
represent static snapshots of instances of the things found in class diagrams. These diagrams
address the static design view or static process view of a system as do class diagrams, but from
the perspective of real or prototypical cases.
A component diagram is shows an encapsulated class and its interfaces, ports, and internal
structure consisting of nested components and connectors. Component diagrams address the
static design implementation view of a system. They are important for building large systems
from smaller parts. (UML distinguishes a composite structure diagram, applicable to any class,
from a component diagram, but we combine the discussion because the distinction between a
component and a structured class is unnecessarily subtle.)
A use case diagram shows a set of use cases and actors (a special kind of class) and their
relationships. Use case diagrams address the static use case view of a system. These diagrams
are especially important in organizing and modeling the behaviors of a system.
Both sequence diagrams and communication diagrams are kinds of interaction diagrams. An
interaction diagram shows an interaction, consisting of a set of objects or roles, including the
messages that may be dispatched among them. Interaction diagrams address the dynamic view
of a system. A sequence diagram is an interaction diagram that emphasizes the time-ordering
of messages; a communication diagram is an interaction diagram that emphasizes the
structural organization of the objects or roles that send and receive messages. Sequence
diagrams and communication diagrams represent similar basic concepts, but each diagram
emphasizes a different view of the concepts. Sequence diagrams emphasize temporal
ordering, and communication diagrams emphasize the data structure through which messages
flow. A timing diagram (not covered in this book) shows the actual times at which messages
are exchanged.
A state diagram shows a state machine, consisting of states, transitions, events, and activities.
A state diagrams shows the dynamic view of an object. They are especially important in
modeling the behavior of an interface, class, or collaboration and emphasize the event-ordered
behavior of an object, which is especially useful in modeling reactive systems.
An activity diagram shows the structure of a process or other computation as the flow of
control and data from step to step within the computation. Activity diagrams address the
dynamic view of a system. They are especially important in modeling the function of a system
and emphasize the flow of control among objects.
A deployment diagram shows the configuration of run-time processing nodes and the
components that live on them. Deployment diagrams address the static deployment view of an
architecture. A node typically hosts one or more artifacts.
An artifact diagram shows the physical constituents of a system on the computer. Artifacts
include files, databases, and similar physical collections of bits. Artifacts are often used in
conjunction with deployment diagrams. Artifacts also show the classes and components that
they implement. (UML treats artifact diagrams as a variety of deployment diagram, but we
discuss them separately.)
A package diagram shows the decomposition of the model itself into organization units and
their dependencies.
A timing diagram is an interaction diagram that shows actual times across different objects or
roles, as opposed to just relative sequences of messages. An interaction overview diagram is a
hybrid of an activity diagram and a sequence diagram. These diagrams have specialized uses
and so are not discussed in this book. See the UML Reference Manual for more details.
This is not a closed list of diagrams. Tools may use the UML to provide other kinds of
diagrams, although these are the most common ones that you will encounter in practice.
The UML's building blocks can't simply be thrown together in a random fashion. Like any
language, the UML has a number of rules that specify what a well-formed model should look
like. A well-formed model is one that is semantically self-consistent and in harmony with all
its related models.
Models built during the development of a software-intensive system tend to evolve and may be
viewed by many stakeholders in different ways and at different times. For this reason, it is
common for the development team to not only build models that are well-formed, but also to
build models that are
These less-than-well-formed models are unavoidable as the details of a system unfold and
churn during the software development life cycle. The rules of the UML encourage you but do
not force you to address the most important analysis, design, and implementation questions
that push such models to become well-formed over time.
1. Specifications
2. Adornments
3. Common divisions
4. Extensibility mechanisms
Specifications
The UML is more than just a graphical language. Rather, behind every part of its graphical
notation there is a specification that provides a textual statement of the syntax and semantics of
that building block. For example, behind a class icon is a specification that provides the full
set of attributes, operations (including their full signatures), and behaviors that the class
embodies; visually, that class icon might only show a small part of this specification.
Furthermore, there might be another view of that class that presents a completely different set
of parts yet is still consistent with the class's underlying specification. You use the UML's
graphical notation to
visualize a system; you use the UML's specification to state the system's details. Given this
split, it's possible to build up a model incrementally by drawing diagrams and then adding
semantics to the model's specifications, or directly by creating a specification, perhaps by
reverse engineering an existing system, and then creating diagrams that are projections into
those specifications.
The UML's specifications provide a semantic backplane that contains all the parts of all the
models of a system, each part related to one another in a consistent fashion. The UML's
diagrams are thus simply visual projections into that backplane, each diagram revealing a
specific interesting aspect of the system.
Adornments
Most elements in the UML have a unique and direct graphical notation that provides a visual
representation of the most important aspects of the element. For example, the notation for a
class is intentionally designed to be easy to draw, because classes are the most common
element found in modeling object-oriented systems. The class notation also exposes the most
important aspects of a class, namely its name, attributes, and operations.
A class's specification may include other details, such as whether it is abstract or the visibility
of its attributes and operations. Many of these details can be rendered as graphical or textual
adornments to the class's basic rectangular notation. For example, Figure 2-18 shows a class,
adorned to indicate that it is an abstract class with two public, one protected, and one private
operation.
Adornments
Every element in the UML's notation starts with a basic symbol, to which can be added a
variety of adornments specific to that symbol.
Common Divisions
In modeling object-oriented systems, the world often gets divided in several ways.
First, there is the division of class and object. A class is an abstraction; an object is one
concrete manifestation of that abstraction. In the UML, you can model classes as well as
objects, as shown in Figure 2-19. Graphically, the UML distinguishes an object by using the
same symbol as its class and then simply underlying the object's name.
Figure 2-19. Classes and Objects
In this figure, there is one class, named Customer, together with three objects: Jan (which is
marked explicitly as being a Customer object), :Customer (an anonymous Customer object),
and Elyse (which in its specification is marked as being a kind of Customer object, although
it's not shown explicitly here).
Almost every building block in the UML has this same kind of class/object dichotomy. For
example, you can have use cases and use case executions, components and component
instances, nodes and node instances, and so on.
In this figure, there is one component named SpellingWizard.dll that provides (implements)
two interfaces, IUnknown and ISpelling. It also requires an interface, IDictionary, that must be
provided by another component.
Almost every building block in the UML has this same kind of interface/implementation
dichotomy. For example, you can have use cases and the collaborations that realize them, as
well as operations and the methods that implement them.
Third, there is the separation of type and role. The type declares the class of an entity, such as
an object, an attribute, or a parameter. A role describes the meaning of an entity within its
context, such as a class, component, or collaboration. Any entity that forms part of the
structure of another entity, such as an attribute, has both characteristics: It derives some of its
meaning from its inherent type and some of its meaning from its role within its context (Figure
2-21).
Extensibility Mechanisms
The UML provides a standard language for writing software blueprints, but it is not possible
for one closed language to ever be sufficient to express all possible nuances of all models
across all domains across all time. For this reason, the UML is opened-ended, making it
possible for you to extend the language in controlled ways. The UML's extensibility
mechanisms include
Stereotypes
Tagged
values
Constraints
A stereotype extends the vocabulary of the UML, allowing you to create new kinds of building
blocks that are derived from existing ones but that are specific to your problem. For example,
if you are working in a programming language, such as Java or C++, you will often want to
model exceptions. In these languages, exceptions are just classes, although they are treated in
very special ways. Typically, you only want to allow them to be thrown and caught, nothing
else. You can make exceptions first-class citizens in your modelsmeaning that they are treated
like basic building blocksby marking them with an appropriate stereotype, as for the class
Overflow in Figure 2-19.
A tagged value extends the properties of a UML stereotype, allowing you to create new
information in the stereotype's specification. For example, if you are working on a
shrink-
wrapped product that undergoes many releases over time, you often want to track the version
and author of certain critical abstractions. Version and author are not primitive UML concepts.
They can be added to any building block, such as a class, by introducing new tagged values to
that building block. In Figure 2-19, for example, the class EventQueue is extended by marking
its version and author explicitly.
A constraint extends the semantics of a UML building block, allowing you to add new rules or
modify existing ones. For example, you might want to constrain the EventQueue class so that
all additions are done in order. As Figure 2-22 shows, you can add a constraint that explicitly
marks these for the operation add.
Collectively, these three extensibility mechanisms allow you to shape and grow the UML to
your project's needs. These mechanisms also let the UML adapt to new software technology,
such as the likely emergence of more powerful distributed programming languages. You can
add new building blocks, modify the specification of existing ones, and even change their
semantics. Naturally, it's important that you do so in controlled ways so that through these
extensions, you remain true to the UML's purpose the communication of information.
Architecture:
Any real world system is used by different users. The users can be developers, testers, business
people, analysts and many more. So before designing a system the architecture is made with
different perspectives in mind. The most important part is to visualize the system from
different viewer.s perspective. The better we understand the better we make the system.
Design View ,Implementation view, Process View, Deployment View and Usecase
View
And the centre is the Use Case view which connects all these four. A Use case represents
the functionality of the system. So the other perspectives are connected with use case.
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.
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.
Object-Oriented Concepts
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.
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.