Conceptual Model of the Unified

Modeling Language (UML)

The Unified Modeling Language (UML) is a standard visual language for describing
and modelling software blueprints. The UML is more than just a graphical language.
Stated formally, the UML is for: Visualizing, Specifying, Constructing, and
Documenting.
The artifacts of a software-intensive system (particularly systems built using the
object-oriented style).
Three Aspects of UML:

Figure – Three Aspects of UML

Note – Language, Model, and Unified are the important aspect of UML as described
in the map above.
1. Language:
 It enables us to communicate about a subject which includes the requirements
and the system.
 It is difficult to communicate and collaborate for a team to successfully develop
a system without a language.
2. Model:
 It is a representation of a subject.
 It captures a set of ideas (known as abstractions) about its subject.
3. Unified:
 It is to bring together the information systems and technology industry’s best
engineering practices.
 These practices involve applying techniques that allow us to successfully
develop systems.
A Conceptual Model:
A conceptual model of the language underlines the three major elements:
• The Building Blocks
• The Rules
• Some Common Mechanisms
Once you understand these elements, you will be able to read and recognize the
models as well as create some of them.
Figure – A Conceptual Model of the UML
Building Blocks:
The vocabulary of the UML encompasses three kinds of building blocks:
1. Things:
Things are the abstractions that are first-class citizens in a model; relationships tie
these things together; diagrams group interesting collections of things.
There are 4 kinds of things in the UML:
1. Structural things
2. Behavioral things
3. Grouping things
4. Annotational things
These things are the basic object-oriented building blocks of the UML. You use
them to write well-formed models.
2. Relationships:
There are 4 kinds of relationships in the UML:
1. Dependency
2. Association
3. Generalization
4. Realization
These relationships are the basic relational building blocks of the UML.
3. Diagrams:
It is the graphical presentation of a set of elements. It is rendered as a connected
graph of vertices (things) and arcs (relationships).
1. Class diagram
2. Object diagram
3. Use case diagram
4. Sequence diagram
5. Collaboration diagram
6. Statechart diagram
7. Activity diagram
8. Component diagram
9. Deployment diagram
Rules:
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.
The UML has semantic rules for:
1. Names – What you can call things, relationships, and diagrams.
2. Scope – The context that gives specific meaning to a name.
3. Visibility – How those names can be seen and used by others.
4. Integrity – How things properly and consistently relate to one another.
5. Execution – What it means to run or simulate a dynamic model.
Common Mechanisms:
The UML is made simpler by the four common mechanisms. They are as follows:
1. Specifications
2. Adornments
3. Common divisions
4. Extensibility mechanisms

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.

Collaboration −Collaboration defines an interaction between elements.

Use case −Use case represents a set of actions performed by a system

for a specific goal.

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 among elements to accomplish a
specific task.

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. Events are external factors
responsible for state change

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 comments of UML model
elements. Note - It is the only one Annotational thing available. A
note is used to render comments, constraints, etc. of an UML
element.

UML - Behavioral Diagram vs Structural Diagram

The Unified Modeling Language is a standardized general-purpose modeling
language and nowadays is managed as a de facto industry standard by the Object
Management Group (OMG). The creation of UML was originally motivated
by the desire to standardize the disparate notational systems and approaches to
software design. It was developed by Grady Booch, Ivar Jacobson, and James
Rumbaugh at Rational Software in 1994–1995, with further development led by
them through 1996.
Static vs Dynamic View
Static modeling is used to specify the structure of the objects, classes or
components that exist in the problem domain. These are expressed using class,
object or component. While dynamic modeling refers to representing the object
interactions during runtime. It is represented by sequence, activity, collaboration,
and state. UML diagrams represent these two aspects of a system:
 Structural (or Static) view: emphasizes the static structure of the system
using objects, attributes, operations and relationships. It includes class
diagrams and composite structure diagrams.
 Behavioral (or Dynamic) view: emphasizes the dynamic behavior of the
system by showing collaborations among objects and changes to the
internal states of objects. This view includes sequence diagrams, activity
diagrams, and state machine diagrams.
In UML 2.2 there are 14 types of UML diagrams, which are divided into these
two categories:
 7 diagram types represent structural information

 Another 7 represents general UML diagram types for behavioral modeling,

including four that represent different aspects of interactions.
These diagrams can be categorized hierarchically as shown in the following UML
diagram map:
Structural Diagrams
Structure diagrams depict the static structure of the elements in your system. i.e.,
how one object relates to another. It shows the things in the system – classes,
objects, packages or modules, physical nodes, components, and interfaces. For
example, just as the static aspects of a house encompass the existence and
placement of such things as walls, doors, windows, pipes, wires, and vents. The
Seven UML structural diagrams are roughly organized around the major groups
of things you’ll find when modeling a system.
Since structure diagrams represent the structure, they are used extensively in
documenting the software architecture of software systems.
For example, the component diagram describes how a software system is split up
into components and shows the dependencies among these components.
Structural Diagram Brief Description
 It shows a set of nodes and their relationships that illustrates
Deployment Diagram
the static deployment view of an architecture.
It groups related UML elements into a collection of
Package Diagram
logically related UML structure.
It shows a set of classes, interfaces, and collaborations and
Class Diagram their relationships, typically, found in modeling object-
oriented systems.
It shows a set of objects and their relationships, which is the
Object Diagram static snapshots of instances of the things found in class
diagrams.
It shows a set of components and their relationships that
Component Diagram
illustrates the static implementation view of a system.

Behavioral Diagrams
UML’s five behavioral diagrams are used to visualize, specify, construct, and
document the dynamic aspects of a system. It shows how the system behaves and
interacts with itself and other entities (users, other systems). They show how data
moves through the system, how objects communicate with each other, how the
passage of time affects the system, or what events cause the system to change
internal states. Since behavior diagrams illustrate the behavior of a system, they
are used extensively to describe the functionality of software systems. As an
example, the activity diagram describes the business and operational step-by-step
activities of the components in a system.
In other words, a behavioral diagram shows how the system works ‘in motion’,
that is how the system interacts with external entities and users, how it responds
to input or event and what constraints it operates under. There are seven
behavioral diagrams that you can model the dynamics of a system as listed in the
Table below:
Behavioral Diagram Brief Description
It is a graphical representations of workflows of stepwise
Activity Diagram
activities and actions with support for choice, iteration and
 concurrency
It describes a system’s functional requirements in terms of
Use Case Diagram use cases that enable you to relate what you need from a
system to how the system delivers on those needs.
It shows the discrete behavior of a part of a designed
State Machine Diagram
system through finite state transitions.
It shows the sequence of messages exchanged between the
Sequence Diagram objects needed to carry out the functionality of the
scenario.
It shows interactions between objects and/or parts
Communication Diagram (represented as lifelines) using sequenced messages in a
free-form arrangement.
Interaction Overview It depicts a control flow with nodes that can
Diagram contain other interaction diagrams.
It shows interactions when the primary purpose of the
diagram is to reason about time by focusing on conditions
Timing Diagram
changing within and among lifelines along a linear time
axis.

What are the six types of relationships in UML class diagrams?

There are six main types of relationships between classes: inheritance , realization /
implementation , composition , aggregation , association, and dependency . The arrows for the
six relationships are as follows:

Then we come to understand the specific content of the class relationship.

 Six types of relationships

In the six types of relationships, the code structure of the three types of
relationships such as composition , aggregation , and association is the same as
using attributes to store the references of another class. Therefore, they must be
distinguished by the relationship between the contents.

Inheritance

Inheritance is also called generalization and is used to describe the relationship

between parent and child classes. A parent class is also called a base class, and a
subclass is also called a derived class.
In the inheritance relationship, the subclass inherits all the functions of the parent
class, and the parent class has all the attributes, methods, and subclasses.
Subclasses contain additional information in addition to the same information as
the parent class.
For example: buses, taxis, and cars are cars, they all have names, and they can all
be on the road.

Realization / Implementation

Implementation (Implementation) is mainly used to specify the relationship

between interfaces and implementation classes .
An interface (including an abstract class ) is a collection of methods. In an
implementation relationship, a class implements an interface, and methods in the
class implement all methods of the interface declaration.
For example: cars and ships are vehicles, and the vehicle is just an abstract concept
of a mobile tool, and the ship and the vehicle realize the specific mobile functions.

Composition relationship

Composition: The relationship between the whole and the part, but the whole
and the part cannot be separated .
The combination relationship represents the relationship between the whole and
part of the class, and the overall and part have a consistent lifetime. Once the
overall object does not exist, some of the objects will not exist, and they will all die
in the same life.For example, a person is composed of a head and a body. The two
are inseparable and coexist.

Aggregation Relationship

Aggregation: The relationship between the whole and part, and the whole and
part can be separated.
Aggregate relations also represent the relationship between the whole and part of
the class, member objects are part of the overall object, but the member object can
exist independently from the overall object.
For example, bus drivers and work clothes and hats are part of the overall
relationship, but they can be separated. Work clothes and hats can be worn on
other drivers. Bus drivers can also wear other work clothes and hats.

EDIT THIS TEMPLATE

Association Relationships

Association: Indicates that a property of a class holds a reference to an instance

(or instances) of another class .
Association is the most commonly used relationship between a class and a class,
which means that there is a connection between one type of object and another
type of object. Combinations and aggregations also belong to associative
relations , but relations between classes of affiliations are weaker than the other
two.
There are four kinds of associations : two-way associations , one-way
associations , self-association , and multiple-number associations .
For example: cars and drivers, one car corresponds to a particular driver, and one
driver can drive multiple cars.

In UML diagrams, bidirectional associations can have two arrows or no arrows ,

and one-way associations or self-associations have an arrow .
In a multiplicity relationship, you can add a number directly to the associated line
to indicate the number of objects in the corresponding class.
1..1: Only one
 0..*: Zero or more
1..*:one or more
0..1: No or only one
m..n: at least m, at most n (m<=n)

Dependencies
Dependence: Assume that a change in class A causes a change in class B, then say that class B
depends on class A.
In most cases, dependencies are reflected in methods of a class that use another class’s
object as a parameter .
A dependency relationship is a “use” relationship. A change in a particular thing may affect other
things that use it, and use a dependency when it is necessary to indicate that one thing uses
another.For example: The car relies on gasoline. If there is no gasoline, the car will not be able to
drive

What is UML Extensibility Mechanism?

The UML is a general-purpose, tool-supported, and standardized modeling
language that is used in order to specify, visualize, construct and document all the
elements of a wide range of system intensive processes. It promotes a use case
driven, architecture-centric, iterative and incremental process, which is object-
oriented and component-based. The UML is broadly applicable to different types
of systems, domains, methods and processes, which is why it is such a popular
and broadly used language.
However, even though the UML is very well-defined, there might be situations in
which you might find yourself wanting to bend or extend the language in some
controlled way to tailor it to your specific problem domain in order to simplify
the communication of your objective. This is where the UML extension
mechanisms come in.
The Three UML 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.
UML defines three extensibility mechanisms to allow modelers to add extensions
without having to modify the underlying modeling language. These three
mechanisms are:
 Stereotypes

 Constraints
 tagged values
Stereotypes
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.
They are used for classifying or marking the UML building blocks in order to
introduce new building blocks that speak the language of your domain and that
look like primitive, or basic, model elements.

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 models, meaning that they are treated like basic
building blocks, by marking them with an appropriate stereotype, as for the class
Overflow as shown in the Figure below:

Model New types in UML

Another Example, an enumeration types, such as Coloroolean and Status, can be
modeled as enumerations, with their individual values provided as attributes:

Model Special Relationship

A dependency can have a name, although names are rarely needed unless you
want to use stereotypes to distinguish different flavors of dependencies. For
example:

Tagged Values
A tagged value extends the properties of a UML building block, allowing you to
create new information in that element’s specification. They are properties for
specifying keyword-value pairs of model elements, where the keywords are
attributes. They allow you to extend the properties of a UML building block so
that you create new information in the specification of that element. Tagged
Values can be defined for existing model elements, or for individual stereotypes
so that everything with that stereotype has that tagged value. It is important to
mention that a tagged value is not equal to a class attribute. Instead, you can
regard a tagged value as being metadata, since its value applies to the element
itself and not to its instances.
Graphically, a tagged value is rendered as a string enclosed by brackets, which is
placed below the name of another model element. The string consists of a name
(the tag), a separator (the symbol =), and a value (of the tag) as shown in the
Figure below:

You can specify just the value if its meaning is unambiguous, such as when the
value is the name of the enumeration.
Usage of Tagged Values
One of the most common uses of a tagged value is to specify properties that are
relevant to code generation or configuration management. So, for example, you
can make use of a tagged value in order to specify the programming language to
which you map a particular class, or you can use it to denote the author and the
version of a component.
Tagged Value Example – Configuration Management System
Suppose you want to tie the models you create to your project’s configuration
management system. Among other things, this means keeping track of the version
number, current check-in/check out status, and perhaps even the creation and
modification dates of each subsystem. Because this is process-specific
information, it is not a basic part of the UML, although you can add this
information as tagged values. Furthermore, this information is not just a class
attribute either. A subsystem’s version number is part of its metadata, not part of
the model.
The Figure below shows four subsystems, each of which has been extended to
include its version number and status. In the case of the Billing subsystem, one
other tagged value is shown – the person who has currently checked out the
subsystem.

Constraints
A constraint is an extension of the semantics of a UML element, allowing you to
add new rules or to modify existing ones. They allow you to extend the semantics
of a UML building block by adding new rules or modifying existing ones. A
constraint specifies conditions that must be held true for the model to be well-
formed. This notation can also be used to adorn a model element’s basic notation,
in order to visualize parts of an element’s specification that have no graphical cue.
For example, you can use constraint notation to provide some properties of
associations, such as order and changeability
Graphically, a constraint is rendered as a string enclosed by brackets and placed
near the associated element or connected to that element or elements by
dependency relationships. The example below shows, you might want to specify
that, across a given association, communication is encrypted. Similarly, you
might want to specify that among a set of associations, only one is manifest at a
time.

Architecture of UML
A model is a way to represent a system. To envision a system, we will build
several models. Architecture is the collection of several views. The stakeholders
(end-users, analysts, developers, system integrators, testers, technical
writers, and project managers) of a project will be involved in different views.
Architecture is all about how a system is built at its highest level. It is necessary to
think large from multiple angles with high quality, productivity, and design in
mind. The software team is engaged in many practical matters, such as:

 The overall structure of the development team.

 The business needs.
  Development cycle.
 The observation of the structure itself.

Software architecture describes the parts included in the system, each function has
parts, and the relationship between these parts.
It is important to have well-formed software architecture, mainly for an extensive
software system. The software architect will consider a lot of factors to design the
architecture:

 Where will the system run?

 What will the system be used for?
 Who will be using the system?
 What quality matters to them?

Having a straight-forward design of a system as an initial point gives a strong basis

for developers to follow.
With a luminous architecture, it is easier to know where the primary
responsibilities are consisting within the system and where to compose changes to
add novel requirements or commonly fixing the bankruptcy. A software architect
will know how well things are related to each other and what needs to be enforced
efficiently. Software architecture provides high productivity to the software team,
and this can be an essential aspect for them. The software development becomes
more attractive as it represents a detailed structure in place to correspondent work,
implement individual features or ground discussion on probable issues.
In extension, the architecture will help out to attain affection in the software with a
well-designed framework using principles like the departure of concerns; the
system becomes more comfortable to sustain, restate, and readjust. The software
architecture is advantageous to many persons, such as the end-user, the client, the
software developer, and the project manager. Each one will have a distinct mindset
to view the system and will get a different plan for a project. It also serves as an
assemblage of several views. A beautiful gathering of these views is listed below:

 Use case view

 Design view
 Implementation view
 Process view
 Deployment view
Use case view
Use case views are advantageous to display the various requirements of the system.
The use case view contains the use case diagram. Also, it describes the
functionality of the system as anticipated by external actors very well. It will be
very easy to seizure the static aspects of the use case view in the use case diagram.
Use case view is mainly developed by analysts and domain experts. Dynamic
elements of this view are defined in statechart diagrams, interactive diagrams, and
activity diagrams.
Design view
Static structure and dynamic behavior view is used for showing the designation of
the functionality inside the system. It also shows the terminology of the problem
space and solution space. Static aspects of this view are recognized in class and
object diagrams in UML. Dynamic points of this view are abducted in statechart
diagrams, interaction diagrams, and activity diagrams.
Implementation view
The Implementation view means for the organization of the nucleus components
and files. It principally addresses the contour management of the system’s release.
Static facets of this view are conquered in component diagram. Dynamic aspects of
this view can be expressed in the statechart diagram, interaction diagram, and
activity diagram.
Process view
The process view displays the adequacy of the system. It consolidates the
processes and threads that can cause the concurrency of the system and
synchronization mechanisms. The system’s scalability, performance, throughput
can be addressed through this view. Static and dynamic aspects are represented
similarly as the design view, but more concerned about the active classes that
express these processes and threads.
Deployment view
This view demonstrates the deployment of the system in terms of environmental
architecture. It encompasses the nodes that cause the system’s hardware topology
over the system’s executes. Principally, it describes the installation, delivery, and
distribution of the components that design the physical system.