UNIT-IV

INTRODUCTION TO UML:
Importance of Modeling
We build models so that we can better understand the system we are developing.

Through modeling, we achieve four aims.

1. Models help us to visualize a system as it is or as we want it to be.

2. Models permit us to specify the structure or behavior of a system.
3. Models give us a template that guides us in constructing a system.
4. Models document the decisions we have made
Modeling is not just for big systems. Even the software equivalent of a dog house can
benefit from some modeling. However, it's definitely true that the larger and more complex the
system, the more important modeling becomes, for one very simple reason:

We build models of complex systems because we cannot comprehend such a

system in its entirety.

There are limits to the human ability to understand complexity. Through modeling, we
narrow the problem we are studying by focusing on only one aspect at a time. This is essentially
the approach of "divide-and-conquer" that Edsger Dijkstra spoke of years ago: Attack a hard
problem by dividing it into a series of smaller problems that you can solve. Furthermore, through
modeling, we amplify the human intellect. A model properly chosen can enable the modeler to
work at higher levels of abstraction.
The operative word here is "formal." In reality, in even the simplest project, developers do
some amount of modeling, albeit very informally. A developer might sketch out an idea on a
blackboard or a scrap of paper in order to visualize a part of a system, or the team might use CRC
cards to work through a scenario or the design of a mechanism. There's nothing wrong with any
of these models. If it works, by all means use it. However, these informal models are often ad hoc
and do not provide a common language that can easily be shared with others. Just as there exists a
common language of blueprints for the construction industry, a common language for electrical
engineering, and a common language for mathematical modeling, so too can a development
organization benefit by using a common language for software modeling.

Principles of Modeling
The use of modeling has a rich history in all the engineering disciplines. That experience suggests
four basic principles of modeling.
1. The choice of what models to create has a profound influence on how a problem is attacked
and how a solution is shaped.
2. Every model may be expressed at different levels of precision.
3. The best models are connected to reality.
4. No single model is sufficient. Every nontrivial system is best appro2.ached through a small
set of nearly independent models.
Depending on the nature of the system, some models may be more important than others. For
example, in data-intensive systems, models addressing static design views will dominate. In GUI
intensive systems, static and dynamic use case views are quite important. In hard real time systems,
dynamic process views tend to be more important. Finally, in distributed systems, such as one
finds in Web-intensive applications, implementation and deployment models are the most
important.

Object Oriented Modeling

In software, there are several ways to approach a model. The two most common ways are
from an algorithmic perspective and from an object-oriented perspective.

The traditional view of software development takes an algorithmic perspective. In this

approach, the main building block of all software is the procedure or function. This view leads
developers to focus on issues of control and the decomposition of larger algorithms into smaller
ones. There's nothing inherently evil about such a point of view except that it tends to yield brittle
systems. As requirements change (and they will) and the system grows (and it will), systems built
with an algorithmic focus turn out to be very hard to maintain.

The contemporary view of software development takes an object-oriented perspective. In

this approach, the main building block of all software systems is the object or class. Simply put,
an object is a thing, generally drawn from the vocabulary of the problem space or the solution
space; a class is a description of a set of common objects. Every object has identity (you can name
it or otherwise distinguish it from other objects), state (there's generally some data associated with
it), and behavior (you can do things to the object, and it can do things to other objects, as well).

For example, consider a simple three-tier architecture for a billing system, involving a user
interface, middleware, and a database. In the user interface, you will find concrete objects, such
as buttons, menus, and dialog boxes. In the database, you will find concrete objects, such as tables
representing entities from the problem domain, including customers, products, and orders. In the
middle layer, you will find objects such as transactions and business rules, as well as higher-level
views of problem entities, such as customers, products, and orders.

Conceptual model of UML

To understand the UML, you need to form a conceptual model of the language, and this
requires learning three major elements: the UML's basic building blocks, the rules that dictate how
those building blocks may be put together, and some common mechanisms that apply throughout
the UML. Once you have grasped these ideas, you will be able to read UML models and create
some basic ones. As you gain more experience in applying the UML, you can build on this
conceptual model, using more advanced features of the language.

Building Blocks of the UML

The vocabulary of the UML encompasses three kinds of building blocks:
1. Things
2. Relationships
 3. Diagrams

Things in the UML

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 four 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.

Relationships in the UML

There are four 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. You use them to write
well-formed models.
Diagrams in the UML
A diagram is the graphical presentation of a set of elements, most often rendered as a
connected graph of vertices (things) and arcs (relationships). You draw diagrams to visualize a
system from different perspectives, so a diagram is a projection into a system. For all but the most
trivial systems, a diagram represents an elided view of the elements that make up a system. The
same element may appear in all diagrams, only a few diagrams (the most common case), or in no
diagrams at all (a very rare case). In theory, a diagram may contain any combination of things
and relationships. In practice, however, a small number of common combinations arise, which are
consistent with the five most useful views that comprise the architecture of a software-intensive
system. For this reason, the UML includes nine such diagrams:
1. Class diagram
2. Object diagram
3. Use case diagram
4. Sequence diagram
5. Collaboration diagram
6. State chart diagram
7. Activity diagram
8. Component diagram
9. Deployment diagram
STRUCTURAL MODELING:
Classes
Classes are the most important building block of any object-oriented system. A class is a
description of a set of objects that share the same attributes, operations, relationships, and
semantics. A class implements one or more interfaces.
A class is a description of a set of objects that share the same attributes, operations, relationships,
and semantics. Graphically, a class is rendered as a rectangle.

Names
A class name must be unique within its enclosing package
Every class must have a name that distinguishes it from other classes. A name is a textual string.
That name alone is known as a simple name; a path name is the class name prefixed by the
name of the package in which that class lives. A class may be drawn showing only its name, as
Typically, you capitalize the first letter of every word in a class name, as in Customer or
TemperatureSensor. Figure 4-2 shows.

Figure 4-2 Simple and Path Names

Attributes
Attributes are related to the semantics of aggregation
An attribute is a named property of a class that describes a range of values that instances of the
property may hold. A class may have any number of attributes or no attributes at all. An attribute
represents some property of the thing you are modeling that is shared by all objects of that class.
For example, every wall has a height, width, and thickness; you might model your customers in
such a way that each has a name, address, phone number, and date of birth. An attribute is therefore,
an abstraction of the kind of data or state an object of the class might encompass. At a given
moment, an object of a class will have specific values for every one of its class's attributes.

Graphically, attributes are listed in a compartment just below the class name. Attributes may be
drawn showing only their names, Typically, you capitalize the first letter of every word in an
attribute name except the first letter, as in name or loadBearing.as shown in Figure 4-3.
 Figure 4-3 Attributes

Operations
You can further specify the implementation of an operation by using a note or by using an
activity diagram.
An operation is the implementation of a service that can be requested from any object of
the class to affect behavior. In other words, an operation is an abstraction of something you can do
to an object and that is shared by all objects of that class. A class may have any number of
operations or no operations at all. For example, in a windowing library such as the one found in
Java's awt package, all objects of the class Rectangle can be moved, resized, or queried for their
properties. Typically, you capitalize the first letter of every word in an operation name except the
first letter, as in move or isEmpty.
Relationships
In object-oriented modeling, there are three kinds of relationships that are especially
important: dependencies, which represent using relationships among classes (including
refinement, trace, and bind relationships); generalizations, which link generalized classes to their
specializations; and associations, which represent structural relationships among objects. Each of
these relationships provides a different way of combining your abstractions.
In the UML, the ways that things can connect to one another, either logically or physically,
are modeled as relationships. In object-oriented modeling, there are three kinds of relationships
that are most important: dependencies, generalizations, and associations.

Dependencies are using relationships. For example, pipes depend on the water heater to
heat the water they carry.

Generalizations connect generalized classes to more-specialized ones in what is known as

subclass/superclass or child/parent relationships. For example, a bay window is a kind of window
with large, fixed panes; a patio window is a kind of window with panes that open side to side.

Associations are structural relationships among instances. For example, rooms consist of
walls and other things; walls themselves may have embedded doors and windows; pipes may pass
through walls.

The UML provides a graphical representation for each of these kinds of relationships, as
Figure 5-1 shows. This notation permits you to visualize relationships apart from any specific
programming language, and in a way that lets you emphasize the most important parts of a
relationship: its name, the things it connects, and its properties.
Dependency
A dependency is a using relationship that states that a change in specification of one thing
(for example, class Event) may affect another thing that uses it (for example, class Window), but
not necessarily the reverse. Graphically, a dependency is rendered as a dashed directed line,
directed to the thing being depended on. Use dependencies when you want to show one thing using
another.
In the UML you can also create dependencies among many other things, especially notes
and packages.

Note
A dependency can have a name, although names are rarely needed unless you have a model with
many dependencies and you need to refer to or distinguish among dependencies. More commonly,
you'll use stereotypes to distinguish different flavors of dependencies.

Generalization
A generalization is a relationship between a general thing (called the superclass or parent)
and a more specific kind of that thing (called the subclass or child). Generalization is sometimes
called an "is-a-kind-of" relationship: one thing (like the class BayWindow) is-a-kind-of a more
general thing (for example, the class Window). Generalization means that objects of the child may
be used anywhere the parent may appear, but not the reverse. In other words, generalization means
that the child is substitutable for the parent. A child inherits the properties of its parents, especially
their attributes and operations. Often• but not always• the child has attributes and operations in
addition to those found in its parents. An operation of a child that has the same signature as an
operation in a parent overrides the operation of the parent; this is known as polymorphism.
Graphically, generalization is rendered as a solid directed line with a large open arrowhead,
pointing to the parent, as shown in Figure 5-3. Use generalizations when you want to show
parent/child relationships.

A class may have zero, one, or more parents. A class that has no parents and one or more
children is called a root class or a base class. A class that has no children is called a leaf class. A
class that has exactly one parent is said to use single inheritance; a class with more than one parent
is said to use multiple inheritance.

Note
A generalization can have a name, although names are rarely needed unless you have a
model with many generalizations and you need to refer to or discriminate among generalizations.

Association
Associations and dependencies (but not generalization relationships) may be reflective.
An association is a structural relationship that specifies that objects of one thing are
connected to objects of another. Given an association connecting two classes, you can navigate
from an object of one class to an object of the other class, and vice versa. It's quite legal to have
both ends of an association circle back to the same class. This means that, given an object of the
class, you can link to other objects of the same class. An association that connects exactly two
classes is called a binary association. Although it's not as common, you can have associations that
connect more than two classes; these are called n - ary associations. Graphically, an association is
rendered as a solid line connecting the same or different classes. Use associations when you want
to show structural relationships.
Name
An association can have a name, and you use that name to describe the nature of the relationship.
So that there is no ambiguity about its meaning, you can give a direction to the name by providing
a direction triangle that points in the direction you intend to read the name.

Note
Although an association may have a name, you typically don't need to include one if you explicitly
provide role names for the association, or if you have a model with many associations and you
need to refer to or distinguish among associations. This is especially true when you have more than
one association connecting the same classes.

Role
When a class participates in an association, it has a specific role that it plays in that
relationship; a role is just the face the class at the near end of the association presents to the class
at the other end of the association. You can explicitly name the role a class plays in an association.
In Figure , a Person playing the role of employee is associated with a Company playing the
role of employer.

Multiplicity
An association represents a structural relationship among objects. In many modeling
situations, it's important for you to state how many objects may be connected across an instance
of an association. This "how many" is called the multiplicity of an association's role, and is written
as an expression that evaluates to a range of values or an explicit value as in Figure. When you
state a multiplicity at one end of an association, you are specifying that, for each object of the class
at the opposite end, there must be that many objects at the near end. You can show a multiplicity
of exactly one (1), zero or one (0..1), many (0..*), or one or more (1..*). You can even state an
exact number (for example, 3).
Aggregation
A plain association between two classes represents a structural relationship between peers,
meaning that both classes are conceptually at the same level, no one more important than the other.
Sometimes, you will want to model a "whole/part" relationship, in which one class represents a
larger thing (the "whole"), which consists of smaller things (the "parts"). This kind of relationship
is called aggregation, which represents a "has-a" relationship, meaning that an object of the whole
has objects of the part. Aggregation is really just a special kind of association and is specified by
adorning a plain association with an open diamond at the whole end, as shown in Figure.

Advanced classes
Classes are indeed the most important building block of any object-oriented system.
However, classes are just one kind of an even more general building block in the UML• classifiers.
A classifier is a mechanism that describes structural and behavioral features. Classifiers include
classes, interfaces, datatypes, signals, components, nodes, use cases, and subsystems.
 Classifiers (and especially classes) have a number of advanced features beyond the simpler
properties of attributes and operations described in the previous section: You can model
multiplicity, visibility, signatures, polymorphism, and other characteristics. In the UML, you can
model the semantics of a class so that you can state its meaning to whatever degree of formality
you like.
In the UML, there are several kinds of classifiers and classes; it's important that you choose
the one that best models your abstraction of the real world.
The UML provides a representation for a number of advanced properties, as Figure shows.
This notation permits you to visualize, specify, construct, and document a class to any level of
detail you wish, even sufficient to support forward and reverse engineering of models and code.

Classifiers
When you model, you'll discover abstractions that represent things in the real world and
things in your solution. For example, if you are building a Web-based ordering system, the
vocabulary of your project will likely include a Customer class (representing people who order
products) and a Transaction class (an implementation artifact, representing an atomic action). In
the deployed system, you might have a Pricing component, with instances living on every client
node. Each of these abstractions will have instances; separating the essence and the instance of the
things in your world is an important part of modeling.

The most important kind of classifier in the UML is the class. A class is a description of a
set of objects that share the same attributes, operations, relationships, and semantics. Classes are
not the only kind of classifier, however. The UML provides a number of other kinds of
classifiers to help you model.

$ Interface A collection of operations that are used to specify a service of a class or a Component

$ Datatype A type whose values have no identity, including primitive built-in types (such as
numbers and strings), as well as enumeration types (such as Boolean)

$ Signal The specification of an asynchronous stimulus communicated between instances

$Component A physical and replaceable part of a system that conforms to and provides the
realization of a set of interfaces

$ Node A physical element that exists at run time and that represents a computational resource,
generally having at least some memory and often processing capability
$ Use case A description of a set of a sequence of actions, including variants, that a system
performs that yields an observable result of value to a particular actor

$Subsystem A grouping of elements of which some constitute a specification of the behavior

offered by the other contained elements

Visibility
One of the most important details you can specify for a classifier's attributes and operations is its
visibility. The visibility of a feature specifies whether it can be used by other classifiers. In the
UML, you can specify any of three levels of visibility.

1. public Any outside classifier with visibility to the given classifier can use the feature; specified
by prepending the symbol +

2. protected Any descendant of the classifier can use the feature; specified by prepending the
symbol #

3. private Only the classifier itself can use the feature; specified by prepending the symbol –
Scope
Another important detail you can specify for a classifier's attributes and operations is its owner
scope. The owner scope of a feature specifies whether the feature appears in each instance of the
classifier or whether there is just a single instance of the feature for all instances of the classifier.
In the UML, you can specify two kinds of owner scope.

1. instance Each instance of the classifier holds its own value for the feature.

2. classifier There is just one value of the feature for all instances of the classifier.

Advanced relationships
Dependencies, generalizations, and associations are the three most important relational
building blocks of the UML. These relationships have a number of properties beyond those
described in the previous section. You can also model multiple inheritance, navigation,
composition, refinement, and other characteristics. Using a fourth kind of relationship• realization•
you can model the connection between an interface and a class or component, or between a use
case and a collaboration. In the UML, you can model the semantics of relationships to any degree
of formality.
The UML provides a representation for a number of advanced properties, as Figure 10-1
shows. This notation permits you to visualize, specify, construct, and document webs of
relationships to any level of detail you wish, even sufficient to support forward and reverse
engineering of models and code.

Dependency

A dependency is a using relationship, specifying that a change in the specification of one

thing (for example, class SetTopController) may affect another thing that uses it (for example,
class ChannelIterator), but not necessarily the reverse. Graphically, a dependency is rendered as
a dashed line, directed to the thing that is depended on. Apply dependencies when you want to
show one thing using another.
First, there are eight stereotypes that apply to dependency relationships among classes and
objects in class diagrams.

1. Bind
2. Derive
3. Friend
4. Instanceof
5. Instantiate
6. Powertype
7. Refine
8. Use1.

Continuing, there are two stereotypes that apply to dependency relationships among
packages.
1. Access
2. Import

Two stereotypes apply to dependency relationships among use cases:

1. Extend
2. Include

You'll encounter three stereotypes when modeling interactions among objects.

1. Become
2. Call
3. Copy

One stereotype you'll encounter in the context of state machines is

1. Send

Finally, one stereotype that you'll encounter in the context of organizing the elements of
your system into subsystems and models is
1. Trace

Generalization
A generalization is a relationship between a general thing (called the superclass or parent)
and a more specific kind of that thing (called the subclass or child). For example, you might
encounter the general class Window with its more specific kind, MultiPaneWindow. With a
generalization relationship from the child to the parent, the child (MultiPaneWindow) will inherit
all the structure and behavior of the parent (Window). The child may even add new structure and
behavior, or it may modify the behavior of the parent. In a generalization relationship, instances
of the child may be used anywhere instances of the parent apply• meaning that the child is
substitutable for the parent.
Association
An association is a structural relationship, specifying that objects of one thing are
connected to objects of another. For example, a Library class might have a one-to-many
association to aBook class, indicating that each Book instance is owned by one Library instance.
Furthermore, given a Book, you can find its owning Library, and given a Library, you can navigate
to all its Books. Graphically, an association is rendered as a solid line connecting the same or
different classes. You use associations when you want to show structural relationships.

There are four basic adornments that apply to an association: a name, the role at each end
of the association, the multiplicity at each end of the association, and aggregation. For advanced
uses, there are a number of other properties you can use to model subtle details, such as navigation,
qualification, and various flavors of aggregation.

Interfaces, Types and Roles

In the UML, you use interfaces to model the seams in a system. An interface is collection
of operations used to specify a service of a class or a component. By declaring an interface, you
can state the desired behavior of an abstraction independent of an implementation of that
abstraction. Clients can build against that interface, and you can build or buy any implementation
of that interface, as long as the implementation satisfies the responsibilities and the contract
denoted by the interface.
Many programming languages support the concept of interfaces, including Java and CORBA
IDL. Interfaces are not only important for dividing the specification and the implementation of a
class or component, but as you scale up to larger systems, you can use interfaces to specify the
outside view of a package or subsystem.

The UML provides a graphical representation for interfaces, as Figure 11-1 shows. This notation
permits you to visualize the specification of an abstraction apart from any implementation.

An interface is a collection of operations that are used to specify a service of a class or a

component. A type is a stereotype of a class used to specify a domain of objects, together with the
operations (but not the methods) applicable to the object. A role is the behavior of an entity
participating in a particular context. Graphically, an interface is rendered as a circle; in its
expanded form, an interface may be rendered as a stereotyped class in order to expose its
operations and other properties.

Names
An interface name must be unique within its enclosing package. Every interface must
have a name that distinguishes it from other interfaces. A name is a textual string. That name
alone is known as a simple name; a path name is the interface name prefixed by the name of the
package in which that interface lives. An interface may be drawn showing only its name, as in
Figure
Operations
An interface is a named collection of operations used to specify a service of a class or of a
component. Unlike classes or types, interfaces do not specify any structure (so they may not
include any attributes), nor do they specify any implementation (so they may not include any
methods, which provide the implementation of an operation). Like a class, an interface may have
any number of operations. These operations may be adorned with visibility properties, concurrency
properties, stereotypes, tagged values, and constraints.

When you visualize an interface in its normal form as a circle, by definition, you suppress
the display of these operations. However, if it's important for your understanding of the current
model, you can render an interface as a stereotyped class, listing its operations in the appropriate
compartment. Operations may be drawn showing only their name, or they may be augmented to
show their full signature and other properties, as in Figure

Relationships
Like a class, an interface may participate in generalization, association, and dependency
relationships. In addition, an interface may participate in realization relationships. Realization is a
semantic relationship between two classifiers in which one classifier specifies a contract that
another classifier guarantees to carry out.
An interface specifies a contract for a class or a component without dictating its
implementation. A class or component may realize many interfaces. In so doing, it commits to
carry out all these contracts faithfully, which means that it provides a set of methods that properly
implement the operations defined in the interface. Similarly, a class or a component may depend
on many interfaces. In so doing, it expects that these contracts will be honored by some set of
components that realize them. This is why we say that an interface represents a seam in a system.
An interface specifies a contract, and the client and the supplier on each side of the contract may
change independently, as long as each fulfills its obligations to the contract.
Types and Roles
A class may realize many interfaces. An instance of that class must therefore support all
those interfaces, because an interface defines a contract, and any abstraction that conforms to that
interface must, by definition, faithfully carry out that contract. Nonetheless, in a given context,
an instance may present only one or more of its interfaces as relevant. In that case, each interface
represents a role that the object plays. A role names a behavior of an entity participating in a
particular context. Stated another way, a role is the face that an abstraction presents to the world.
Roles also play a part in collaborations.

For example, consider an instance of the class Person. Depending on the context, that
Person instance may play the role of Mother, Comforter, PayerOfBills, Employee, Customer,
Manager, Pilot, Singer, and so on. When an object plays a particular role, it presents a face to the
world, and clients that interact with it expect a certain behavior depending on the role that it
plays at the time. For example, an instance of Person in the role of Manager would present a
different set of properties than if the instance were playing the role of Mother.

In the UML, you can specify a role an abstraction presents to another abstraction by
adorning the name of an association end with a specific interface. For example, Figure 11-5
shows the interface Employee, whose definition includes three operations. There exists an
association between the classes Person and Company in which context Person plays the role e,
whose type is Employee. In a different association, the Person might present an entirely different
face to the world. With this explicit type, the role the Person plays is more than just a name
meaningful to the human reader of this diagram. In the UML, this means that the Person presents
the role of Employee to the Company, and in that context, only the properties specified by
Employee are visible and relevant to the Company.
Packages
In the UML, the chunks that organize a model are called packages. A package is a
generalpurpose mechanism for organizing elements into groups. Packages help you organize the
elements in your models so that you can more easily understand them. Packages also let you
control access to their contents so that you can control the seams in your system's architecture.

The UML provides a graphical representation of package, as Figure 12-1 shows. This
notation permits you to visualize groups of elements that can be manipulated as a whole and in a
way that lets you control the visibility of and access to individual elements.

A package is a general-purpose mechanism for organizing elements into groups.

Graphically, a package is rendered as a tabbed folder.

Names
A package name must be unique within its enclosing package.

Every package must have a name that distinguishes it from other packages. A name is a
textual string. That name alone is known as a simple name; a path name is the package name
prefixed by the name of the package in which that package lives, if any. A package is typically
drawn showing only its name, as in Figure 12-2. Just as with classes, you may draw packages
adorned with tagged values or with additional compartments to expose their details .
Visibility
You can control the visibility of the elements owned by a package just as you can control
the visibility of the attributes and operations owned by a class. Typically, an element owned by a
package is public, which means that it is visible to the contents of any package that imports the
element's enclosing package. Conversely, protected elements can only be seen by children, and
private elements cannot be seen outside the package in which they are declared. In Figure
OrderForm is a public part of the package Client, and Order is a private part. A package that
imports Client can see OrderForm, but it cannot see Order. As viewed from the outside, the fully
qualified name of OrderForm would be Client::OrderForm. You specify the visibility of an
element owned by a package by prefixing the element's name with an appropriate visibility symbol.
Public elements are rendered by prefixing their name with a + symbol, as for OrderForm in Figure
Collectively, the public parts of a package constitute the package's interface.

Packages that are friends to another may see all the elements of that package, no matter
what their visibility.

Generalization
There are two kinds of relationships you can have between packages: import and access
dependencies, used to import into one package elements exported from another, and
generalizations, used to specify families of packages.
Class diagrams
Class diagrams are the most common diagram found in modeling object- oriented systems.
A class diagram shows a set of classes, interfaces, and collaborations and their relationships.

You use class diagrams to model the static design view of a system. For the most part, this
involves modeling the vocabulary of the system, modeling collaborations, or modeling schemas.
Class diagrams are also the foundation for a couple of related diagrams: component diagrams and
deployment diagrams.

Class diagrams are important not only for visualizing, specifying, and documenting
structural models, but also for constructing executable systems through forward and reverse
engineering.

Class diagrams commonly contain the following things:

 Classes
 Interfaces
 Collaborations
 Dependency, generalization, and association relationships

Like all other diagrams, class diagrams may contain notes and constraints.
 Class diagrams may also contain packages or subsystems, both of which are used to group
elements of your model into larger chunks. Sometimes, you'll want to place instances in your
class diagrams, as well, especially when you want to visualize the (possibly dynamic) type of an
instance.

You use class diagrams to model the static design view of a system. This view primarily
supports the functional requirements of a system• the services the system should provide to its
end users. When you model the static design view of a system, you'll typically use class
diagrams in one of three ways.
1. To model the vocabulary of a system
2. To model simple collaborations
3. To model a logical database schema

Modeling the vocabulary of a system involves making a decision about which abstractions
are a part of the system under consideration and which fall outside its boundaries. You use class
diagrams to specify these abstractions and their responsibilities.

A collaboration is a society of classes, interfaces, and other elements that work together to
provide some cooperative behavior that's bigger than the sum of all the elements. For example,
when you're modeling the semantics of a transaction in a distributed system, you can't just stare at
a single class to understand what's going on. Rather, these semantics are carried out by a set of
classes that work together. You use class diagrams to visualize and specify this set of classes and
their relationships.
 Think of a schema as the blueprint for the conceptual design of a database. In many
domains, you'll want to store persistent information in a relational database or in an object-oriented
database. You can model schemas for these databases using class diagrams.

Forward and Reverse Engineering

Forward engineering is the process of transforming a model into code through a mapping
to an implementation language. Forward engineering results in a loss of information, because
models written in the UML are semantically richer than any current object-oriented programming
language. In fact, this is a major reason why you need models in addition to code. Structural
features, such as collaborations, and behavioral features, such as interactions, can be visualized
clearly in the UML, but not so clearly from raw code

All of these classes specify a mapping to Java, as noted in their tagged value. Forward
engineering the classes in this diagram to Java is straightforward, using a tool. Forward
engineering the class EventHandler yields the following code.
 public abstract class EventHandler
{
EventHandler successor;
private Integer currentEventID;
private String source;
EventHandler() {}
public void handleRequest() {}
}

Reverse engineering is the process of transforming code into a model through a mapping
from a specific implementation language. Reverse engineering results in a flood of information,
some of which is at a lower level of detail than you'll need to build useful models. At the same
time, reverse engineering is incomplete. There is a loss of information when forward engineering
models into code, and so you can't completely recreate a model from code unless your tools encode
information in the source comments that goes beyond the semantics of the implementation
language.

Object Diagrams
Object diagrams model the instances of things contained in class diagrams. An object
diagram shows a set of objects and their relationships at a point in time.

You use object diagrams to model the static design view or static process view of a system.
This involves modeling a snapshot of the system at a moment in time and rendering a set of objects,
their state, and their relationships.

Object diagrams are not only important for visualizing, specifying, and documenting
structural models, but also for constructing the static aspects of systems through forward and
reverse engineering.
Object diagrams commonly contain
 Objects
 Links

Like all other diagrams, object diagrams may contain notes and constraints.

Object diagrams may also contain packages or subsystems, both of which are used to group
elements of your model into larger chunks. Sometimes, you'll want to place classes in your object
diagrams, as well, especially when you want to visualize the classes behind each instance.

When you model the static design view or static process view of a system, you typically
use object diagrams in one way:
 To model object structures
 UNIT – V
BEHAVIORAL MODELING
Interaction Diagrams:

Introduction
In UML, the dynamic aspects of a system can be modeled using interactions. Interactions contain
messages that are exchanged between objects. A message can be an invocation of an operation or
a signal. The messages may also include creation and destruction of other objects.

We can use interactions to model the flow of control within an operation, a class, a component, a
use case or the system as a whole. Using interaction diagrams, we can model these flows in two
ways: one is by focusing on how the messages are dispatched across time and the second is by
focusing on the structural relationships between objects and then consider how the messages are
passed between the objects.

Graphically a message is rendered as a directed line with the name of its operation as show
below:
Interaction (Definition)
An interaction is a behavior that contains a set of messages exchanged among a set of objects
within a context to accomplish a purpose. A message is specification of a communication
between objects that conveys information with the expectation that the activity will succeed.

Objects and Roles

The objects that participate in an interaction are either concrete things or prototypical things. As
a concrete thing, an object represents something in the real world. For example, p an instance of
the class Person, might denote a particular human. Alternately, as a prototypical thing, p might
represent any instance of Person.

Links
A link is a semantic connection among objects. In general, a link is an instance of association.
Wherever, a class has an association with another class, there may be a link between the
instances of the two classes.

Wherever there is a link between two objects, one object can send messages to another object.
We can adorn the appropriate end of the link with any of the following standard stereotypes:
Messages
A message is the specification of communication among objects that conveys information with
the expectation that activity will succeed. The receipt of a message instance may be considered
an instance of an event.

When a message is passed, the action that results is an executable statement that forms an
abstraction of a computational procedure. An action may result in a change of state. In UML, we
can model several kinds of actions like:
Sequencing
When an object passes a message to another object, the receiving object might in turn send a
message to another object, which might send a message to yet a different object and so on.

This stream of messages forms a sequence. So, we can define a sequence as a stream of
messages. Any sequence must have a beginning. The start of every sequence is associated with
some process or thread.

To model the sequence of a message, we can explicitly represent the order of the message
relative to the start of the sequence by prefixing the message with a sequence number set apart
by a colon separator.

Most commonly, we can specify a procedural or nested flow of control, rendering using a filled
solid arrowhead. Less common but also possible, you can specify a flat flow of control, rendered
using a stick arrowhead.

We will use flat sequences only when modeling interactions in the context of use cases that
involve the system as a whole, together with actors outside the system.

In all other cases, we will use procedural sequences, because they represent ordinary, nested
operation calls of the type we find in most programming languages.
Representation
When we model an interaction, we typically include both objects and messages. We can
visualize those objects and messages involved in an interaction in two ways: by emphasizing the
time ordering of messages and by emphasizing the structural organization of the objects that send
and receive messages.

Use Case Diagrams:

What is the Use Case Diagram?
Use Case Diagram captures the system's functionality and requirements by using
actors and use cases. Use Cases model the services, tasks, function that a system
needs to perform. Use cases represent high-level functionalities and how a user will
handle the system. Use-cases are the core concepts of Unified Modelling language
modeling.

Why Use-Case diagram?

A Use Case consists of use cases, persons, or various things that are invoking the
features called as actors and the elements that are responsible for implementing the
use cases. Use case diagrams capture the dynamic behaviour of a live system. It
models how an external entity interacts with the system to make it work. Use case
diagrams are responsible for visualizing the external things that interact with the part
of the system.

Use-case diagram notations

Following are the common notations used in a use case diagram:

Use-case:

Use cases are used to represent high-level functionalities and how the user will handle
the system. A use case represents a distinct functionality of a system, a component, a
package, or a class. It is denoted by an oval shape with the name of a use case written
inside the oval shape. The notation of a use case in UML is given below:

UML UseCase Notation

Actor:

It is used inside use case diagrams. The actor is an entity that interacts with the
system. A user is the best example of an actor. An actor is an entity that initiates the
use case from outside the scope of a use case. It can be any element that can trigger an
interaction with the use case. One actor can be associated with multiple use cases in
the system. The actor notation in UML is given below.
 UML Actor Notation

How to draw a use-case diagram?

To draw a use case diagram in UML first one need to analyse the entire system
carefully. You have to find out every single function that is provided by the system.
After all the functionalities of a system are found out, then these functionalities are
converted into various use cases which will be used in the use case diagram.

A use case is nothing but a core functionality of any working system. After organizing
the use cases, we have to enlist the various actors or things that are going to interact
with the system. These actors are responsible for invoking the functionality of a
system. Actors can be a person or a thing. It can also be a private entity of a system.
These actors must be relevant to the functionality or a system they are interacting
with.

After the actors and use cases are enlisted, then you have to explore the relationship of
a particular actor with the use case or a system. One must identify the total number of
ways an actor could interact with the system. A single actor can interact with multiple
use cases at the same time, or it can interact with numerous use cases simultaneously.

Following rules must be followed while drawing use-case for any system:

1. The name of an actor or a use case must be meaningful and relevant to the
system.
2. Interaction of an actor with the use case must be defined clearly and in an
understandable way.
3. Annotations must be used wherever they are required.
4. If a use case or an actor has multiple relationships, then only significant
interactions must be displayed.

Tips for drawing a use-case diagram

 1. A use case diagram should be as simple as possible.
2. A use case diagram should be complete.
3. A use case diagram should represent all interactions with the use case.
4. If there are too many use cases or actors, then only the essential use cases
should be represented.
5. A use case diagram should describe at least a single module of a system.
6. If the use case diagram is large, then it should be generalized.

An example of a use-case diagram

Following use case diagram represents the working of the student management
system:

UML UseCase Diagram

In the above use case diagram, there are two actors named student and a teacher.
There are a total of five use cases that represent the specific functionality of a student
management system. Each actor interacts with a particular use case. A student actor
can check attendance, timetable as well as test marks on the application or a system.
This actor can perform only these interactions with the system even though other use
cases are remaining in the system.
It is not necessary that each actor should interact with all the use cases, but it can
happen.

The second actor named teacher can interact with all the functionalities or use cases of
the system. This actor can also update the attendance of a student and marks of the
student. These interactions of both student and a teacher actor together sums up the
entire student management application.

When to use a use-case diagram?

A use case is a unique functionality of a system which is accomplished by a user. A
purpose of use case diagram is to capture core functionalities of a system and
visualize the interactions of various things called as actors with the use case. This is
the general use of a use case diagram.

The use case diagrams represent the core parts of a system and the workflow between
them. In use case, implementation details are hidden from the external use only the
event flow is represented.

With the help of use case diagrams, we can find out pre and post conditions after the
interaction with the actor. These conditions can be determined using various test
cases.

In general use case diagrams are used for:

1. Analyzing the requirements of a system

2. High-level visual software designing
3. Capturing the functionalities of a system
4. Modeling the basic idea behind the system
5. Forward and reverse engineering of a system using various test cases.

Use cases are intended to convey desired functionality so the exact scope of a use case
may vary according to the system and the purpose of creating UML model.

Summary
 Use case diagrams are a way to capture the system's functionality and
requirements in UML diagrams.
 It captures the dynamic behavior of a live system.
 A use case diagram consists of a use case and an actor.
 A use case represents a distinct functionality of a system, a component, a
package, or a class.
  An actor is an entity that initiates the use case from outside the scope of a use
case.
 The name of an actor or a use case must be meaningful and relevant to the
system.
 A purpose of use case diagram is to capture the core functionalities of a system.

Activity Diagrams:
What is an Activity Diagram?
Activity diagram is defined as a UML diagram that focuses on the execution and flow
of the behavior of a system instead of implementation. It is also called object-
oriented flowchart. Activity diagrams consist of activities that are made up of actions
which apply to behavioral modeling technology.

Components of Activity Diagram

Activities
It is a behavior that is divided into one or more actions. Activities are a network of
nodes connected by edges. There can be action nodes, control nodes, or object nodes.
Action nodes represent some action. Control nodes represent the control flow of an
activity. Object nodes are used to describe objects used inside an activity. Edges are
used to show a path or a flow of execution. Activities start at an initial node and
terminate at a final node.
Activity partition/swimlane
An activity partition or a swimlane is a high-level grouping of a set of related actions.
A single partition can refer to many things, such as classes, use cases, components, or
interfaces.

If a partition cannot be shown clearly, then the name of a partition is written on top of
the name of an activity.

Fork and Join nodes

Using a fork and join nodes, concurrent flows within an activity can be generated. A
fork node has one incoming edge and numerous outgoing edges. It is similar to one
too many decision parameters. When data arrives at an incoming edge, it is duplicated
and split across numerous outgoing edges simultaneously. A single incoming flow is
divided into multiple parallel flows.

A join node is opposite of a fork node as It has many incoming edges and a single
outgoing edge. It performs logical AND operation on all the incoming edges. This
helps you to synchronize the input flow across a single output edge.

Pins

An activity diagram that has a lot of flows gets very complicated and messy.

Pins are used to clearing up the things. It provides a way to manage the execution
flow of activity by sorting all the flows and cleaning up messy thins. It is an object
node that represents one input to or an output from an action.

Both input and output pins have precisely one edge.

Why use Activity Diagrams?

Activity diagram allows you to create an event as an activity which contains a
collection of nodes joined by edges. An activity can be attached to any modeling
element to model its behavior. Activity diagrams are used to model,

 Use cases
 Classes
 Interfaces
 Components
 Collaborations
Activity diagrams are used to model processes and workflows. The essence of a useful
activity diagram is focused on communicating a specific aspect of a system's dynamic
behavior. Activity diagrams capture the dynamic elements of a system.

Activity diagram is similar to a flowchart that visualizes flow from one activity to
another activity. Activity diagram is identical to the flowchart, but it is not a
flowchart. The flow of activity can be controlled using various control elements in the
UML diagram. In simple words, an activity diagram is used to activity diagrams that
describe the flow of execution between multiple activities.

Activity Diagram Notations

Activity diagrams symbol can be generated by using the following notations:

 Initial states: The starting stage before an activity takes place is depicted as the
initial state
 Final states: The state which the system reaches when a specific process ends is
known as a Final State
 State or an activity box:
 Decision box: It is a diamond shape box which represents a decision with
alternate paths. It represents the flow of control.

Activity Digram Notation and Symbol

How to draw an activity diagram?

Activity diagram is a flowchart of activities. It represents the workflow between
various system activities. Activity diagrams are similar to the flowcharts, but they are
not flowcharts. Activity diagram is an advancement of a flowchart that contains some
unique capabilities.

Activity diagrams include swimlanes, branching, parallel flow, control nodes,

expansion nodes, and object nodes. Activity diagram also supports exception
handling.

To draw an activity diagram, one must understand and explore the entire system. All
the elements and entities that are going to be used inside the diagram must be known
by the user. The central concept which is nothing but an activity must be clear to the
user. After analyzing all activities, these activities should be explored to find various
constraints that are applied to activities. If there is such a constraint, then it should be
noted before developing an activity diagram.

All the activities, conditions, and associations must be known. Once all the necessary
things are gathered, then an abstract or a prototype is generated, which is later
converted into the actual diagram.

Following rules must be followed while developing an activity diagram,

1. All activities in the system should be named.

2. Activity names should be meaningful.
3. Constraints must be identified.
4. Activity associations must be known.

Example of Activity Diagram

Let us consider mail processing activity as a sample for Activity Diagram. Following
diagram represents activity for processing e-mails.
 activity diagram

In the above activity diagram, three activities are specified. When the mail checking
process begins user checks if mail is important or junk. Two guard conditions [is
essential] and [is junk] decides the flow of execution of a process. After performing
the activity, finally, the process is terminated at termination node.

When Use Activity Diagram

Activity diagram is used to model business processes and workflows. These diagrams
are used in software modeling as well as business modeling.

Most commonly activity diagrams are used to,

 1. Model the workflow in a graphical way, which is easily understandable.
2. Model the execution flow between various entities of a system.
3. Model the detailed information about any function or an algorithm which is
used inside the system.
4. Model business processes and their workflows.
5. Capture the dynamic behavior of a system.
6. Generate high-level flowcharts to represent the workflow of any application.
7. Model high-level view of an object-oriented or a distributed system.

Summary
 Activity diagram is also called as object-oriented flowcharts.
 Activity diagrams consist of activities that are made up of smaller actions.
 Activity is a behavior that is divided into one or more actions.
 It uses action nodes, control nodes and object nodes.
 An activity partition or a swimlane is a high-level grouping of a set of related
actions.
 Fork and join nodes are used to generate concurrent flows within an activity.
 Activity diagram is used to model business processes and workflows.

Events and Signals:

Introduction
In state machines (sequence of states), we use events to model the occurrence of a stimulus that
can trigger an object to move from one state to another state. Events may include signals, calls,
the passage of time or a change in state.

In UML, each thing that happens is modeled as an event. An event is the specification of a
significant occurrence that has a location in time and space. A signal, passing of time and change
in state are asynchronous events. Calls are generally synchronous events, representing invocation
of an operation.

UML allows us to represent events graphically as shown below. Signals may be represented as
stereotyped classes and other events are represented as messages associated with transitions
which cause an object to move from one state to another.
Types of Events
Events may be external or internal. Events passed between the system and its actors are external
events. For example, in an ATM system, pushing a button or inserting a card are external events.
Internal events are those that are passed among objects living inside the system. For example, a
overflow exception generated by an object is an internal event.

In UML, we can model four kinds of events namely: signals, calls, passing of time and change in
state.

Signals
A signal is a named object that is sent asynchronously by one object and then received by
another. Exceptions are the famous examples for signals. A signal may be sent as the action of a
state in a state machine or as a message in an interaction. The execution of an operation can also
send signals.

In UML, we model the relationship between an operation and the events using a dependency
stereotyped with “send”, which indicates that an operation sends a particular signal.
Call Events
A call event represents the dispatch of an operation from one object to another. A call event may
trigger a state change in a state machine. A call event, in general, is synchronous.

This means that the sender object must wait until it gets an acknowledgment from the receiver
object which receives the call event. For example, consider the states of a customer in an ATM
application:

Time and Change Events

A time event represents the passage of time. In UML, we model the time event using the “after”
keyword followed by an expression that evaluates a period of time.

A change event represents an event that represents a change in state or the satisfaction of some
condition. In UML, change event is modeled using the keyword “when” followed by some
Boolean expression.
Sending and Receiving Events
Any instance of a class can receive a call event or signal. If this is a synchronous call event, the
sender is in locked state with receiver. If this is a signal, then the sender is free to carry its
operations without any concern on the receiver.

In UML, call events are modeled as operations on the class of an object and signals that an object
can receive are stored in an extra component in the class as shown below:
Common Modeling Techniques

Modeling a family of signals

To model a family of signals,

1. Consider all the signals to which a set of objects can respond.

2. Arrange these signals in a hierarchy using generalization-specialization relationship.
3. Look out for polymorphism in the state machine of the active objects. When polymorphism is
found, adjust the hierarchy by introducing intermediate abstract signals.

Modeling Exceptions

To model exceptions,

1. For each class and interface and for each operation of such elements, consider the exceptional
conditions that might arise.
2. Arrange these exceptions in a hierarchy.
 3. For each operation, specify the exceptions that it may rise.

Process and Threads:

 A heavyweight flow, which executes concurrently with other processes is known as 'Process'
 A lightweight flow which executes concurrently with other threads within the same process is
known as 'Thread'
 An object which owns a process or thread and initiate control activity is known as 'Active
Object'
 A class whose instances are active objects is known as 'Active Class'
 Graphically, active class is represented as a rectangle with thick lines and, processes and
threads are represented as stereotyped active classes

 Flow of Control
 Classes and Events
 Communication
 Synchronization
Flow of Control
 In a sequential system, there is a single flow of control. i.e., one thing, and one thing only, can
take place at a time
 In a concurrent system, there is multiple simultaneous flow of control i.e., more than one thing
can take place at a time
Classes and Events
 Active classes are just classes which represents an independent flow of control
 Same properties are shared as like other classes
 Flow of control starts when an active object is created and it terminates when destroyed
 Stereotypes of active classes are
«process»
«thread»
 All the threads that live in the context of a process are peers of one another
Communication
 The four possible combinations of interaction with both active and passive objects are
1. A message may be passed from one passive object to another
2. A message may be passed from one active object to another
3. A message may be passed from an active object to a passive object
4. A message may be passed from a passive object to an active one

 In inter-process communication there are two possible styles of communication

One active object might synchronously call an operation of another
One active object might asynchronously send a signal or call an operation of another object
 Full arrow represents synchronous message and half arrow represents asynchronous message
Synchronization
 Synchronization means arranging the flow of controls of objects so that mutual exclusion will
be guaranteed
 In object-oriented systems these objects are treated as a critical region
 The three methods to handle synchronization are
Sequential - Callers must coordinate outside the object so that only one flow is in the object at a time
Guarded - Multiple flow of control is sequentialized with the help of object's guarded operations.
Therefore, it becomes sequential
Concurrent - Multiple flow of control is guaranteed by treating each operation as atomic
 Synchronization is represented in the operations of active classes with the help of constraints
Time and Space
 Timing mark is a denotation for the time at which an event occurs
 Graphically represented as a small hash mark (horizontal line) on the border of a sequence
diagram as shown in image
 A time expression evaluates to an absolute or relative value of time

Time
 Passing of messages represents the dynamic aspect of a system
 Messages in an interaction are represented with signal or a call
 The three functions of messages are
1. sendTime
2. receiveTime
3. transmissionTime
Location
 In distributed systems, components are fixed at the time when loaded
 Components may migrate from node to node in other systems
 Artifacts are used to manifest components and classes
State Chart Diagram
What is a State Machine Diagram?
State machine diagrams are also called as state chart diagrams. State machine
diagrams are used to capture the behavior of a software system. UML State machine
diagrams can be used to model the behavior of a class, a subsystem, a package, or
even an entire system. It is also called a Statechart or State Transition diagram.

Statechart diagrams provide us an efficient way to model the interactions or

communication that occur within the external entities and a system. These diagrams
are used to model the event-based system. A state of an object is controlled with the
help of an event.

Statechart diagrams are used to describe various states of an entity within the
application system.

There are a total of two types of state machine diagrams:

1. Behavioral state machine

 It captures the behavior of an entity present in the system.

 It is used to represent the specific implementation of an element.
 The behavior of a system can be modelled using behavioral state machine
diagrams.

2. Protocol state machine

 These diagrams are used to capture the behavior of a protocol.

 It represents how the state of protocol changes concerning the event. It also
represents corresponding changes in the system.
 They do not represent the specific implementation of an element.

Why State Machine Diagram?

Statechart diagram is used to capture the dynamic aspect of a system. State machine
diagrams are used to represent the behavior of an application. An object goes through
various states during its lifespan. The lifespan of an object remains until the program
is terminated. The object goes from multiple states depending upon the event that
occurs within the object. Each state represents some unique information about the
object.
Statechart diagrams are used to design interactive systems that respond to either
internal or external event. Statechart diagram visualizes the flow of execution from
one state to another state of an object.

It represents the state of an object from the creation of an object until the object is
destroyed or terminated.

The primary purpose of a statechart diagram is to model interactive systems and

define each and every state of an object. Statechart diagrams are designed to capture
the dynamic behavior of an application system. These diagrams are used to represent
various states of a system and entities within the system.

Notation and Symbol for State Machine

Following are the various notations that are used throughout the state chart diagram.
All these notations, when combined, make up a single diagram.

UML state diagram notations

Initial state
The initial state symbol is used to indicate the beginning of a state machine diagram.

Final state
This symbol is used to indicate the end of a state machine diagram.
Decision box
It contains a condition. Depending upon the result of an evaluated guard condition, a
new path is taken for program execution.

Transition
A transition is a change in one state into another state which is occurred because of
some event. A transition causes a change in the state of an object.

State box
It is a specific moment in the lifespan of an object. It is defined using some condition
or a statement within the classifier body. It is used to represent any static as well as
dynamic situations.

It is denoted using a rectangle with round corners. The name of a state is written
inside the rounded rectangle.

The name of a state can also be placed outside the rectangle. This can be done in case
of composite or submachine states. One can either place the name of a state within the
rectangle or outside the rectangle in a tabular box. One cannot perform both at the
same time.

A state can be either active or inactive. When a state is in the working mode, it is
active, as soon as it stops executing and transits into another state, the previous state
becomes inactive, and the current state becomes active.

Types of State
Unified Modeling Language defines three types of states:

 Simple state
o They do not have any substrate.
 Composite state
o These types of states can have one or more than one substrate.
o A composite state with two or more substates is called an orthogonal
state.
 Submachine state
o These states are semantically equal to the composite states.
o Unlike the composite state, we can reuse the submachine states.
How to draw a Statechart diagram?
Statechart diagrams are used to describe the various state that an object passes
through. A transition between one state into another state occurs because of some
triggered event. To draw a state diagram, one must identify all the possible states of
any particular entity.

The purpose of these UML diagrams is to represent states of a system. States plays a
vital role in state transition diagrams. All the essential object, states, and the events
that cause changes within the states must be analyzed first before implementing the
diagram.

Following rules must be considered while drawing a state chart diagram:

1. The name of a state transition must be unique.

2. The name of a state must be easily understandable and describe the behavior of
a state.
3. If there are multiple objects, then only essential objects should be implemented.
4. Proper names for each transition and an event must be given.

When to use State Diagrams?

State diagrams are used to implement real-life working models and object-oriented
systems in depth. These diagrams are used to compare the dynamic and static nature
of a system by capturing the dynamic behavior of a system.

Statechart diagrams are used to capture the changes in various entities of the system
from start to end. They are used to analyze how an event can trigger change within
multiple states of a system.

State char diagrams are used,

1. To model objects of a system.

2. To model and implement interactive systems.
3. To display events that trigger changes within the states.

Example of State Machine

Following state chart diagram represents the user authentication process.
 UML state diagram

There are a total of two states, and the first state indicates that the OTP has to be
entered first. After that, OTP is checked in the decision box, if it is correct, then only
state transition will occur, and the user will be validated. If OTP is incorrect, then the
transition will not take place, and it will again go back to the beginning state until the
user enters the correct OTP.
 State machine vs. Flowchart
Statemachine FlowChart

It represents various states of a system. The Flowchart illustrates the program

execution flow.

The state machine has a WAIT concept, i.e., The Flowchart does not deal with waiting for
wait for an action or an event. a concept.

State machines are used for a live running Flowchart visualizes branching sequences of
system. a system.

The state machine is a modeling diagram. A flowchart is a sequence flow or a DFD

diagram.

The state machine can explore various states Flowchart deal with paths and control flow.
of a system.

Summary
 Statechart diagrams are also called as state machine diagrams.
 These diagrams are used to model the event-based system.
 A state of an entity is controlled with the help of an event.
 There is a total of two types of state machine diagrams: 1) Behavioral 2) State
machine 3) Protocol state machine
 Statechart diagram is used to capture the dynamic aspect of a system.
 A state is a specific moment in the lifespan of an object.
Architectural Modelling:
Component Diagram:
What is Component Diagram?
When modeling large object-oriented systems, it is necessary to break down the
system into manageable subsystems. UML component diagrams are used for
modeling large systems into smaller subsystems which can be easily managed.

A component is a replaceable and executable piece of a system whose implementation

details are hidden. A component provides the set of interfaces that a component
realizes or implements. Components also require interfaces to carry out a function.

UML Component diagrams are used to represent different components of a system.

Component diagram Notations

1. A component

component notation

2. A node
 node notation

What is a Component?
A component is a replaceable and executable piece of a system whose implementation
details are hidden. A component provides the set of interfaces that a component
realizes or implements. Components also require interfaces to carry out a function.

It is a modular part of a system that encapsulates its contents. They are the logical
elements of a system that plays an essential role during the execution of a system.

A component is similar to a black box whose external behavior is defined by a

provided interface and required interfaces.

Structure of a component
A component is represented with classifier rectangle stereotypes as

<< component >>. Component details are hidden for the outside world. The name of a
component is placed at the center of a rectangle. A component icon is displayed at the
upper right corner of a rectangle, which is optional.

A component in UML is represented as follows,

 Interface notation

Interfaces
The interface is a named set of public features. It separates the specification of
functionality from its implementation by a class diagram or a subsystem. An interface
symbol cannot be instantiated. It declares a contract that may be realized by zero or
more classifiers such as a class or a subsystem.

Anything that realizes an interface accepts the functionalities of the interface and
agrees to abide by the contract defined by the interface.

If the implementation language does not support interfaces the use abstract classes,
interfaces are named just like classes, in UpperCamelCase.

There are two types of interfaces,

1. Provided interfaces
2. Required interfaces

We can connect provided and required interfaces using assembly connector.

Advantages:

 It increases the flexibility and extensibility of a class.

 It decreases the implementation dependencies.

Disadvantages:

 Extra flexibility leads to complex classes.

 Too many interfaces make systems hard to understand.
Subsystems
It is a component base that acts as a decomposition unit for larger systems. It is a
logical construct which is used to break down an extensive system into smaller
systems which are known as subsystems. This process makes it easy to manage each
subsystem efficiently.

A subsystem cannot be instantiated during runtime, but their contents can be

initialized. When subsystems are connected, it creates a single system.

Port
A port is an interaction point between a classifier and an external environment. It
groups semantically cohesive set of provided and required interfaces. A port can be
used in UML without specifying the name of the port. A port may have visibility.
When a port is drawn over the boundary of a classifier, then it means that the port is
public. It also means that all the interfaces used are made as public.

When a port is drawn inside the classifier, then it is either protected or private.

A port also has multiplicity that indicates the number of instances of the port classifier
will have. A port in UML diagram is denoted as given below,

port notation

Here the port1 is drawn over the boundary, which means it has visibility as public.
Why use Component Diagram?
UML component diagrams have significant importance. Component diagram
variously differs from other diagrams. While other diagrams are used to represent the
system, working of a system or the architecture of a system. Component diagrams are
used to describe the working and behavior of various components of a system.

It represents how each component acts during the execution of a system.

These are the static diagrams of the unified modeling language. A component diagram
is used to represent the structure and organization of components during any instance
of time.

Component diagrams are used for modeling the subsystems. These subsystems
collectively represent the entire working view of any system. A single component
cannot visualize the whole system, but the collection of multiple components can.

So, component diagrams are used for,

 To represent the components of any system at runtime.

 It helps during testing of a system.
 It visualizes the connection between various components.

When to use Component Diagram?

Component diagrams are different from any other diagrams in UML. Component
diagrams are used to display various components of a software system as well as
subsystems of a single system. They are used to represent physical things or
components of a system. It generally visualizes the structure and an organization of a
system.

It describes how various components together make a single, fully functional system.
We can display each component individually or collectively as a single unit.

1. Component diagrams are used to model the component organization of a

system.
2. They are used to divide a single system into various subsystems as per the
functionality.
How to draw a component diagram
A component is nothing but an executable piece of a system. Various components
together make a single system. Component diagrams are used widely during the
execution phase of any system.

Before modeling the component diagram, one must know all the components within
the system. The working of each component should be mentioned. Component
diagrams are used to analyze the execution of a system.

One should also explore each component in depth to understand the connection of a
component to other physical artifacts in the system.

The relationship amongst various artifacts, libraries, and files are the essential things
required during modeling of a component diagram.

Example of a component diagram

component diagram Example

Summary
 A component is a replaceable and executable piece of a system.
  A component provides the set of required interfaces that a component realizes
or implements.
 These are the static diagrams of the unified modeling language.
 It is a modular part of a system that encapsulates its contents
 Component diagrams are used to represent the working and behavior of various
components of a system.
 Various components together make a single system.

Deployment Diagrams:
What is Deployment Diagram?
Deployment Diagram is a type of diagram that specifies the physical hardware on
which the software system will execute. It also determines how the software is
deployed on the underlying hardware. It maps software pieces of a system to the
device that are going to execute it.

The deployment diagram maps the software architecture created in design to the
physical system architecture that executes it. In distributed systems, it models the
distribution of the software across the physical nodes.

The software systems are manifested using various artifacts, and then they are
mapped to the execution environment that is going to execute the software such
as nodes. Many nodes are involved in the deployment diagram; hence, the relation
between them is represented using communication paths.

There are two forms of a deployment diagram.

 Descriptor form
o It contains nodes, the relationship between nodes and artifacts.
 Instance form
o It contains node instance, the relationship between node instances and
artifact instance.
o An underlined name represents node instances.

Purpose of a deployment diagram

Deployment diagrams are used with the sole purpose of describing how software is
deployed into the hardware system. It visualizes how software interacts with the
hardware to execute the complete functionality. It is used to describe software to
hardware interaction and vice versa.
Deployment Diagram Symbol and
notations

Deployment Diagram Notations

A deployment diagram consists of the following notations:

1. A node
2. A component
3. An artifact
4. An interface

What is an artifact?
An artifact represents the specification of a concrete real-world entity related to
software development. You can use the artifact to describe a framework which is used
during the software development process or an executable file. Artifacts are deployed
on the nodes. The most common artifacts are as follows,

1. Source files
2. Executable files
3. Database tables
4. Scripts
5. DLL files
6. User manuals or documentation
7. Output files

Artifacts are deployed on the nodes. It can provide physical manifestation for any
UML element. Generally, they manifest components. Artifacts are labeled with the
stereotype <<artifact>>, and it may have an artifact icon on the top right corner.
Each artifact has a filename in its specification that indicates the physical location of
the artifact. An artifact can contain another artifact. It may be dependent on one
another.

Artifacts have their properties and behavior that manipulates them.

Generally, an artifact is represented as follows in the unified modeling language.

artifact

Artifact Instances
An artifact instance represents an instance of a particular artifact. An artifact instance
is denoted with same symbol as that of the artifact except that the name is underlined.
UML diagram allows this to differentiate between the original artifact and the
instance. Each physical copy or a file is an instance of a unique artifact.

Generally, an artifact instance is represented as follows in the unified modeling

language.

artifact instance

What is a node?
Node is a computational resource upon which artifacts are deployed for execution. A
node is a physical thing that can execute one or more artifacts. A node may vary in its
size depending upon the size of the project.

Node is an essential UML element that describes the execution of code and the
communication between various entities of a system. It is denoted by a 3D box with
the node-name written inside of it. Nodes help to convey the hardware which is used
to deploy the software.

An association between nodes represents a communication path from which

information is exchanged in any direction.

Generally, a node has two stereotypes as follows:

 << device >>

It is a node that represents a physical machine capable of performing

computations. A device can be a router or a server PC. It is represented using a
node with stereotype <<device>>.

In the UML model, you can also nest one or more devices within each other.

Following is a representation of a device in UML:

device node

 << execution environment >>

It is a node that represents an environment in which software is going to

execute. For example, Java applications are executed in java virtual machine
(JVM). JVM is considered as an execution environment for Java applications.
We can nest an execution environment into a device node. You can net more
than one execution environments in a single device node.

Following is a representation of an execution environment in UML:

 execution environment node

How to draw a deployment diagram?

Deployment diagram visualizes the topological view of an entire system. It represents
the deployment of a system.

A deployment diagram consists of nodes which describe the physical devices used
inside the system. On these nodes, artifacts are deployed. We can also have node
instances on which artifact instances are going to be implemented.

Node and artifacts of a system participate in the final execution of a system.

A deployment diagram plays a critical role during the administrative process, and it
must satisfy the following parameters,

 High performance
 Maintainability
 Scalability
 Portability
 Easily understandable

Nodes and artifacts are the essential elements of deployment. Before actually drawing
the deployment diagram, all nodes and the relationship between every node of the
system must be identified.

You must know the architecture of a system, whether an application is a web

application, cloud application, desktop application, or a mobile application. All these
things are critical and plays a vital role during the development of a deployment
diagram.
If all the nodes, relations, and artifacts are known, then it becomes easy to develop a
deployment diagram.

Example of a Deployment diagram

Following deployment diagram represents the working of HTML5 video player in the
browser:

Deployment Diagram
When to use a deployment diagram?
Deployment diagrams are mostly used by system administrators, network engineers,
etc. These diagrams are used with the sole purpose of describing how software is
deployed into the hardware system. It visualizes how software interacts with the
hardware to execute the complete functionality.

To make the software work efficiently and at a faster rate, the hardware also must be
of good quality. It must be designed efficiently to make software work properly and
produce accurate results in quick time.

Deployment diagrams can be used for,

1. Modeling the network topology of a system.

2. Modeling distributed systems and networks.
3. Forward and reverse engineering processes.

Summary
 The deployment diagram maps the software architecture created in design to
the physical system architecture that executes it.
 It maps software pieces of a system to the hardware that are going to execute it.
 Deployment diagram visualizes the topological view of an entire system.
 Nodes and artifacts are the essential elements of deployment.
 Node and artifacts of a system participate in the final execution of a system.