Explain unifies modelling language - The Unified Modeling Language (UML) is a language for specifying, visualizing,

constructing. and documenting the artifacts of software systems, as well as for business modeling and other non-
software systems. UML is not a programming language but tools can be used to generate code in various languages
using UML diagrams. UML has a direct relation with object oriented analysis and design.
Explain Structural thing - A structural thing is used to describe the static part of a model. They represent the physical
conceptual elements. It is used to represent the things that are visible to human eyes. Struct things are all about the
physical part of a system. It is the noun of a UML model, such as a da object, interface, collaboration, use case,
component, and a node Structural things consist of Class: A class is used to represent various objects. It is used to
define the properties and operations of an object
Behavioral thing - A behavioral thing consists of the dynamic parts of UML models. They are the verbs of a UML
model, such as interactions, activities and state machines. Behavioral things are used to represent 3. the behavior of a
system.
The Unified Process (UP)- The Unified Process (UP) combines commonly accepted best practices, such as an iterative
sents lifecycle and risk-driven development, into a cohesive and well-documented description Unified Process is
based on the enlargement and refinement of a system through multiple iterations, with cyclic feedback and
adaptation. The system is developed incrementally over time, iteration by iteration, and thus this approach is also
known as iterative and incremental software development.
Pipes and Filter - In a pipe and filter style each component has a set of inputs and a set of outputs. A component
reads streams of data on its inputs and produces streams of data on its outputs, delivering a complete instance of the
result in a standard order. This is usually accomplished by applying a local transformation to the input streams and
computing incrementally so output begins before 2. input is consumed. Hence, components are termed "filters". The
connectors of this style serve as conduits for the streams, transmitting outputs of one filter to inputs of another.
Hence the connectors are termed "pipes".
Implicit invocation - The idea behind implicit invocation is that instead of invoking a procedure directly, a component
can announce (or broadcast) one or more events. Other components in the system can register an interest in an event
by associating a procedure with the event. When the event is announced the system itself invokes all of the
procedures that have been registered for the event. Thus an event announcement "implicitly" causes the invocation
of procedures in other modules.
Blackboard Model - Blackboard architecture style is an artificial intelligence approach which handles complex
problem, where the solution is the sum of its parts. In this architecture, the logical flow is determined by the current
data status in data store because the data store is active and its clients are passive. Blackboard architecture style has a
blackboard component which acts as a central data repository. It is used in location-locomotion, data interpretation
and environmental changes for solving the problem. It is an approach to processing agent communication centrally.
Table Driven Interpreters - In interpreter organization a virtual machine is produced in software. An interpreter
includes the pseudo-program being interpreted the interpretation engine itself. The pseudo-program includes the
program itself and the interpreter's analog of its execution state. The interpretation engine includes both the
definition of the interpreter and the current state of its execution. Thus an interpreter generally has four components:
an interpretation engine to do the work, a memory that contains the pseudo-code to be interpreted, a representation
of the control state of the interpretation engine and a representation of the current state of the program being
simulated
layered system - A layered system is organized hierarchically, each layer providing service to the layer above it and
serving as a client to the layer below it. In some layered systems inner layers are hidden from all except the adjacent
outer layer, except for certain functions carefully selected for export Thus in these systems the components
implement a virtual machine at some layer in the hierarchy. The connectors are defined by the protocols that
determine how the layers will interact. Topological constraints include limiting interactions to adjacent layers.
Repositories - In a repository style there are two quite distinct kinds of components: a central data structure
represents the current state, and a collection of independent components operate on the central data store.
Interactions between the repository and its external components can vary significantly between systems. The choice
of control discipline leads to major subcategories. If the types of transactions in an input stream of transactions
trigger selection of processes to execute, the repository can be a traditional database.
Design Pattern - Christopher Alexander says, "Each pattern describes a problem which occurs over and over again in
our environment, and then describes the core of the solution to that problem, in such a way that you can use this
solution a million times over, without ever doing it the same way twice." Our solutions are expressed in terms of
objects and interfaces”

Describe Design Pattern - Graphical notations are important and useful; however, they aren't sufficient. They simply
capture the end product of the design process as relationships between classes and objects. To reuse the design, we
must also record the decisions, alternatives, and trade-offs that led to it. Concrete examples are important too,
because they help you see the design in action. We describe design patterns using a consistent format. Each pattern is
divided into sections according to the following template. The template lends a uniform structure to the information,
making design patterns easier to learn, compare and use.
Creational Patterns- Creational design patterns are concerned with the way of creating objects. These design patterns
are used when a decision must be made at the time of instantiation of a class (i.e., creating an object of a class).
Sometimes, the nature of the object must be changed according to the nature of the program. In such cases, we must
get the help of creational design patterns to provide more general and flexible approach.
Singleton pattern- Singleton pattern says that just "define a class that has only one instance and provide a global
point of access to it". In other words, a class must ensure that only single instance should be created and single object
can be used by all other classes
Factory Method - A Factory Pattern says that just define an interface or abstract class for creating an object but let
the subclasses decide which class to instantiate. In other words, subclasses are responsible to create the instance of
the class. It is also known as Virtual Constructor. Intent- Define an interface for creating an object, but let subclasses
decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.
Abstract Factory- Abstract Factory Pattern says that just define an interface or abstract class for creating families of
related (or dependent) objects but without specifying their concrete sub-classes. Abstract Factory lets a class returns
a factory of classes. So, this is the reason that Abstract Factory Pattern is one level higher than the Factory Pattern. An
Abstract Factory Pattern is also known as a kit
Structural Patterns - Structural design patterns are concerned with how classes and objects can be composed to form
larger structures. The structural design patterns simplify the structure by identifying the relationships. These patterns
focus on, how the classes inherit from each other and how they are composed from other classes.
Adapter- Adapter pattern works as a bridge between two incompatible interfaces. It combines the capability of two
independent interfaces. This pattern involves a single class which is responsible to join functionalities of independent
or incompatible interfaces. Convert the interface of a class into another interface client expect
Decorator pattern- Decorator pattern allows a user to add new functionality to an existing object without altering its
structure. This pattern acts as a wrapper to existing class. This pattern creates a decorator class which wraps the
original class and provides additional functionality keeping class methods signature intact.
Façade- As the name suggests, it means the face of the building. The people walking past the road can only see this
glass face of the building. They do not know anything about it, the wiring, the pipes and other complexities. It hides
all the complexities of the building and displays a friendly face. Facade pattern hides the complexities of the system
and provides an interface to the client using which the client can access the system. This pattern adds an interface to
existing system to hide its complexities. It involves a single class which provides simplified methods required by client
and delegates calls to methods of existing system classes.
Behavioral Patterns- Behavioral design patterns are concerned with algorithms and the assignment of responsibilities
between objects. These design patterns are concerned with the interaction and responsibility of objects. In these
design patterns, the interaction between the objects should be in such a way that they can easily talk to each other
and still should be loosely coupled. That means the implementation and the client should be loosely coupled in order
to avoid hard coding and dependencies.
Observer pattern - Observer pattern is used when there is one-to-many relationship between objects such as if one
object is modified, its dependent objects are to be notified automatically. Intent Define a one-to-many dependency
between objects so that when one object change state, all its dependents are notified and updated automatically.
Low Coupling - Coupling is a measure of how strongly one element is connected to, has knowledge of, or depends on
other elements. When depended-upon elements changes, and there is coupling or dependency, the dependent may
be affected.
Low coupling is an evaluative pattern that dictates how to assign responsibilities to support:
1. Lower dependency between the classes. 2. Change in one class having a less impact on other classes.3. Higher
reuse potential.
A class, for example, with high (or strong) coupling relies on many other classes. Such classes may be undesirable;
some suffer from the following problems: 1. Forced local changes because of changes in related classes.

High Cohesion - High cohesion is an evaluative pattern that attempts to keep objects appropriately focused,
manageable and understandable. High cohesion is generally used in support of low coupling. The term cohesion is
used to indicate the degree to which a class has a single, well-focused responsibility. Cohesion is a measure of how
the methods of a class or a module are meaningfully and strongly related and how focused they are in providing a
well-defined purpose to the system. An element with highly related responsibilities, and which does not do a
tremendous amount of work, has high cohesion.

Controller- A controller is a non-user interface object responsible for receiving or handling a system event and defines
the method for the system operation. The controller is responsible for handling the requests of actors. The controller
is the middle-man between your user clicking "Send" and your back-end making that happen. If an actor clicks on a
button, what should the UI objects do? It is bad practice for the UI objects to contain application or business logic.

Pure Fabrication - Assign a highly cohesive set of responsibilities to an artificial or convenience class that does not
represent a problem domain concept - something made up, to support high cohesion, low coupling, and reuse. Such a
class is a fabrication of the imagination. The responsibilities assigned to this fabrication support high cohesion and
low coupling, so that the design of the fabrication is very clean or pure. Hence it is called as pure fabrication.

Polymorphism- The Polymorphism GRASP pattern deals with how a general responsibility gets distributed to a set of
classes or interfaces. When alternate behaviors are selected based on the type of an object, use polymorphic method
call to select the behavior, rather than using if statements to test the type. Polymorphism is also used to create
pluggable software components. A software component is pluggable if it presents itself as the known class or
interface.
Indirection - Indirection introduces an intermediate unit to communicate between the other units, so that the other
units are not directly coupled Many existing design patterns are specializations of Pure Fabrication, many are also
specializations of Indirection Example Adapter. Facade, and Observer. In addition, many Pure Fabrications are
generated because of Indirection

Protected Variations (PV) - Protected Variations (PV) was first published as a pattern by Cockburn. Almost every
software or architectural design trick like data encapsulation, polymorphism, date-drive design, interfaces, virtual
machines, configuration files, operating systems, and much more is specialization of Protected Variations. PV provides
a well-defined interface so that there will be no effect on other units. It provides flexibility and protection from
variations. Also provides more structured design. Example: polymorphism, data encapsulation, interfaces. It
expresses: "How to avoid impact of variations of some elements on the other elements."
Don't Talk to Strangers (Law of Demeter) - This law was proposed by Ian Holland in 1987 when he and his colleagues
were programming a system called Demeter using object oriented programming. During the development of the
system they realized that the code that fulfilled a series of rules was less coupled. This law says that avoid creating
designs that traverse long object structure paths and send messages (or talk) to distant, indirect (stranger) objects.
Such designs are fragile with respect to changes in the object structures - a common point of instability. It is, a
mechanism to achieve protection from structure changes is to apply the Don't Talk to Strangers rules.

Spring core framework - The Core module forms the backbone of the entire Spring Framework. All other Spring
modules are dependent on this module. It is also called the IOC container and is central to Spring's support for
Dependency Injection (DI). IOC is best described by the term the Hollywood principle, which states "Don't call us;
we'll call you." (The junior artists often hear this from production managers in Hollywood.) However, this is important
in software development as well to control the flow of applications while ensuring high cohesion and low coupling. To
better understand, this let us consider a simple case when your application performs some calculations and prints the
end result using a logging library like log4j. In this case, the application code irresponsible for the flow of control while
invoking methods on the log4j API as and when necessary.

Bean Factory - The org.springframework.beans.factory.BeanFactory interface provides the basis for Spring's IOC
container or bean factory. It is a sophisticated implementation of the GOF factory method design pattern and creates,
caches, wires together, and manages application objects. These objects are affectionately called beans because Spring
promotes the POJO programming model. Spring provides several out-of-the-box implementations of the bean factory.
One such implementation is the XmlBeanFactory class. This class allows you to configure the various application
classes and their dependencies in XML files. In short, a bean factory like JNDI is a registry of application objects.