What are the five concepts of object oriented language?

1) Polymorphism
2) Dynamic binding
3) Inheritance
4) Data Encapsulation
5) Data Abstraction

There are nine types of diagrams in UML :-

Use case diagram: They describe "WHAT" of a system rather than "HOW" the system does it.They are
used to identify the primary elements and processes that form the system. The primary elements are
termed as "actors" and the processes are called "use cases". Use Case diagrams shows "actors" and
there "roles".
Class diagram: From the use case diagram we can now go to detail design of system, for which the
primary step is class diagram. The best way to identify classes is to consider all "NOUNS" in use cases as
classes, "VERBS" as methods of classes, relation between actors can then be used to define relation
between classes. The relationship or association between the classes can be either an "is-a" or "has-a"
relationship which can easily be identified from use cases.
Object diagram: An object is an instance of a class. Object diagram captures the state of classes in the
system and their relationships or associations at a specific point of time.
State diagram: A state diagram, as the name suggests, represents the different states that objects in
the system undergo during their life cycle. Object change in response to certain simulation so this
simulation effect is captured in state diagram. So basically it has a initial state and final state and events
that happen in between them. Whenever you think that some simulations are complicated you can go
for this diagram.
Sequence diagram: Sequence diagrams can be used to explore the logic of a complex operation,
function, or procedure. They are called sequence diagrams because sequential nature is shown via
ordering of messages. First message starts at the top and the last message ends at bottom. The
important aspect of a sequence diagram is that it is time-ordered. This means that the exact sequence
of the interactions between the objects is represented step by step. Different objects in the sequence
diagram interact with each other by passing "messages".
Collaboration diagram: A collaboration diagram groups together the interactions between different
objects to fulfill a common purpose.
Activity diagram: Activity diagram is typically used for business process modeling, for modeling the
logic captured by a single use case, or for visualizing the detailed logic of a business rule.Complicated
process flows in the system are captured in the activity diagram. Similar to a state diagram, an activity
diagram also consists of activities, actions, transitions, initial and final states, and guard conditions. But
difference is state diagrams are in context of simulation while activity gives detail view of business logic.
Deployment diagram: Deployment diagrams show the hardware for your system, the software that is
installed on that hardware, and the middleware used to connect the disparate machines to one another.
It shows how the hardware and software work together to run a system. In one line its shows the
deployment view of the system.
Component diagram: The component diagram represents the high-level parts that make up the
system. From .NET angle point of view they form the "NAMESPACES". This diagram depicts, at a3 1 4
high level, what components form part of the system and how they are interrelated. Its shows the
logical grouping of classes or group of other components.

What is UML?

The Unified Modeling Language (UML) is a graphical language for visualizing, specifying, constructing,
and documenting the artifacts of a software-intensive system.UML provides blue prints for business
process, System function, programming language statements, database schemas and reusable
components.

DIAGRAMS IN UML
USE CASE DIAGRAMS
A Use case diagram is a graphical view of some or all of the actors, use cases, and their interactions  identified for a
system. Each system typically has a Main Use Case diagram, which is a picture of the system boundary (actors) and
the major functionality provided by the system (use cases).
Other use case diagrams may be created as needed. Some examples follow:
• A diagram showing all the use cases for a selected actor
• A diagram showing all the use cases being implemented in an iteration
• A diagram showing a use case and all its relationships
They are most valuable on a very large or complex system where the interaction between Use Cases is not
straightforward or easily apparent. Use Case Diagrams are also especially useful when you have Use Cases that are
"subclassed" from other Use Cases. The Use Case Diagrams give you an easy graphical way to display this
inheritance.
CLASS DIAGRAM
Class Diagrams describe the various types of objects that exist in the system and the static relationships that exist
between them. Class Diagrams also show the attributes (properties) and the operations (methods) of a class. Class
Diagrams allow you to plan how the classes/objects will function and interact. You find the classes by examining the
objects in the sequence and collaboration diagrams.
The UML modeling elements found in class diagrams include:
· Classes and their structure and behavior.
· Association, aggregation, dependency, and inheritance relationships.
· Multiplicity and navigation indicators
· Role names.
STATECHART DIAGRAM
State Diagrams describe the behavior of a system. They show all the possible states an object can get into, and also
how the object's state changes as a result of events that happen to it. Usually, State Diagrams are drawn to show the
lifetime behavior of a single class. The large black dots indicate the starting and ending points of the events. State
transition diagrams are drawn for objects that typically have a lot of dynamic behavior.
A state transition may have an action and/or a guard condition associated with it and may also trigger an event. An
action is behavior that occurs when the state transition occurs.
An event is a message that is sent to another object in the system. A guard condition is a Boolean expression of
attribute values that allows a state transition only if the condition is true. Both actions and guards are behaviors of the
object and typically become operations. Often, these operations are private—that is, they are used only by the object
itself.
ACTIVITY DIAGRAMS
Similar to a flow chart, Activity Diagrams describe the sequencing of activities. They are actually a variant of the State
Diagram. Like State Diagrams, the starting point is indicated with a large black dot. The horizontal black lines indicate
where the object may take one of several different paths of action. Activity Diagrams are especially useful for objects
which contain a lot of complex logic that you wish to clearly present.
SEQUENCE DIAGRAMS
Interaction Diagrams show how groups of objects collaborate in some behavior. Sequence Diagrams are the most
common type of Interaction Diagram, and show an instance of an object and the 'life' of that object. In addition, the
interaction between objects is shown.
Sequence diagrams show object interactions arranged in a time sequence.
COLLABORATION DIAGRAMS
Collaboration Diagrams, like Sequence Diagrams, are also interaction diagrams. Within the Collaboration Diagram, the
objects are shown as icons. The arrows as well as the numbers (in this case, 1 and 1.1) indicate the order in which
events occur. Collaboration Diagrams are good when you want to get a quick overview of the general flow of events and
object relations. However, Sequence Diagrams are a better choice when you need to demonstrate the timing and
sequencing of events.
COMPONENT DIAGRAMS
Component Diagrams show the various components in a system and their dependencies. The 'component' represents a
physical module of code. The components are often the same as the packages, but they  can be different, since the
components represent the physical packaging of code. The 'dependencies' between the components show how
changes in one component can affect the other components.
DEPLOYMENT DIAGRAMS
Deployment Diagrams show the physical relationship among software and hardware components in the system. This
diagram is a good place to show how components and objects are routed and how they move around in a distributed
system. Deployment Diagrams really show how the Component Diagrams interact. Many times, developers will combine
the Component and Deployment Diagrams into a single diagram.
PACKAGE DIAGRAMS
Package Diagrams simply show groups of classes and the dependencies that exist between them. Package Diagrams
are similar to Class Diagrams.However, instead of showing the individual classes, they show the related classes
grouped together into a unit called a "package." A dependency exists between two packages if any dependency exists
between any two classes inside each package. Package Diagrams can be real