DIRECT TO HOME SERVICE

Table of content

I) Abstract

1. Objective

2. Drawbacks of existing system

3. Proposed system

4. Description of modules

II) Introduction

1. Description of Project

2. Detailed description of project modules

III) Literature survey

1. What software concepts we are using(model  description of

upm,diagram of upm, how case study is executing in sequence)

2. UML description (building blocks of uml,detailed description of

diagrams with example of diagrams)

3. How much work has been done previously w.r.t case study.

4. What are our improvements towards the case study.

5. Which technology we are using.

6. What are the databases used in the case study.

 DIRECT TO HOME SERVICE (DTH)

ABSTRACT:

OBJECTIVE:

The goal of this project is to provide a television service to the client

which is wireless and to improve the vision of the cable television by
providing high picture quality to the clients in packages or offers suitable to
the clients. This improves the end user’s experience and promotes the
service of satellite Television in an cheaper level when compared to normal
wired cable service.

Drawbacks of Existing systems :

Earlier to DTH service, Cable Television service was in wide use in the
market over the world. It was called CATV Community Antenna Television
which was originated in 1948 at European Countries. Cable television is a
system of providing television to consumers via radio frequency signals
transmitted to televisions through fixed optical fibers or coaxial cables
located on the subscriber's property, much like the over-the-air method used
in traditional television broadcasting (via radio waves) in which a television
antenna is required.

The Major drawbacks of the CATV were as follows :

 Need for coaxial wiring between the service provider and the clients.
  Poor Picture Quality service.

 Less number of channels.

 Since information is transferred over cable, possibility of Signal

Interruption is possible.

 Costly and expensive if taken for certain premium channels.

 No Interactive features like recording, games, Radio etc.

Proposed System :

To overcome the problems of the Cable Television, a new system was

developed in Europe called as the Satellite Telivision. Direct to Home service
is a Satellite Telivision in which transmission signals are delivered by the
means of communications satellite and received by a satellite dish and set-
top box. In many areas of the world it provides a wide range of channels and
services, often to areas that are not serviced by terrestrial or cable
providers.

The general advantages of the DTH service are as follows :

 Since transmission are from satellites and wireless, there is no need of

wiring between provider to client.

 No dependency on cable operators for providing transmission. Signals

are received directly from home.
  Good Picture Quality like High Definition type etc.

 Can be used anywhere across the world where the cable cannot reach
like villages, districts.

 Supports a good variety of channels subscription.

 It offers variety of other interactive services like cookery show stock market information,
movie on request etc.

 There won’t be any service breakdowns except in rare cases.

Description of Modules :

The Direct To Home service concept can be understood with the help
of the following Modules in the system development. i.e

 Channels programming source Module

 Broadcast Center Module

 Manager Module

 Satellite Module

 Reciever’s Dish Module.

Introduction :

Description of the Project :

What is DTH?

DTH stands for Direct-To-Home television. DTH is defined as the reception of

satellite programmes with a personal dish in an individual home.
DTH does away with the need for the local cable operator and puts the
broadcaster directly in touch with the consumer. Only cable operators can
receive satellite programmes and they then distribute them to individual
homes.

How does DTH work?

A DTH network consists of a broadcasting centre, satellites, encoders,

multiplexers, modulators and DTH receivers.

A DTH service provider has to lease Ku-band transponders from the satellite.
The encoder converts the audio, video and data signals into the digital
format and the multiplexer mixes these signals. At the user end, there will be
a small dish antenna and set-top boxes to decode and view numerous
channels. On the user's end, receiving dishes can be as small as 45 cm in
diametre.

DTH is an encrypted transmission that travels to the consumer directly

through a satellite. DTH transmission is received directly by the consumer at
his end through the small dish antenna. A settop box, unlike the regular
cable connection, decodes the encrypted transmission.
How does DTH really differ from cable TV ?
The way DTH reaches a consumer's home is different from the way
cable TV does. In DTH, TV channels would be transmitted from the satellite
to a small dish antenna mounted on the window available at the rooftop of
the subscriber's home. So the broadcaster directly connects to the user. The
middlemen like local cable operators are not there in the picture.
DTH can also reach the remotest of areas since it does away with the
intermediate step of a cable operator and the wires (cables) that come from
the cable operator to your house. As we explained above, in DTH signals
directly come from the satellite to your DTH dish. Also with DTH service , a
User can have upto 700 channels on TV.

Detailed Description of Modules :

The Direct To Home service can have the following Modules in its
design. They are explained as follows :-

1) Channel’s Programming Source Module :

Programming sources are simply different channel holders
which provides the programmes for broadcasting. The provider
 doesn’t create original programming itself but it pays the
channel companies for rights to broadcast their content via
satellites. In this the provider is like a broker or intermediate
between the channel provider’s and the clients.

2) Broadcast Center Module :

The Broadcast center Module will be performed at the

Broadcast Center. The Broadcast Centre is the central hub of the
system. At the broadcasting centre the television provider
receives the signal from the various channel programming
sources and beems a broadcast signal into the geostationary
satellites in the orbit. This is the main functional unit of DTH. In
this module necessary encoding, decoding, authentication etc
are performed.

3) Manager Module :

Manager Module is responsible for managing the services

provided by the DTH providers. The manager is sole responsible
for this module . The essential things done in this module are
fixing the price of the DTH service, providing advertisements for
the service, offering discounts for clients, providing suitable
packages for different customers etc. Also the management of
this DTH service will be performed at this module including cost
analysis, profit margin, etc etc.

4) Satellite Module :

The transmission signals which are broadcasted by the

Broadcast center are received by the satellites present in the
geostationary orbit of the earth. Since satellites are high in the
sky, it can have a better line of sight with the customer’s. The
satellite television system receives and transmits the radio
 signals with the help of a special antenna called Satellite dishes.
The Example of a Satellite used in DTH is NSS 6 satellite which is
a KU-band satellite with KA band uplink capacity and it provides
high speed interactive access and internet for multimedia
communication.

5) Receiver’s Dish Module :

The reciever’s dish which is aligned in same direction as of

satellite picks up the signals from the satellite (or multiple
satellites ) and passes it over to the receiver set top box in the
Home attached to the tv. This receiver or set top box decodes
and processes the signals and pass it over to television for
viewing.
LITERATURE SURVEY:

Which software modelling concepts are we using ?

DTH modeling uses the Unified Process Model of the object oriented software
engineering. The Unified process software development model is an popular iterative
and incremental software development process framework. Let us understand what the
unified process is from the phases and characteristics.

UNIFIED PROCESS MODEL LIFE CYCLE :

The Unified Process divides the project into four phases:

• Inception
• Elaboration
• Construction
• Transition

Inception Phase

Inception is the smallest phase in the project, and ideally it should be quite short.
If the Inception Phase is long then it may be an indication of excessive up-front
specification, which is contrary to the spirit of the Unified Process.

The following are typical goals for the Inception phase.

• Establish a justification or business case for the project

• Establish the project scope and boundary conditions
• Outline the use cases and key requirements that will drive the design tradeoffs
• Outline one or more candidate architectures
• Identify risks
• Prepare a preliminary project schedule and cost estimate

The Lifecycle Objective Milestone marks the end of the Inception phase.
Elaboration Phase

During the Elaboration phase the project team is expected to capture a healthy
majority of the system requirements. However, the primary goals of Elaboration are to
address known risk factors and to establish and validate the system architecture. Common
processes undertaken in this phase include the creation of use case diagrams, conceptual
diagrams (class diagrams with only basic notation) and package diagrams (architectural
diagrams).

The architecture is validated primarily through the implementation of an

Executable Architecture Baseline. This is a partial implementation of the system which
includes the core, most architecturally significant, components. It is built in a series of
small, timeboxed iterations. By the end of the Elaboration phase the system architecture
must have stabilized and the executable architecture baseline must demonstrate that the
architecture will support the key system functionality and exhibit the right behavior in
terms of performance, scalability and cost.

The final Elaboration phase deliverable is a plan (including cost and schedule
estimates) for the Construction phase. At this point the plan should be accurate and
credible, since it should be based on the Elaboration phase experience and since
significant risk factors should have been addressed during the Elaboration phase.

The Lifecycle Architecture Milestone marks the end of the Elaboration phase.

Construction Phase

Construction is the largest phase in the project. In this phase the remainder of the
system is built on the foundation laid in Elaboration. System features are implemented in
a series of short, timeboxed iterations. Each iteration results in an executable release of
the software. It is customary to write full text use cases during the construction phase and
each one becomes the start of a new iteration. Common UML (Unified Modelling
Language) diagrams used during this phase include Activity, Sequence, Collaboration,
State (Transition) and Interaction Overview diagrams.

The Initial Operational Capability Milestone marks the end of the Construction phase.

Transition Phase

The final project phase is Transition. In this phase the system is deployed to the
target users. Feedback received from an initial release (or initial releases) may result in
further refinements to be incorporated over the course of several Transition phase
iterations. The Transition phase also includes system conversions and user training.

The Product Release Milestone marks the end of the Transition phase.
UNIFIED PROCESS CHARACTERISTICS :

Diagram illustrating how the relative emphasis of different disciplines

changes over the course of the project

Iterative and Incremental

The Unified Process is an iterative and incremental development process. The Elaboration,
Construction and Transition phases are divided into a series of timeboxed iterations. (The
Inception phase may also be divided into iterations for a large project.) Each iteration results in
an increment, which is a release of the system that contains added or improved functionality
compared with the previous release.

Although most iterations will include work in most of the process disciplines (e.g. Requirements,
Design, Implementation, Testing) the relative effort and emphasis will change over the course of
the project.

Use Case Driven

In the Unified Process, use cases are used to capture the functional requirements and to define
the contents of the iterations. Each iteration takes a set of use cases or scenarios from
requirements all the way through implementation, test and deployment.
Architecture Centric

The Unified Process insists that architecture sit at the heart of the project team's efforts to shape
the system. Since no single model is sufficient to cover all aspects of a system, the Unified
Process supports multiple architectural models and views.

One of the most important deliverables of the process is the executable architecture baseline
which is created during the Elaboration phase. This partial implementation of the system serves
to validate the architecture and act as a foundation for remaining development.

Risk Focused

The Unified Process requires the project team to focus on addressing the most critical risks early
in the project life cycle. The deliverables of each iteration, especially in the Elaboration phase,
must be selected in order to ensure that the greatest risks are addressed first.
In our project case study of Direct to Home service, we implement the Unified Modelling
Process by following the four phases of the Unified process.

In the first Inception phase, we define the overall Plan of the whole process which is just a
prototype of the model. After defining the plan of the DTH we go for developing the scope and
objective of the DTH i.e to provide efficient wireless and high quality picture along with various
interactive programmes for the end users eradicating the need for buying wires and depending
upon the cable operators. The next step is to gather the requirements from the clients or end users
by asking them about the disadvantages of the cable system and the future enhancements they
would like to suggest which can improve the quality of the television system. All the User
Requirements(i.e functional and non functional) are gathered in the requirement list and the
requirement list is updated and observed to reflect the actual requirements which are useful to
our system. This is called Requirement Analysis from the user’s requirement meaning that we
perform a understanding or detailed study of the requirements and takes only that requirements
which are useful for our development of the DTH project.

In the second Elaboration phase, the updated Requirements which are collected after Inception
phase are elaborated and studied further in detail by expert team members and identify the use
cases for the DTH project. After detail elaboration of the requirements, Software Requirement
Specification is made by the developer and the contract is made for the DTH service to be
implemented by the Governing Authorities specifying cost and necessary infrastructure for the
system. The next step in the elaboration phase is to develop an architectural overview of the
whole system and designing each module of the whole architecture by using the concept of UML
language through different diagrams.

The Third phase is the Construction phase, the architectural and designed overview of the
Elaboration are taken into consideration and the execution of the DTH service is started. At the
first level, Coding is done by diving the DTH service into different modules and later integrating
all single modules into a collective single module by using high level languages. After the DTH
coding is done, the next level is to test the DTH system at different levels of testing like system
level or unit level. This testing is performed by skilled testing experts. Now the tested DTH
project is passed onto next and the final phase of the unified process.
In the final phase of Transition, DTH system is tested and deployed to the target users. During
this deployment process we train the end users about how to use the DTH system by providing
the installation procedure and manuals for installing the SET TOP BOX of the DTH system.
Also we collect the feedback from the target users regarding the initial release of the product
which can be reviewed and maintained or refined for further transition phases.
Building blocks of UML:

The vocabulary of the UML encompasses three kinds of building blocks:

• Things
• Relationships
• Diagrams

(1) Things:

Things are the most important building blocks of UML. They are abstractions that are first class
citizens in a model. Things can be:

• Structural
• Behavioral
• Grouping
• Annotational

Structural things:

The Structural things define the static part of the model. They represent physical and
conceptual elements. Following are the brief descriptions of the seven structural things in UML.

Class:

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. Graphically, a class is
rendered as a rectangle, usually including its name, attribute, and operations as show in the
below figure.
Interface:

Interface defines a set of operations which specify the responsibility of a class. An Interface
might represent the complete behavior of a class or component or only a part of that behavior.

Collaboration:

Collaboration defines interaction between elements and is a society of roles and other elements
that work together to provide some cooperative behavior that’s bigger than the sum of its
elements. Therefore collaborations have structural as well as behavior dimensions.

Use case:

Use case is a description of set of sequence of actions that a system performs that yields a
observable result of value to a particular actor. A use case is used to structure the behavioral
things in a model. A use case is realized by a collaboration. Graphically use case is rendered as
an ellipse with solid lines, usually including its name as shown below.

Component:

Component is a physical and replaceable part of the system that conforms to and provides the
realization of a set of interfaces. A component typically represents the physical packaging of
logical elements such as classes, interfaces and collaboration. Graphically an component is
rendered as a rectangle with tabs, usually including its name as shown below.
Node:

A node can be defined as 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 represented as a cube including its name.

Behavioral things:

A behavioral thing consists of the dynamic parts of UML models. Following are the behavioral
things:

Interaction:

Interaction is defined as a behavior that consists of a group of messages exchanged among

elements to accomplish a specific task. An interaction involves a number of other elements
including messages, action sequence, and links. Graphically the message is rendered as a
directed line, almost including the name of its operation.

State machine:

State machine is useful when the state of an object in its life cycle is important. It defines the
sequence of states an object goes through in response to events. Events are external factors
responsible for state change. Graphically a state is rendered as a rounded rectangle usually
including its name and its substates.
Grouping things:

Grouping things can be defined as a mechanism to group elements of a UML model together.
There is only one grouping thing available:

Package:

Package is the only one grouping thing available for gathering structural and behavioral things. It
is a General purpose mechanism for organizing elements into groups. Structural or behavior or
other grouping things can be placed in a package. Graphically a package is rendered as a tabbed
folder usually including its name n contents.

Annotational things:

Annotational things can be defined as a mechanism to capture remarks, descriptions, and

comments of UML model elements. Note is the only one Annotational thing available.

Note:

A note is used to render comments, constraints etc of an UML element.

(2) Relationship:

Relationship is another most important building block of UML. It shows how elements are
associated with each other and this association describes the functionality of an application.

There are four kinds of relationships available.

Dependency:

Dependency is a semantic relationship between two things in which change in one

thing(independent thing) also affects the semantics of the other things(dependent thing).
Graphically it is rendered as a dashed line,possibly directed.

Association:

Association is structural relationship that describes a set of links that connects elements of an
UML model. It also describes how many objects are taking part in that relationship. Aggregation
is a special kind of association representing structural relationship between a whole and its parts.
Generally association is rendered as a solid line, possibly directed and often containing other
adornments such as multiplicity and role names.
Generalization:

Generalization can be defined as a relationship which connects a specialized element with a

generalized element. It basically describes inheritance relationship in the world of objects.
Graphically Generalization relationship is rendered as a solid line with a hollow arrowhead
pointing to the parent as shown below.

Realization:

Realization can be defined as a relationship between two classifiers, wherein one classifier
specifies a contract that another classifier guarantees to carry out.. This relationship exists in case
of interfaces and the classes or components that realize them and between use cases and the
collaborations that realize them. Graphically it is rendered as a cross between a generalization
and a dependency relationship as shown below.

(3) UML Diagrams:

UML diagrams are the ultimate output of the entire discussion. All the elements, relationships
are used to make a complete UML diagram and the diagram represents a system.

The visual effect of the UML diagram is the most important part of the entire process. All the
other elements are used to make it a complete one.

There are two broad categories of diagrams and then are again divided into sub-categories:
 • Structural Diagrams
• Behavioral Diagrams

Structural Diagrams:

The structural diagrams represent the static aspect of the system. These static aspects represent
those parts of a diagram which forms the main structure and therefore stable.

These static parts are represents by classes, interfaces, objects, components and nodes. The four
structural diagrams are:

• Class diagram
• Object diagram
• Component diagram
• Deployment diagram

Class Diagram:

Class diagrams are the most common diagrams used in UML. Class diagram consists of classes,
interfaces, associations and collaboration.

Class diagrams basically represent the object oriented view of a system which is static in nature.

Active class is used in a class diagram to represent the concurrency of the system.
Class diagram represents the object orientation of a system. So it is generally used for
development purpose. This is the most widely used diagram at the time of system construction.

The class diagram is a static diagram. It represents the static view of an application. Class
diagram is not only used for visualizing, describing and documenting different aspects of a
system but also for constructing executable code of the software application.

The class diagram describes the attributes and operations of a class and also the constraints
imposed on the system. The class diagrams are widely used in the modelling of object oriented
systems because they are the only UML diagrams which can be mapped directly with object
oriented languages.

The class diagram shows a collection of classes, interfaces, associations, collaborations and
constraints. It is also known as a structural diagram.

Purpose:

The purpose of the class diagram is to model the static view of an application. The class
diagrams are the only diagrams which can be directly mapped with object oriented languages and
thus widely used at the time of construction.

The UML diagrams like activity diagram, sequence diagram can only give the sequence flow of
the application but class diagram is a bit different. So it is the most popular UML diagram in the
coder community.

So the purpose of the class diagram can be summarized as:

• Analysis and design of the static view of an application.

• Describe responsibilities of a system.
• Base for component and deployment diagrams.
• Forward and reverse engineering.

How to draw Class Diagram

Class diagrams are the most popular UML diagrams used for construction of software
applications. So it is very important to learn the drawing procedure of class diagram.

Class diagrams have lot of properties to consider while drawing but here the diagram will be
considered from a top level view.

Class diagram is basically a graphical representation of the static view of the system and
represents different aspects of the application. So a collection of class diagrams represent the
whole system.

The following points should be remembered while drawing a class diagram:

 • The name of the class diagram should be meaningful to describe the aspect of the system.
• Each element and their relationships should be identified in advance.
• Responsibility (attributes and methods) of each class should be clearly identified.
• For each class minimum number of properties should be specified. Because unnecessary
properties will make the diagram complicated.
• Use notes when ever required to describe some aspect of the diagram. Because at the end
of the drawing it should be understandable to the developer/coder.
• Finally, before making the final version, the diagram should be drawn on plain paper and
rework as many times as possible to make it correct

Where to use Class Diagrams

Class diagram is a static diagram and it is used to model static view of a system. The static view
describes the vocabulary of the system.

Class diagram is also considered as the foundation for component and deployment diagrams.
Class diagrams are not only used to visualize the static view of the system but they are also used
to construct the executable code for forward and reverse engineering of any system.

Generally UML diagrams are not directly mapped with any object oriented programming
languages but the class diagram is an exception.

Class diagram clearly shows the mapping with object oriented languages like Java, C++ etc. So
from practical experience class diagram is generally used for construction purpose.

So in a brief, class diagrams are used for:

• Describing the static view of the system.

• Showing the collaboration among the elements of the static view.
• Describing the functionalities performed by the system.
• Construction of software applications using object oriented languages.

Now the following diagram is an example of an Order System of an application. So it describes a

particular aspect of the entire application.

• First of all Order and Customer are identified as the two elements of the system and they
have a one to many relationship because a customer can have multiple orders.
• We would keep Order class is an abstract class and it has two concrete classes
(inheritance relationship) SpecialOrder and NormalOrder.
 • The two inherited classes have all the properties as the Order class. In addition they have
additional functions like dispatch () and receive ().

So the following class diagram has been drawn considering all the points mentioned above:

Object Diagram:

Object diagrams can be described as an instance of class diagram. So these diagrams are more
close to real life scenarios where we implement a system.

Object diagrams are a set of objects and their relationships just like class diagrams and also
represent the static view of the system.

The usage of object diagrams is similar to class diagrams but they are used to build prototype of
a system from practical perspective.

Object diagrams are derived from class diagrams so object diagrams are dependent upon class
diagrams.

Object diagrams represent an instance of a class diagram. The basic concepts are similar for class
diagrams and object diagrams. Object diagrams also represent the static view of a system but this
static view is a snapshot of the system at a particular moment.
Object diagrams are used to render a set of objects and their relationships as an instance.

Purpose:

The purpose of a diagram should be understood clearly to implement it practically. The purposes
of object diagrams are similar to class diagrams.

The difference is that a class diagram represents an abstract model consists of classes and their
relationships. But an object diagram represents an instance at a particular moment which is
concrete in nature.

It means the object diagram is more close to the actual system behaviour. The purpose is to
capture the static view of a system at a particular moment.

So the purpose of the object diagram can be summarized as:

• Forward and reverse engineering.

• Object relationships of a system
• Static view of an interaction.
• Understand object behavior and their relationship from practical perspective

We have already discussed that an object diagram is an instance of a class diagram. It implies
that an object diagram consists of instances of things used in a class diagram.

So both diagrams are made of same basic elements but in different form. In class diagram
elements are in abstract form to represent the blue print and in object diagram the elements are in
concrete form to represent the real world object.

To capture a particular system, numbers of class diagrams are limited. But if we consider object
diagrams then we can have unlimited number of instances which are unique in nature. So only
those instances are considered which are having impact on the system.

From the above discussion it is clear that a single object diagram cannot capture all the necessary
instances or rather cannot specify all objects of a system. So the solution is:

• First, analyze the system and decide which instances are having important data and
association.
• Second, consider only those instances which will cover the functionality.
• Third, make some optimization as the numbers of instances are unlimited.

Before drawing an object diagrams the following things should be remembered and understood
clearly:

• Object diagrams are consist of objects.

• The link in object diagram is used to connect objects.
• Objects and links are the two elements used to construct an object diagram.
Now after this the following things are to be decided before starting the construction of the
diagram:

• The object diagram should have a meaningful name to indicate its purpose.
• The most important elements are to be identified.
• The association among objects should be clarified.
• Values of different elements need to be captured to include in the object diagram.
• Add proper notes at points where more clarity is required.

Object diagrams can be imagined as the snapshot of a running system at a particular moment.
Now to clarify it we can take an example of a running train.

Now if you take a snap of the running train then you will find a static picture of it having the
following:

• A particular state which is running

• A particular number of passengers. Which will change if the snap is taken in a different
time.

So here we can imagine the snap of the running train is an object having the above values. And
this is true for any real life simple or complex system. In a brief, object diagrams are used for:

• Making the prototype of a system.

• Reverse engineering.
• Modeling complex data structures.
• Understanding the system from practical perspective.

The following diagram is an example of an object diagram. It represents the Order management
system which we have discussed in Class Diagram. The following diagram is an instance of the
system at a particular time of purchase. It has the following objects

• Customer
• Order
• SpecialOrder
• NormalOrder

Now the customer object (C) is associated with three order objects (O1, O2 and O3). These order
objects are associated with special order and normal order objects (S1, S2 and N1). The customer
is having the following three orders with different numbers (12, 32 and 40) for the particular
time considered.

Now the customer can increase number of orders in future and in that scenario the object
diagram will reflect that. If order, special order and normal order objects are observed then we
you will find that they are having some values.
For orders the values are 12, 32, and 40 which implies that the objects are having these values for
the particular moment (here the particular time when the purchase is made is considered as the
moment) when the instance is captured.

The same is for special order and normal order objects which are having number of orders as 20,
30 and 60. If a different time of purchase is considered then these values will change
accordingly.

So the following object diagram has been drawn considering all the points mentioned above:

Component Diagram:

Component diagrams represent a set of components and their relationships. These components
consist of classes, interfaces or collaborations.

So Component diagrams represent the implementation view of a system.

During design phase software artifacts (classes, interfaces etc) of a system are arranged in
different groups depending upon their relationship. Now these groups are known as components.

Finally, component diagrams are used to visualize the implementation.

Component diagrams are different in terms of nature and behaviour. Component diagrams are
used to model physical aspects of a system.

Now the question is what are these physical aspects? Physical aspects are the elements like
executables, libraries, files, documents etc which resides in a node.
So component diagrams are used to visualize the organization and relationships among
components in a system. These diagrams are also used to make executable systems.

Purpose:

Component diagram is a special kind of diagram in UML. The purpose is also different from all
other diagrams discussed so far. It does not describe the functionality of the system but it
describes the components used to make those functionalities.

So from that point component diagrams are used to visualize the physical components in a
system. These components are libraries, packages, files etc.

Component diagrams can also be described as a static implementation view of a system. Static
implementation represents the organization of the components at a particular moment.

A single component diagram cannot represent the entire system but a collection of diagrams are
used to represent the whole.

So the purpose of the component diagram can be summarized as:

• Visualize the components of a system.

• Construct executables by using forward and reverse engineering.
• Describe the organization and relationships of the components.

How to draw Component Diagram

Component diagrams are used to describe the physical artifacts of a system. This artifact
includes files, executables, libraries etc.

So the purpose of this diagram is different, Component diagrams are used during the
implementation phase of an application. But it is prepared well in advance to visualize the
implementation details.

Initially the system is designed using different UML diagrams and then when the artifacts are
ready component diagrams are used to get an idea of the implementation.

This diagram is very important because without it the application cannot be implemented
efficiently. A well prepared component diagram is also important for other aspects like
application performance, maintenance etc.

So before drawing a component diagram the following artifacts are to be identified clearly:

• Files used in the system.

• Libraries and other artifacts relevant to the application.
• Relationships among the artifacts.
Now after identifying the artifacts the following points needs to be followed:

• Use a meaningful name to identify the component for which the diagram is to be drawn.
• Prepare a mental layout before producing using tools.
• Use notes for clarifying important points.

The following is a component diagram for order management system. Here the artifacts are files.
So the diagram shows the files in the application and their relationships. In actual the component
diagram also contains dlls, libraries, folders etc.

In the following diagram four files are identified and their relationships are produced.
Component diagram cannot be matched directly with other UML diagrams discussed so far.
Because it is drawn for completely different purpose.

Where to use Component Diagrams

We have already described that component diagrams are used to visualize the static
implementation view of a system. Component diagrams are special type of UML diagrams used
for different purposes.

These diagrams show the physical components of a system. To clarify it, we can say that
component diagrams describe the organization of the components in a system.

Organization can be further described as the location of the components in a system. These
components are organized in a special way to meet the system requirements.

As we have already discussed those components are libraries, files, executables etc. Now before
implementing the application these components are to be organized. This component
organization is also designed separately as a part of project execution.

Component diagrams are very important from implementation perspective. So the

implementation team of an application should have a proper knowledge of the component
details.

Now the usage of component diagrams can be described as:

• Model the components of a system.

• Model database schema.
• Model executables of an application.
• Model system's source code.

So the following component diagram has been drawn considering all the points mentioned
above:
Deployment diagrams:

Deployment diagrams are a set of nodes and their relationships. These nodes are physical entities
where the components are deployed.

Deployment diagrams are used for visualizing deployment view of a system. This is generally
used by the deployment team.

Deployment diagrams are used to visualize the topology of the physical components of a system
where the software components are deployed.

So deployment diagrams are used to describe the static deployment view of a system.
Deployment diagrams consist of nodes and their relationships.

Purpose:

The name Deployment itself describes the purpose of the diagram. Deployment diagrams are
used for describing the hardware components where software components are deployed.
Component diagrams and deployment diagrams are closely related.
Component diagrams are used to describe the components and deployment diagrams shows how
they are deployed in hardware.

UML is mainly designed to focus on software artifacts of a system. But these two diagrams are
special diagrams used to focus on software components and hardware components.

So most of the UML diagrams are used to handle logical components but deployment diagrams
are made to focus on hardware topology of a system. Deployment diagrams are used by the
system engineers.

The purpose of deployment diagrams can be described as:

• Visualize hardware topology of a system.

• Describe the hardware components used to deploy software components.
• Describe runtime processing nodes.

Deployment diagram represents the deployment view of a system. It is related to the component
diagram. Because the components are deployed using the deployment diagrams. A deployment
diagram consists of nodes. Nodes are nothing but physical hardwares used to deploy the
application.

Deployment diagrams are useful for system engineers.

An efficient deployment diagram is very important because it controls the following parameters

• Performance
• Scalability
• Maintainability
• Portability

So before drawing a deployment diagram the following artifacts should be identified:

• Nodes
• Relationships among nodes

The following deployment diagram is a sample to give an idea of the deployment view of order
management system. Here we have shown nodes as:

• Monitor
• Modem
• Caching server
• Server
The application is assumed to be a web based application which is deployed in a clustered
environment using server 1, server 2 and server 3. The user is connecting to the application using
internet. The control is flowing from the caching server to the clustered environment.

Behavioral Diagrams:

Any system can have two aspects, static and dynamic. So a model is considered as complete
when both the aspects are covered fully.

Behavioral diagrams basically capture the dynamic aspect of a system. Dynamic aspect can be
further described as the changing/moving parts of a system.

UML has the following five types of behavioral diagrams:

• Use case diagram

• Sequence diagram
• Collaboration diagram
• Statechart diagram
• Activity diagram
Use case Diagram:

Use case diagrams are a set of use cases, actors and their relationships.
They represent the use case view of a system.

A use case represents a particular functionality of a system.

A use case describes a sequence of actions that provide something of

measurable value to an actor and is drawn as a horizontal ellipse an actor is
a person, organization, or external system that plays a role in one or more
interactions with your system.

So use case diagram is used to describe the relationships among the functionalities and their
internal/external controllers. These controllers are known as actors.
To model a system the most important aspect is to capture the dynamic behaviour. To clarify a
bit in details, dynamic behaviour means the behaviour of the system when it is running
/operating.

So only static behaviour is not sufficient to model a system rather dynamic behaviour is more
important than static behaviour. In UML there are five diagrams available to model dynamic
nature and use case diagram is one of them. Now as we have to discuss that the use case diagram
is dynamic in nature there should be some internal or external factors for making the interaction.

These internal and external agents are known as actors. So use case diagrams are consists of
actors, use cases and their relationships. The diagram is used to model the system/subsystem of
an application. A single use case diagram captures a particular functionality of a system.

So to model the entire system numbers of use case diagrams are used.

Purpose:

The purpose of use case diagram is to capture the dynamic aspect of a system. But this definition
is too generic to describe the purpose.

Because other four diagrams (activity, sequence, collaboration and Statechart) are also having
the same purpose. So we will look into some specific purpose which will distinguish it from
other four diagrams.

Use case diagrams are used to gather the requirements of a system including internal and
external influences. These requirements are mostly design requirements. So when a system is
analyzed to gather its functionalities use cases are prepared and actors are identified.

Now when the initial task is complete use case diagrams are modelled to present the outside
view.

So in brief, the purposes of use case diagrams can be as follows:

• Used to gather requirements of a system.

• Used to get an outside view of a system.
• Identify external and internal factors influencing the system.
• Show the interacting among the requirements are actors.

Use case diagrams are considered for high level requirement analysis of a system. So when the
requirements of a system are analyzed the functionalities are captured in use cases.

So we can say that uses cases are nothing but the system functionalities written in an organized
manner. Now the second things which are relevant to the use cases are the actors. Actors can be
defined as something that interacts with the system.
The actors can be human user, some internal applications or may be some external applications.
So in a brief when we are planning to draw an use case diagram we should have the following
items identified.

• Functionalities to be represented as an use case

• Actors
• Relationships among the use cases and actors.

Use case diagrams are drawn to capture the functional requirements of a system. So after
identifying the above items we have to follow the following guidelines to draw an efficient use
case diagram.

• The name of a use case is very important. So the name should be chosen in such a way so
that it can identify the functionalities performed.
• Give a suitable name for actors.
• Show relationships and dependencies clearly in the diagram.
• Do not try to include all types of relationships. Because the main purpose of the diagram
is to identify requirements.
• Use note when ever required to clarify some important points

As we have already discussed there are five diagrams in UML to model dynamic view of a
system. Now each and every model has some specific purpose to use. Actually these specific
purposes are different angles of a running system.

So to understand the dynamics of a system we need to use different types of diagrams. Use case
diagram is one of them and its specific purpose is to gather system requirements and actors.

Use case diagrams specify the events of a system and their flows. But use case diagram never
describes how they are implemented. Use case diagram can be imagined as a black box where
only the input, output and the function of the black box is known.

These diagrams are used at a very high level of design. Then this high level design is refined
again and again to get a complete and practical picture of the system. A well structured use case
also describes the pre condition, post condition, exceptions. And these extra elements are used to
make test cases when performing the testing.

Although the use cases are not a good candidate for forward and reverse engineering but still
they are used in a slight different way to make forward and reverse engineering. And the same is
true for reverse engineering. Still use case diagram is used differently to make it a candidate for
reverse engineering.

In forward engineering use case diagrams are used to make test cases and in reverse engineering
use cases are used to prepare the requirement details from the existing application.

So the following are the places where use case diagrams are used:
 • Requirement analysis and high level design.
• Model the context of a system.
• Reverse engineering.
• Forward engineering.

The following is a sample use case diagram representing the order management system. So if we
look into the diagram then we will find three use cases (Order, SpecialOrder and NormalOrder)
and one actor which is customer.

The SpecialOrder and NormalOrder use cases are extended from Order use case. So they have
extends relationship. Another important point is to identify the system boundary which is shown
in the picture. The actor Customer lies outside the system as it is an external user of the system.

Sequence Diagram:

A sequence diagram is an interaction diagram. From the name it is clear that the diagram deals
with some sequences, which are the sequence of messages flowing from one object to another.

Interaction among the components of a system is very important from implementation and
execution perspective.

So Sequence diagram is used to visualize the sequence of calls in a system to perform a specific
functionality.

Sequence diagram emphasizes on time sequence of messages and collaboration diagram

emphasizes on the structural organization of the objects that send and receive messages.

The purposes of interaction diagrams are to visualize the interactive behaviour of the system.
Now visualizing interaction is a difficult task. So the solution is to use different types of models
to capture the different aspects of the interaction.

That is why sequence and collaboration diagrams are used to capture dynamic nature but from a
different angle.
So the purposes of interaction diagram can be describes as:

• To capture dynamic behaviour of a system.

• To describe the message flow in the system.
• To describe structural organization of the objects.
• To describe interaction among objects.

The main purposes of both the diagrams are similar as they are used to capture the dynamic
behaviour of a system. But the specific purposes are more important to clarify and understood.

Sequence diagrams are used to capture the order of messages flowing from one object to another.
And the collaboration diagrams are used to describe the structural organizations of the objects
taking part in the interaction. A single diagram is not sufficient to describe the dynamic aspect of
an entire system so a set of diagrams are used to capture is as a whole.

The interaction diagrams are used when we want to understand the message flow and the
structural organization. Now message flow means the sequence of control flow from one object
to another and structural organization means the visual organization of the elements in a system.

In a brief the following are the usages of interaction diagrams:

• To model flow of control by time sequence.

• To model flow of control by structural organizations.
• For forward engineering.
• For reverse engineering.

The sequence diagram is having four objects (Customer, Order, SpecialOrder and NormalOrder).

The following diagram has shown the message sequence for SpecialOrder object and the same
can be used in case of NormalOrder object. Now it is important to understand the time sequence
of message flows. The message flow is nothing but a method call of an object.

The first call is sendOrder () which is a method of Order object. The next call is confirm ()
which is a method of SpecialOrder object and the last call is Dispatch () which is a method of
SpecialOrder object. So here the diagram is mainly describing the method calls from one object
to another and this is also the actual scenario when the system is running.
Collaboration Diagram:

Collaboration diagram is another form of interaction diagram. It represents the structural

organization of a system and the messages sent/received. Structural organization consists of
objects and links.

The purpose of collaboration diagram is similar to sequence diagram. But the specific purpose of
collaboration diagram is to visualize the organization of objects and their interaction.

The method calls are similar to that of a sequence diagram. But the difference is that the
sequence diagram does not describe the object organization where as the collaboration diagram
shows the object organization.

Now to choose between these two diagrams the main emphasis is given on the type of
requirement. If the time sequence is important then sequence diagram is used and if organization
is required then collaboration diagram is used.
Statechart Diagram:

Any real time system is expected to be reacted by some kind of internal/external events. These
events are responsible for state change of the system.

Statechart diagram is used to represent the event driven state change of a system. It basically
describes the state change of a class, interface etc.

State chart diagram is used to visualize the reaction of a system by internal/external factors. The
name of the diagram itself clarifies the purpose of the diagram and other details. It describes
different states of a component in a system. The states are specific to a component/object of a
system.

A Statechart diagram describes a state machine. Now to clarify it state machine can be defined as
a machine which defines different states of an object and these states are controlled by external
or internal events.

Activity diagram explained in next chapter is a special kind of a Statechart diagram. As

Statechart diagram defines states it is used to model lifetime of an object.
Purpose:

Statechart diagram is one of the five UML diagrams used to model dynamic nature of a system.
They define different states of an object during its lifetime. And these states are changed by
events. So Statechart diagrams are useful to model reactive systems. Reactive systems can be
defined as a system that responds to external or internal events.

Statechart diagram describes the flow of control from one state to another state. States are
defined as a condition in which an object exists and it changes when some event is triggered. So
the most important purpose of Statechart diagram is to model life time of an object from creation
to termination.

Statechart diagrams are also used for forward and reverse engineering of a system. But the main
purpose is to model reactive system.

Following are the main purposes of using Statechart diagrams:

• To model dynamic aspect of a system.

• To model life time of a reactive system.
• To describe different states of an object during its life time.
• Define a state machine to model states of an object.

Statechart diagram is used to describe the states of different objects in its life cycle. So the
emphasis is given on the state changes upon some internal or external events. These states of
objects are important to analyze and implement them accurately.

Statechart diagrams are very important for describing the states. States can be identified as the
condition of objects when a particular event occurs.

Before drawing a Statechart diagram we must have clarified the following points:

• Identify important objects to be analyzed.

• Identify the states.
• Identify the events.

Statechart diagram defines the states of a component and these state changes are dynamic in
nature. So its specific purpose is to define state changes triggered by events. Events are internal
or external factors influencing the system.

Statechart diagrams are used to model states and also events operating on the system. When
implementing a system it is very important to clarify different states of an object during its life
time and statechart diagrams are used for this purpose. When these states and events are
identified they are used to model it and these models are used during implementation of the
system.

If we look into the practical implementation of Statechart diagram then it is mainly used to
analyze the object states influenced by events. This analysis is helpful to understand the system
behaviour during its execution.

So the main usages can be described as:

• To model object states of a system.

• To model reactive system. Reactive system consists of reactive objects.
• To identify events responsible for state changes.
• Forward and reverse engineering.

The following is an example of a Statechart diagram where the state of Order object is analyzed.

The first state is an idle state from where the process starts. The next states are arrived for events
like send request, confirm request, and dispatch order. These events are responsible for state
changes of order object.

During the life cycle of an object (here order object) it goes through the following states and
there may be some abnormal exists also. This abnormal exit may occur due to some problem in
the system. When the entire life cycle is complete it is considered as the complete transaction as
mentioned below.

The initial and final state of an object is also shown below.

Activity Diagram:

Activity diagram describes the flow of control in a system. So it consists of activities and links.
The flow can be sequential, concurrent or branched.

Activities are nothing but the functions of a system. Numbers of activity diagrams are prepared
to capture the entire flow in a system.

Activity diagrams are used to visualize the flow of controls in a system. This is prepared to have
an idea of how the system will work when executed.

Activity diagram is another important diagram in UML to describe dynamic aspects of the
system.

Activity diagram is basically a flow chart to represent the flow form one activity to another
activity. The activity can be described as an operation of the system.

So the control flow is drawn from one operation to another. This flow can be sequential,
branched or concurrent. Activity diagrams deals with all type of flow control by using different
elements like fork, join etc.

Purpose:

The basic purposes of activity diagrams are similar to other four diagrams. It captures the
dynamic behaviour of the system. Other four diagrams are used to show the message flow from
one object to another but activity diagram is used to show message flow from one activity to
another.

Activity is a particular operation of the system. Activity diagrams are not only used for
visualizing dynamic nature of a system but they are also used to construct the executable system
by using forward and reverse engineering techniques. The only missing thing in activity diagram
is the message part.

It does not show any message flow from one activity to another. Activity diagram is some time
considered as the flow chart. Although the diagrams looks like a flow chart but it is not. It shows
different flow like parallel, branched, concurrent and single.

So the purposes can be described as:

 • Draw the activity flow of a system.
• Describe the sequence from one activity to another.
• Describe the parallel, branched and concurrent flow of the system.

Activity diagrams are mainly used as a flow chart consists of activities performed by the system.
But activity diagram are not exactly a flow chart as they have some additional capabilities. These
additional capabilities include branching, parallel flow, swimlane etc.

Before drawing an activity diagram we must have a clear understanding about the elements used
in activity diagram. The main element of an activity diagram is the activity itself. An activity is a
function performed by the system. After identifying the activities we need to understand how
they are associated with constraints and conditions.

So before drawing an activity diagram we should identify the following elements:

• Activities
• Association
• Conditions
• Constraints

Once the above mentioned parameters are identified we need to make a mental layout of the
entire flow. This mental layout is then transformed into an activity diagram.

The basic usage of activity diagram is similar to other four UML diagrams. The specific usage is
to model the control flow from one activity to another. This control flow does not include
messages.

The activity diagram is suitable for modeling the activity flow of the system. An application can
have multiple systems. Activity diagram also captures these systems and describes flow from one
system to another. This specific usage is not available in other diagrams. These systems can be
database, external queues or any other system.

Now we will look into the practical applications of the activity diagram. From the above
discussion it is clear that an activity diagram is drawn from a very high level. So it gives high
level view of a system. This high level view is mainly for business users or any other person who
is not a technical person.

This diagram is used to model the activities which are nothing but business requirements. So the
diagram has more impact on business understanding rather implementation details.

Following are the main usages of activity diagram:

• Modeling work flow by using activities.

• Modeling business requirements.
 • High level understanding of the system's functionalities.
• Investigate business requirements at a later stage.

The following is an example of an activity diagram for order management system. In the diagram
four activities are identified which are associated with conditions. One important point should be
clearly understood that an activity diagram cannot be exactly matched with the code. The activity
diagram is made to understand the flow of activities and mainly used by the business users.

The following diagram is drawn with the four main activities:

• Send order by the customer

• Receipt of the order
• Confirm order
• Dispatch order

After receiving the order request condition checks are performed to check if it is normal or
special order. After the type of order is identified dispatch activity is performed and that is
marked as the termination of the process.

USE CASE DIAGRAM:

Use Case Diagram shows set of use cases and actors and their relationships.
Use case diagrams addresses the static view of a system. These diagrams
are especially important in organizing and modeling the behaviors of the
class.

The actors of our use case diagram are

• Customer
• Administrator
The use case diagram is shown below:

CLASS DIAGRAM:

The Class diagram shows a set of classes, interfaces, and collaborations and
their relationships. These diagrams are the most common diagrams found in
object-oriented systems. Class diagrams address the static view of a system.
Class diagrams that include active classes address the static process view of
the system.

The different classes that are included in our project are:

• Administrator
• Customer
• Payment
• Policies
• Loans

ACTIVITY DIAGRAM:

The Activity Diagram is a special kind of state chart diagram that shows the
flow from activity to activity within a system. Activity Diagram addresses the
dynamic view of the system. They are especially important for modeling the
function of a system and emphasize the flow of control among the objects.

The Activity Diagram of our project is shown below:

HOW MUCH WORK HAVE BEEN DONE BEFORE ON DTH

The entire satellite communications industry -- not just the DTH segment -- can trace its
common heritage to one man. That man is the noted futurist and author Arthur C. Clark. e
penned a paper entitled, "Extraterrestrial Relays." Published in October 1945 by "Wireless World
Magazine," this article advanced a theory that world-wide communications could be
accomplished by placing three space platforms into special orbits 22,300 miles above the
equator. Clark explained that at this altitude, the platforms would orbit the earth at exactly the
same speed as the earth turned -- thus they would appear to remain motionless in space when
viewed from the ground.

Obviously, Clark's paper was far ahead of its time. The world had yet to see the
widespread development of TV -- let alone the ability to place any object, much less a large
communications platform, into orbit. The world would have to wait a dozen years before the first
man-made object, Sputnik, found its way into orbit.

On June 25, 1967, for two hours 26 nations of the world were joined together by an
invisible electromagnetic grid utilizing four satellites. The London-based production, in glorious
black and white, was the first-ever use of satellites to simultaneously interconnect remote corners
of the world to a single program event. The program, appropriately entitled "Our World,"
included the Maria Callas, The Beatles debuting the song "All You Need Is Love" to an audience
estimated at more than 600 million.

During the course of the telecast, live feeds were interconnected through a pair of early
design Intelsats, an American experimental satellite (ATS-1), and a Russian Molniya class bird.
The New York Times would write about the ground-breaking telecast, "Our World was a
compelling reaffirmation of the potential of the home screen to unify the peoples of the world."
Less than three decades later, or approximately the period of one generation of mankind, more
than 30 million homes in the world are equipped with their own satellite dishes. The early
Intelsat, ATS, and Molniya satellites were capable of relaying one (or at most, two) simultaneous
TV programs; each satellite of the current generation easily can deliver as many as 200 program
Channels to dish antennas less than one-thirtieth of the size required for reception of the original
"Our World" telecast.

Well before the turn of the century, virtually any location in Asia or the Pacific will have
direct access to hundreds of channels of TV, high-speed Internet links, and thousands of radio
program channels. It is not an exaggeration to suggest that satellites are redesigning the very
fabric of life by creating full-time universal access to "our world."
 In 1976, premium programmer HBO made history when it initiated satellite delivery of
programming to cable headends with the heavyweight boxing battle dubbed, "The Thriller From
Manila." The move by HBO was followed quickly by Ted Turner, who began uplinking his
heretofore unknown Atlanta UHF-TV station, now known as WTBS. Turner branded it
America's Station, and the superstation was born. 1977 saw Pat Robertson launch the first
satellite-delivered basic cable service -- CBN Cable Network -- the predecessor of The Family
Channel.

In 1981-1985 The DTH industry grew quickly from its modest beginnings. As each new
system was installed, the word of mouth advertising grew for the industry. Obviously the early
DTH systems were very large, thus the simple act of having one installed drew the attention and
interest of the neighborhood. Once non-dishowners experienced the diversity of satellite-
delivered programming (new cable services were now launching at a rapid pace) coupled with
the unsurpassed audio and video quality offered by a DTH system, the fever began to spread
across the land.

The DTH industry will remember 1985 for its rollercoaster ride of highs and lows. From
a shipment perspective, the chart clearly shows that satellite TV was hot -- some 735,000
systems were produced in the United States. Some months in the latter part of the year saw in
excess of 80,000 units sold. An industry which began the year with less than a million consumers
ended the year with over 1.7 million satisfied customers. Indeed, to the outside observer, the
DTH industry appeared to be one of the hottest technology bets available. In fact, this success
was setting the industry up for a dramatic tumble -- one which would take years to overcome.

January 15, 1986 began like any other day in America. The lines were long at satellite
dealerships, and sales were good. As the day wore on, suddenly the video on HBO was replaced
by unrecognizable lines and the audio was gone. At that very moment, the hardware-based DTH
industry transitioned into one which would be driven by the sale of software - programming.
January 15, 1986 began like any other day in America. The lines were long at satellite
dealerships, and sales were good. As the day wore on, suddenly the video on HBO was replaced
by unrecognizable lines and the audio was gone. At that very moment, the hardware-based DTH
industry transitioned into one which would be driven by the sale of software - programming.
This led to the outburst of even more DTH consumer sales.

In December 1986 as a sign of unification of DTH service, The SBCA was formed as a
result of the merger of two trade organizations -- the Society of Private and Commercial Earth
Stations -- (SPACE) and the Direct Broadcast Satellite Association (DBSA). SPACE had
represented primarily the manufacturers, distributors, and retailers of DTH systems. DBSA was
comprised of companies such as RCA Americom, AT&T, Hughes, Comsat, and USSB -- all of
which were interested in high power DBS.
 In 1994 The DTH industry had emerged from its second major crisis, and now, this
industry which had begun so humbly, stood on the threshold of a new era, The Dawn of DBS.
While 1994 marked the arrival of medium and high-power Ku-Band DBS service, it was also
represented one of the best years ever for the C-Band industry.With piracy effectively under
control, and consumer interest in satellite TV growing as a result of initial marketing of DBS
hardware, C-Band sales boomed.

All of this technology creates virtually unlimited opportunities for new business
enterprise and personal development. You are holding in your hand a key that will unlock for
you, your family, and your business the "secrets" of the 21st century "Information Revolution."
There has never been a point in the history of the world when so much opportunity has presented
itself to mankind.

HISTORY OF DTH IN INDIA :-

DTH services were first proposed in India in 1996. But they did not pass approval
because there were concerns over national security and a cultural invasion. In 1997, the
government even imposed a ban when the Rupert Murdoch-owned Indian Sky Broadcasting
(ISkyB) was about to launch its DTH services in India.

Finally in 2000, DTH was allowed. The new policy requires all operators to set up earth
stations in India within 12 months of getting a license. DTH licenses in India will cost $2.14
million and will be valid for 10 years. The companies offering DTH service will have to have an
Indian chief and foreign equity has been capped at 49 per cent. There is no limit on the number
of companies that can apply for the DTH license.

Which Technology are we using ?

 The DTH technology uses the Communication Satellite as a technology for
communication between the broadcasting center and the receiver’s set top box. A
communications satellite (sometimes abbreviated to COMSAT) is an artificial satellite
stationed in space for the purpose of telecommunications. Modern communications satellites use
a variety of orbits including geostationary orbits, Molniya orbits, other elliptical orbits and low
(polar and non-polar) Earth orbits.

For fixed (point-to-point) services, communications satellites provide a microwave radio relay
technology complementary to that of submarine communication cables. They are also used for
mobile applications such as communications to ships, vehicles, planes and hand-held terminals,
and for TV and radio broadcasting, for which application of other technologies, such as cable, is
impractical or impossible.

A direct broadcast satellite is a communications satellite that transmits to small DBS

satellite dishes (usually 18 to 24 inches or 45 to 60 cm in diameter). Direct broadcast satellites
generally operate in the upper portion of the microwave Ku band. DBS technology is used for
DTH-oriented (Direct-To-Home) satellite TV services, such as DirecTV and DISH Network in
the United States, Bell TV and Shaw Direct in Canada, Freesat and Sky Digital in the UK, the
Republic of Ireland, and New Zealand.

Operating at lower frequency and lower power than DBS, FSS satellites require a much
larger dish for reception (3 to 8 feet (1 to 2.5m) in diameter for Ku band, and 12 feet (3.6m) or
larger for C band). They use linear polarization for each of the transponders' RF input and output
(as opposed to circular polarization used by DBS satellites), but this is a minor technical
difference that users do not notice. FSS satellite technology was also originally used for DTH
satellite TV from the late 1970s to the early 1990s in the United States in the form of TVRO
(TeleVision Receive Only) receivers and dishes. It was also used in its Ku band form for the
now-defunct Primestar satellite TV service.Satellites for communication have now been launched
that have transponders in the Ka band, such as DirecTV's SPACEWAY-1 satellite, and Anik F2.
NASA as well has launched experimental satellites using the Ka band recently.
What Database are we using in DTH ?
All the leading providers of DTH service today uses the ORACLE DATABASE often
referred to as ORDMS which is a object-relational database management system produced and
marketed by ORACLE CORPORATION.

Oracle is a powerful, tunable, scalable and reliable industrial RDBMS. It provides

some functionalities which are absent in simple freeware RDBMS like MySQL and PostgreSQL,
such as: transactions support, concurrency and consistency, data integrity, partitioning,
replication, cost-based and rule-based optimizers, parallel execution, redo logs, RAW devices
and many other features.

Although Oracle is a very functional database, the additional qualities like reliability
impose some overhead. In fact, providing many advantages Oracle has some disadvantages.

Oracle Database XE is easy to install and easy to manage. With Oracle Database
XE, you use the Database Home Page, an intuitive browser-based interface, to administer the
database; create tables, views, and other schema objects; import, export, and view table data; run
queries and SQL scripts; and generate reports.

Oracle Database XE includes Oracle HTML DB 2.1, a declarative, graphical

development environment for creating database-centric Web applications. In addition to HTML
DB 2.1, you can use popular Oracle and third-party languages and tools to develop your Oracle
Database XE applications
.NET

 he Microsoft .NET platform's reliance on XML for data exchange—an open

T
Standard managed by the World Wide Web Consortium (W3C)—and modular XML Web
services removes barriers to data sharing and software integration.

The .NET platform, through the .NET Framework's common language runtime,
enables XML Web services to interoperate whatever their source language.

Developers can build reusable XML Web services instead of monolithic applications.

By making it easy to offer your XML Web services to others.

The ability to easily find available XML Web services means you can buy pieces of
your applications rather than build everything from scratch, focusing your time and money where
it makes the most sense.

Easier to build sophisticated development tools – debuggers and profilers can target

the Common Language Runtime, and thus become accessible to all .NET-enabled

languages.

Potentially better performance in system level code for memory management,

garbage collection, and the like have yielded an architecture that should meet or

exceed performance of typical COM-based applications today.

Fewer bugs, as whole classes of bugs should be unknown in .NET. With the CLR

handling memory management, garbage collection.

Faster development using development tool like visual studio.net