3…

Introduction to UML
Concept of UML
UML is a standard language for specifying, visualizing, constructing, and documenting the artifacts of
software systems. UML was created by the Object Management Group (OMG) and UML 1.0
specification draft was proposed to the OMG in January 1997. OMG is continuously making efforts to
create a truly industry standard.

 UML stands for Unified Modeling Language.

 UML is different from the other common programming languages such as C++, Java, COBOL, etc.

 UML is a pictorial language used to make software blueprints.

 UML can be described as a general purpose visual modeling language to visualize, specify,
construct, and document software system.

 Although UML is generally used to model software systems, it is not limited within this boundary.
It is also used to model non-software systems as well. For example, the process flow in a
manufacturing unit, etc.

UML is not a programming language but tools can be used to generate code in various languages
using UML diagrams. UML has a direct relation with object oriented analysis and design. After some
standardization, UML has become an OMG standard.

Goals of UML
A picture is worth a thousand words, this idiom absolutely fits describing UML. Objectoriented
concepts were introduced much earlier than UML. At that point of time, there were no standard
methodologies to organize and consolidate the object-oriented development. It was then that UML
came into picture. There are a number of goals for developing UML but the most important is to
define some general purpose modeling language, which all modelers can use and it also needs to be
made simple to understand and use. 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 system. Thus it must be clear that UML is not a development method
rather it accompanies with processes to make it a successful system. In conclusion, the goal of UML
can be defined as a simple modeling mechanism to model all possible practical systems in today’s
complex environment.
A Conceptual Model of UML
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

The building blocks of UML can be defined as:

 Things

 Relationships

 Diagrams

Things

Things are the most important building blocks of UML.

Things can be:

 Structural

 Behavioral

 Grouping

 Annotational

Structural Things

Structural things define the static part of the model. They represent the physical and conceptual
elements. Following are the brief descriptions of the structural things.

Class: Class represents a set of objects having similar responsibilities.

Interface: Interface defines a set of operations, which specify the responsibility of a class.

UML ─ Building Blocks UML

Collaboration: Collaboration defines an interaction between elements.

Component: Component describes the physical part of a system.

Node: A node can be defined as a physical element that exists at run time.

Behavioral Things

A behavioral thing consists of the dynamic parts of UML models.

Following are the behavioral things:

Interaction: Interaction is defined as a behavior that consists of a group of messages exchanged

State machine: State machine is useful when the state of an object in its life cycle is important. It
defines the sequence of states an object goes through in response to events.

Grouping Things

Grouping things can be defined as a mechanism to group elements of a UML model together. There
is only one grouping thing available:

Package: Package is the only one grouping thing available for gathering structural and behavioral
things.

Annotational Things

Annotational things can be defined as a mechanism to capture remarks, descriptions, and

Relationships
Relationship is another most important building block of UML. It shows how the elements are
associated with each other and this association describes the functionality of an application. There
are four kinds of relationships available.

Dependency

Dependency is a relationship between two things in which change in one element also affects the
other.

Association

Association is basically a set of links that connects the elements of a UML model. It also describes
how many objects are taking part in that relationship.

Generalization
Generalization can be defined as a relationship which connects a specialized element with a
generalized element. It basically describes the inheritance relationship in the world of objects.

Realization

Realization can be defined as a relationship in which two elements are connected. One element
describes some responsibility, which is not implemented and the other one implements them. This
relationship exists in case of interfaces.

Architecture
Visualizing, specifying, constructing, and documenting a software-intensive system demands that the
system be viewed from a number of perspectives. Different stakeholders

• end users, analysts, developers, system integrators, testers, technical writers, and project
managers

• each bring different agendas to a project, and each looks at that system in different ways at
different times over the project's life.

A system's architecture is perhaps the most important artifact that can be used to manage these
different viewpoints and so control the iterative and incremental development of a system
throughout its life cycle.

Architecture is the set of significant decisions about ·

The organization of a software system ·

The selection of the structural elements and their interfaces by which the system is composed ·

Their behavior, as specified in the collaborations among those elements ·

The composition of these structural and behavioral elements into progressively larger subsystems

· The architectural style that guides this organization: the static and dynamic elements and their
interfaces, their collaborations, and their composition Software architecture is not only concerned
with structure and behavior, but also with usage, functionality, performance, resilience, reuse,
comprehensibility, economic and technology.

The use case view of a system encompasses the use cases that describe the behavior of the system
as seen by its end users, analysts, and testers. This view doesn't really specify the organization of a
software system. Rather, it exists to specify the forces that shape the system's architecture. With the
UML, the static aspects of this view are captured in use case diagrams; the dynamic aspects of this
view are captured in interaction diagrams, statechart diagrams, and activity diagrams.

The design view of a system encompasses the classes, interfaces, and collaborations that form the
vocabulary of the problem and its solution. This view primarily supports the functional requirements
of the system, meaning the services that the system should provide to its end users. With the UML,
the static aspects of this view are captured in class diagrams and object diagrams; the dynamic
aspects of this view are captured in interaction diagrams, statechart diagrams, and activity diagrams.

The process view of a system encompasses the threads and processes that form the system's
concurrency and synchronization mechanisms. This view primarily addresses the performance,
scalability, and throughput of the system. With the UML, the static and dynamic aspects of this view
are captured in the same kinds of diagrams as for the design view, but with a focus on the active
classes that represent these threads and processes.

The implementation view of a system encompasses the components and files that are used to
assemble and release the physical system. This view primarily addresses the configuration
management of the system's releases, made up of somewhat independent components and files
that can be assembled in various ways to produce a running system. With the UML, the static
aspects of this view are captured in component diagrams; the dynamic aspects of this view are
captured in interaction diagrams, statechart diagrams, and activity diagrams.

The deployment view of a system encompasses the nodes that form the system's hardware topology
on which the system executes. This view primarily addresses the distribution, delivery, and
installation of the parts that make up the physical system. With the UML, the static aspects of this
view are captured in deployment diagrams; the dynamic aspects of this view are captured in
interaction diagrams, statechart diagrams, and activity diagrams.