Unit-1

UML Introduction
- Grady Booch, The Unified Modeling Language User Guide (2nd
Edition)
• The UML was developed in 1994-95 by Grady Booch, Ivar Jacobson,
and James Rumbaugh at the Rational Software.
• In 1997, it got adopted as a standard by the Object Management
Group (OMG).
OO Analysis and Design
The purpose of OO is given below:
• To identify the objects of a system.
• To identify their relationships.
• To make a design that is executable when the concepts of OO are
employed.
Following are the steps where OO concepts are applied and implemented:
Step 1: OO Analysis
Step 2: OO Design
Step 3: OO Implementation
Why we model?
• "Modeling is a central part of all the activities that lead up to the
deployment of good software.
• We build models to communicate the desired structure and behavior
of our system.
• We build models to visualize and control the system's architecture.
• We build models to better understand the system we are building,
often exposing opportunities for simplification and reuse.
• And we build models to manage risk."
Importance of Modeling
• Modeling is a proven & well accepted engineering techniques. In
building architecture, we develop architectural models of houses to
help visualize the final products.
• In Unified Modeling Language (UML), a model may be structural,
emphasizing the organization of the system or it may be behavioral,
emphasizing the dynamics of the system.
• A model is a simplification of reality, providing blueprints of a system.
UML, in specific:
• Permits you to specify the structure or behavior of a system.
• Helps you visualize a system.
• Provides template that guides you in constructing a system.
• Helps to understand complex system part by part.
• Document the decisions that you have made.
We build model so that we can better understand the system we are
developing. A model may encompass an overview of the system under
consideration, as well as a detailed planning for system design,
implementation and testing.
Principles of UML Modeling
• The choice of model is important.
• Every model may be expressed at different levels of precision.
• The best models are connected to reality.
• No single model is sufficient.
SYSTEM,MODEL,VIEW
• A model is an abstraction describing a subset of a system
• A view depicts selected aspects of a model
• A notation is a set of graphical or textual rules for depicting views
• Views and models of a single system may overlap each other

Examples:
• System: Aircraft
• Models: Flight simulator, scale model
• Views: All blueprints, electrical wiring, fuel system
Introduction to UML
• The unified modeling language (UML) is a standard language for
writing software blueprints of the system.
Definition: The UML is a language for
• Visualizing
• Specifying
• Constructing
• Documenting the objects of a software system.
• UML is a language that provides vocabulary and the rules for
combining words in that vocabulary for the purpose of
communication.
• Vocabulary and rules of a language tell us how to create and real
well-formed models, but they don’t tell you what model you should
create and when should create them.
Model?
• A model is a simplification of reality.
• A model provides the blueprints of a system.
• A model may be structural, emphasizing the organization of the
system, or it may be behavioral, emphasizing the dynamics of the
system.
Why do we model?
• We build models so that we can better understand the system we are
developing.
Building blocks of UML /Elements of UM L
Building blocks of UML are divided into:
1. Things
2. Relationships
3. Diagrams
1. Things in the UML: There are four kinds of things in the UML:
i. Structural things
ii. Behavioral things
iii. Grouping things
iv. Annotational things
i. Structural things are the nouns of UML models. These are the static parts
of a model, representing elements that are either conceptual or physical.
In all, there are seven kinds of structural things.
a. Class
b. Interface
c. Collaboration
d. Use case
e. Active class
f. Component
g. Node
a. Class: 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. Graphically, a class is
rendered as a rectangle, usually including its name, attributes, and
operations.
• Object: An individual that describes the behavior and the functions of
a system. The notation of the object is similar to that of the class; the
only difference is that the object name is always underlined and its
notation is given below;
b. Interface: Interface is a collection of operations that specify a service
of a class or component. An interface therefore describes the
externally visible behavior of that element. An interface might
represent the complete behavior of a class or component or only a part
of that behavior.
• An interface is rendered as a circle together with its name. An
interface rarely stands alone. Rather, it is typically attached to the
class or component that realizes the interface.

ISpelling
C. Collaboration: Collaboration defines an interaction and is a society
of roles and other elements that work together to provide some
cooperative behavior. Therefore, collaborations have structural, as well
as behavioral, dimensions. A given class might participate in several
collaborations.
• Graphically, a collaboration is rendered as an ellipse with dashed
lines, usually including only its name.

Here Chain of responsibility is collaboration name.

d. Use case: Use case is a description of set of sequence of actions that
a system performs that yields an observable result of value to a
particular actor. Use case is used to structure the behavioral things in a
model. A use case is realized by a collaboration. Graphically, a use case
is rendered as an ellipse with solid lines, usually including only its
name.
e. Active class: Active class is a class whose objects own one or more
processes or threads. An active class is just like a class except that its
objects represent elements whose behaviour is concurrent with other
elements.
• Graphically, an active class is rendered just like a class, but with heavy
lines, usually including its name, attributes, and operations.
f. Component: Component is a physical and replaceable part of a
system that conforms to and provides the realization of a set of
interfaces.
Graphically, a component is rendered as a rectangle with tabs.
g. Node: Node is a physical element that exists at run time and
represents a computational resource, generally having at least some
memory and, often, processing capability.
Graphically, a node is rendered as a cube, usually including only its
name.
ii)Behavioral Things: Behavioral Things are the dynamic parts of UML
models. These are the verbs of a model, representing behavior over
time and space.
In all, there are two primary kinds of behavioral things.
a. Interaction
b. state machine
a. Interaction: Interaction is a behavior that comprises a set of messages
exchanged among a set of objects within a particular context to accomplish a
specific purpose. An interaction involves a number of other elements, including
messages, action sequences and links.
Graphically a message is rendered as a directed line, almost always including
the name of its operation
• State Machine: State machine is a behavior that specifies the
sequences of states an object or an interaction goes through during
its lifetime in response to events, together with its responses to those
events. State machine involves a number of other elements, including
states, transitions, events, and activities.
• Graphically, a state is rendered as a rounded rectangle, usually
including its name.
iii) Grouping Things: These are the organizational parts of UML models.
These are the boxes into which a model can be decomposed. There is
one primary kind of grouping thing, namely, packages.
Ex: Package: A package is a general-purpose mechanism for organizing
elements into groups. Structural things, behavioral things, and even other
grouping things may be placed in a package.
• Graphically, a package is rendered as a tabbed folder, usually
including only its name and, sometimes, its contents.
iv) Annotational Things: Annotational things are the explanatory parts
of UML models. These are the comments you may apply to describe
about any element in a model.
• Ex: note: A note is simply a symbol for rendering constraints and
comments attached to an element or a collection of elements.
• Graphically, a note is rendered as a rectangle with a dog-eared
corner, together with a textual or graphical comment.
2. Relationships in the UML: There are four kinds of relationships in
the UML:
1.Dependency
2.Association
3.Generalization
4.Realization
1. Dependency is a semantic relationship between two things in which
a change to one thing may affect the semantics of the other thing.
• Graphically a dependency is rendered as a dashed line, possibly
directed, and occasionally including a label.

2. Association is a structural relationship that describes a set of links, a

link being a connection among objects.
• Graphically an association is rendered as a solid line, possibly
directed, occasionally including a label, and often containing other
adornments, such as multiplicity and role names.
3. Generalization is a specialization/generalization relationship in
which objects of the child are substitutable for the objects of the
parent.
Graphically, a generalization relationship is rendered as a solid line with
a hollow arrowhead pointing to the parent.

4. Realization is a semantic relationship between classifiers, wherein

one classifier specifies a contract that another classifier guarantees to
carry out.
Graphically a realization relationship is rendered as a cross between a
generalization and a dependency relationship.
3. Diagrams in the UML:
Diagram is the graphical presentation of a set of elements, most often rendered as a
connected graph of vertices (things) and arcs (relationships).
In theory, a diagram may contain any combination of things and relationships.
For this reason, the UML includes nine such diagrams:
• Class diagram
• Object diagram
• Use case diagram
• Sequence diagram
• Collaboration diagram
• State chart diagram
• Activity diagram
• Component diagram
• Deployment diagram
• Class diagram
• A class diagram shows a set of classes, interfaces, and collaborations and
their relationships. Class diagrams address the static design view of a
system. Class diagrams that include active classes address the static
process view of a system.
• Object diagram
• Object diagrams represent static snapshots of instances of the things found
in class diagrams. These diagrams address the static design view or static
process view of a system. An object diagram shows a set of objects and
their relationships.
• Use case diagram
• A use case diagram shows a set of use cases and actors and their
relationships. Use case diagrams address the static use case view of a
system. These diagrams are especially important in organizing and
modeling the behaviors of a system.
Interaction Diagrams
• An interaction diagram shows an interaction, consisting of a set of objects
and their relationships. Including the messages that may be dispatched
among them. Interaction diagrams address the dynamic view of a system.
• Both sequence diagrams and collaboration diagrams are kinds of
interaction diagrams. Sequence diagrams and collaboration diagrams are
isomorphic, meaning that you can take one and transform it into the other
• A Sequence diagram is an interaction diagram that emphasizes the time-
ordering of messages.
• A collaboration diagram is an interaction diagram that emphasizes the
structural organization of the objects that send and receive messages.
Statechart diagram
• A statechart diagram shows a state machine, consisting of states,
transitions, events, and activities. Statechart diagrams address the
dynamic view of a system. They are especially important in modeling
the behavior of an interface, class, or collaboration and emphasize
the event-ordered behavior of an object.
Activity diagram
• An activity diagram is a special kind of a statechart diagram that
shows the flow from activity to activity within a system. Activity
diagrams address the dynamic view of a system. They are especially
important in modeling the function of a system and emphasize the
flow of control among objects.
Component diagram
• A component diagram shows the organizations and dependencies
among a set of components. Component diagrams address the static
implementation view of a system. They are related to class diagrams
in that a component typically maps to one or more classes,
interfaces, or collaborations.
Deployment diagram
• A deployment diagram shows the configuration of run-time
processing nodes and the components that live on them. Deployment
diagrams address the static deployment view of an architecture.