Seminar Topics & Project Ideas On Computer Science Electronics Electrical Mechanical Engineering Civil MBA Medicine Nursing Science Physics Mathematics Chemistry ppt pdf doc presentation downloads and Abstract

Full Version: Automated exam cell application software
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
[attachment=74089]



INTRODUCTION
1.1 PROBLEM DEFINITION
This paper gives the information about the automated exam cell application software. The
problem is to design a new application system for the Examination Cell of our college which has
working requirements of recording their Seating plans, students’ records etc. The need of the
organization is to get a system which is automated and easy to use and efficient in recording
seating plan for students. The Exam cell application contains various featured menus such as,
Input Screen, Schedule, Seating arrangements, Student registration, Hall ticket, Import & Export,
Proforma, and Logout. Some of the extra ordinary features of this application are 100%
accuracy, less paper work, less man power. Thus on a whole it serves as a complete automated
software which handles the every tiresome and complex process handled by the exam cell of our
college during the examination times.
1.2 EXISTING SYSTEM
The system that is being followed by the Exam Cell is a labor-intensive procedure which can
be broadly divided into two tasks. One is the students’ role which is then followed by the
administrator’s role. The main tasks that are carried out by the Exam Cell are:
• Release a notification and distribute challans to students.
• Students should manually fill the form and pay money in the bank.
• Fill an application form and submit the same in the Exam Cell.
Once all the applications are collected, the administrator performs the following jobs:
• Sort the applications with respect to the departments and semesters.
• Validate all the details.
When a timetable is disclosed, the administrator performs the following:
• Create hall tickets to all the registered students.
• Organize students with a particular seating arrangement plan.
• After the completion of the exam, a D-Form has to be generated.
2
A D-Form gives the information about the number of students who had registered for the subject
and gives the information about the appeared and absent students.
All the above tasks have to be done manually and this results in many drawbacks. All these
drawbacks are explained in the following section.
1.2.1 DRAWBACKS
The existing system has the following drawbacks:
• Cumbersome task-Sorting all the applications and then verifying them and manual
seating plan arrangement for large number of students clearly is a tough task.
• Time taking.
• Labor-intensive.
• Manual results may not always be perfect and precise.
1.3 PROPOSED SYSTEM
We are now going to present our automated systems which smoothens the process of the
students and the administrator. We are going to develop a robust system which automates all the
tasks that are carried out by the administrator. We provide an e-form which receives all the
required details from the student and automatically a challan and an application form are
generated. After successful generation, the data are stored in the database. Students make the
payments and submit the same in the Exam Cell where they are validated. Once the validations
are completed, the administrator can carry out the following operations:
• Retrieve desired student’s details.
• View data with respect to the department or subject or date.
• Automatic generation of hall tickets.
• Automatic seating plan and D-Form generation.
3
1.3.1 PREREQUISITES
• The administrator is required to save the details of all the subjects along with their codes
in the data base.
• Provide the carcass of the classroom (total number of students, departments to be seated).
• List of the absentees.
Once the inputs are taken, the system processes the data and generates the necessary output in a
print-friendly page. This system will overcome many drawbacks of the existing system and also
has many advantages.
1.3.2 ADVANTAGES
The proposed system results in the following advantages:
• Simplifies manual work.
• Accurate and Effective.
• Efficient.
1.4 REQUIREMENTS
The software and hardware requirements of our proposed system are as follows:
1.4.1 SOFTWARE REQUIREMENTS
The system can be divided into 2 modules.
• Web portal
Operating System : Windows XP/7/8
Client Side : HTML, JavaScript
Server Side Scripting : JSP
Database Query Language : MySQL
Web server : Apache2
4
• Standalone application
Operating System : Windows XP/7/8
Front End : Swings, AWT
Database Query Language : MySQL
1.4.2 HARDWARE REQUIREMENTS
• Server Side
Processor : Quad 2GHz+ CPU
RAM : 8GB
Hard disk space : 80 GB for system drive
• Client Side
Processor : Intel Pentium Core2Duo
RAM : 256MB
Hard disk space : 40 GB
1.5 SYSTEM REQUIREMENT SPECIFICATION
1.5.1 MODULES
1. Registration.
2. Data retrieval.
3. Automatic Hall Ticket Generation.
4. Automatic Seating Plan Generation.
5. Proforma Generation.
5
1.5.2 MODULES DESCRIPTION
1.5.2.1 Registration: The student registers into the portal by giving his/her details(name, regd
no, semester, subject etc.) and the database stores these details. The student can download
the same and can take the print of that copy.
1.5.2.2 Data Retrieval: After all the students have registered and the admin has the timetables of
all departments, then data retrieval operations like, retrieving data with respect to date,
subject, name etc can be performed.
1.5.2.3 Automatic hall ticket generation: The admin can login to the system and can generate
the hall ticket for each department and semester. The system automatically generates and
displays the same to the admin. The admin can take a printed copy of the same.
1.5.2.4 Automatic seating plan generation: When the admin gives the required inputs, the
system generates the complete seating plan for all the rooms based on the capacity and
displays the same.
1.5.2.5 Proforma Generation: Once an examination is completed, the admin can generate the
proformas. One of the proforma is, the D-Form which gives the list of absent students
and number of registered students.
1.6 FUNCTIONAL AND NON FUNCTIONAL REQUIREMENTS
1.6.1 SYSTEM REQUIREMENT SPECIFICATION
A System Requirements Specification (SRS) - a requirements specification for a
software system - is a complete description of the behavior of a system to be developed. It
includes a set of use cases that describe all the interactions the users will have with the software.
Use cases are also known as functional requirements. In addition to use cases, the SRS also
contains non-functional (or supplementary) requirements. Non-functional requirements are
requirements which impose constraints on the design or implementation (such as performance
engineering requirements, quality standards, or design constraints).
6
1.6.1.1 FUNCTIONAL REQUIREMENTS
In software engineering, a functional requirement defines a function of a software
system or its component. A function is described as a set of inputs, the behavior, and outputs (see
also software). Functional requirements may be calculations, technical details, data manipulation
and processing and other specific functionality that define what a system is supposed to
accomplish. Behavioral requirements describing all the cases where the system uses the
functional requirements are captured in use cases. Generally, functional requirements are
expressed in the form “system shall do <requirement>”. The plan for implementing functional
requirements is detailed in the system design. In requirements engineering, functional
requirements specify particular results of a system. Functional requirements drive the application
architecture of a system. A requirements analyst generates use cases after gathering and
validating a set of functional requirements. The hierarchy of functional requirements is:
user/stakeholder request -> feature -> use case -> business rule.
Functional requirements drive the application architecture of a system. A requirements
analyst generates use cases after gathering and validating a set of functional requirements.
Functional requirements may be technical details, data manipulation and other specific
functionality of the project is to provide the information to the user. The following are the
Functional requirements of our system:
1. The system shall perform all the operations efficiently and can efficiently access data.
2. The search of query is based on major intention of user.
3. The system can store students’ data efficiently optimized queries can be written.
1.6.1.2 NON FUNCTIONAL REQUIREMENTS
In systems engineering and requirements engineering, a non-functional requirement
is a requirement that specifies criteria that can be used to judge the operation of a system, rather
than specific behaviors. This should be contrasted with functional requirements that define
specific behavior or functions. The plan for implementing non-functional requirements is
detailed in the system architecture.
7
The non-functional requirements are "system shall be <requirement>". Non-functional
requirements are often called qualities of a system.The following are the Non functional
requirements for our system:
Availability: A system’s “availability” or “uptime” is the amount of time that is operational
and available for use. It’s related to is the server providing the service to the users in displaying
images. As our system will be used by thousands of users at any time our system must be
available always. If there are any cases of updations they must be performed in a short interval of
time without interrupting the normal services made available to the users.
Efficency: Specifies how well the software utilizes scarce resources: CPU cycles, disk space,
memory, bandwidth etc. All of the above mentioned resources can be effectively used by
performing most of the validations at client side and reducing the workload on server by using
JSP instead of CGI which is being implemented now.
Flexibility : If the organization intends to increase or extend the functionality of the software
after it is deployed, that should be planned from the beginning; it influences choices made during
the design, development, testing and deployment of the system. New modules can be easily
integrated to our system without disturbing the existing modules or modifying the logical
database schema of the existing applications.
Portability: Portability specifies the ease with which the software can be installed on all
necessary platforms, and the platforms on which it is expected to run. By using appropriate
server versions released for different platforms our project can be easily operated on any
operating system, hence can be said highly portable.
Scalability : Software that is scalable has the ability to handle a wide variety of system
configuration sizes. The nonfunctional requirements should specify the ways in which the system
may be expected to scale up (by increasing hardware capacity, adding machines etc.). Our
system can be easily expandable. Any additional requirements such as hardware or software
which increase the performance of the system can be easily added. An additional server would be
useful to speed up the application.
8
Integrity : Integrity requirements define the security attributes of the system, restricting access
to features or data to certain users and protecting the privacy of data entered into the software.
Certain features access must be disabled to normal users such as adding the details of files,
searching etc which is the sole responsibility of the server. Access can be disabled by providing
appropriate logins to the users for only access.
Usability: Ease-of-use requirements address the factors that constitute the capacity of the
software to be understood, learned, and used by its intended users. Hyper links will be provided
for each and every service the system provides through which navigation will be easier. A
system that has high usability coefficient makes the work of the user easier.
Performance : The performance constraints specify the timing characteristics of the software.
Making the application form filling process through online and providing the invigilation list
information and examination hall list is given high priority compared to other services and can
be identified as the critical aspect of the system.
1. In our system introduced user specific search performance.
2. The query related search is effective it provide within short period results, so the speed of
system is very high.
3. The ranking optimization scheme available for personalized image search system.
9
CHAPTER 2
SYSTEM ANALYSIS
2.1 SCENARIO BASED MODELLING
Use-oriented techniques are widely used in software requirement analysis and design.
Use cases and usage scenarios facilitate system understanding and provide a common language
for communication. This paper presents a scenario-based modeling technique and discusses its
applications. In this model, scenarios are organized hierarchically and they capture the system
functionality at various abstraction levels including scenario groups, scenarios, and subscenarios.
Combining scenarios or sub-scenarios can form complex scenarios. Data are also
separately identified, organized, and attached to scenarios. This scenario model can be used to
cross check with the UML model. It can also direct systematic scenario-based testing including
test case generation, test coverage analysis with respect to requirements, and functional
regression testing.
UML DIAGRAM
The unified modeling language allows the software engineer to express an analysis model
using the modeling notation that is governed by a set of syntactic semantic and pragmatic rules.
A UML system is represented using five different views that describe the system from
distinctly different perspective. Each view is defined by a set of diagram, which is as follows.
User Model View
1. This view represents the system from the users perspective.
2. The analysis representation describes a usage scenario from the end-users perspective.
Structural model view
1. In this model the data and functionality are arrived from inside the system.
2. This model view models the static structures.
10
Behavioral Model View
1. It represents the dynamic of behavioral as parts of the system, depicting the interactions
of collection between various structural elements described in the user model and
structural model view.
Implementation Model View
1. In this the structural and behavioral as parts of the system are represented as they are to
be built.
Environmental Model View
In this the structural and behavioral aspects of the environment in which the system is to be
implemented are represented.
UML is specifically constructed through two different domains they are
• UML Analysis modeling, which focuses on the user model and structural model views of
the system?
• UML design modeling, which focuses on the behavioral modeling, implementation
modeling and environmental model views.
Use case Diagrams represent the functionality of the system from a user’s point of view. Use
cases are used during requirements elicitation and analysis to represent the functionality of the
system. Use cases focus on the behavior of the system from external point of view.
Actors are external entities that interact with the system. Examples of actors include users like
administrator, bank customer …etc., or another system like central database.
Class diagram: A class diagram show’s set of classes interfaces collaboration’s and their
relationships. Class diagram address the static design view of a system.
Use case diagram: It shows set of use cases and actors and their relationships. Use case
diagram address the static design view of a system.
Sequence diagram: It is an interaction diagram that emphasizes the tine ordering messages.
11
Collaboration diagram: It emphasizes the structural organization of objects that sender receive
message.
Activity diagram: It is a special kind of State chart diagram that shows the flow from activityactivity
within a system. It addresses the dynamic view of system.
2.1.1 IDENTIFYING USECASES
An use case diagram in the Unified Modeling Language (UML) is a type of behavioral
diagram defined by and created from a Use-case analysis. Its purpose is to present a graphical
overview of the functionality provided by a system in terms of actors, their goals (represented as
use cases), and any dependencies between those use cases.
The main purpose of a use case diagram is to show what system functions are performed for
which actor. Roles of the actors in the system can be depicted.
Interaction among actors is not shown on the use case diagram. If this interaction is
essential to a coherent description of the desired behavior, perhaps the system or use case
boundaries should be re-examined. Alternatively, interaction among actors can be part of the
assumptions used in the use case.The different elements present in a use case diagram are as
follows:
Use cases: A use case describes a sequence of actions that provide something of measurable
value to an actor and is drawn as a horizontal ellipse.
Actors: An actor is a person, organization, or external system that plays a role in one or more
interactions with the system.
System boundary boxes (optional): A rectangle is drawn around the use cases, called the
system boundary box, to indicate the scope of system. Anything within the box represents
functionality that is in scope and anything outside the box is not.
Four relationships among use cases are used often in practice.
12
Include
In one form of interaction, a given use case may include another. "Include is a Directed
Relationship between two use cases, implying that the behavior of the included use case is
inserted into the behavior of the including use case.
The first use case often depends on the outcome of the included use case. This is useful
for extracting truly common behaviors from multiple use cases into a single description. The
notation is a dashed arrow from the including to the included use case, with the label
"«include»".There are no parameters or return values. To specify the location in a flow of events
in which the base use case includes the behavior of another, you simply write include followed
by the name of use case you want to include, as in the following flow for track order.
Extend
In another form of interaction, a given use case (the extension) may extend another. This
relationship indicates that the behavior of the extension use case may be inserted in the extended
use case under some conditions. The notation is a dashed arrow from the extension to the
extended use case, with the label "«extend»". Modelers use the «extend» relationship to indicate
use cases that are "optional" to the base use case.
Generalization
In the third form of relationship among use cases, a generalization/specialization
relationship exists. A given use case may have common behaviors, requirements, constraints, and
assumptions with a more general use case. In this case, describe them once, and deal with it in
the same way, describing any differences in the specialized cases. The notation is a solid line
ending in a hollow triangle drawn from the specialized to the more general use case (following
the standard generalization notation).
Associations
Associations between actors and use cases are indicated in use case diagrams by solid
lines. An association exists whenever an actor is involved with an interaction described by a use
13
case. Associations are modeled as lines connecting use cases and actors to one another, with an
optional arrowhead on one end of the line. The arrowhead is often used to indicating the
direction of the initial invocation of the relationship or to indicate the primary actor within the
use case.
14
2.1.2 USE CASE DIAGRAM
Fig 2.1 : Use case diagram for the whole system
15
2.1.2 ACTIVITY DIAGRAM:
Activity diagrams are graphical representations of workflows of stepwise activities
and actions with support for choice, iteration and concurrency. In the Unified Modeling
Language, activity diagrams can be used to describe the business and operational step-by-step
workflows of components in a system. An activity diagram shows the overall flow of control.
Activity diagrams are constructed from a limited repertoire of shapes, connected with arrows.
The most important shape types:
• rounded rectangles represent activities;
• diamonds represent decisions;
• bars represent the start (split) or end (join) of concurrent activities;
• a black circle represents the start (initial state) of the workflow;
• an encircled black circle represents the end (final state).
Arrows run from the start towards the end and represent the order in which activities happen.
However, the join and split symbols in activity diagrams only resolve this for simple cases; the
meaning of the model is not clear when they are arbitrarily combined with decisions.
16
Fig 2.2: Activity diagram for Student Registration
17
Fig 2.3: Activity diagram to save details
18
Fig 2.4: Activity diagram to store time table
19
Fig 2.5: Activity diagram to retrieve data
20
Fig 2.6: Activity diagram to generate hall ticket
21
Fig 2.7: Activity diagram for seating plan generation
22
Fig 2.8: Activity diagram for D-Form Generation
23
2.2 BEAVIOURAL MODELLING:
2.2.1 STATE CHART DIAGRAM:
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 State chart 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.
Purpose:
State chart 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. State chart 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 State chart diagram is to model life time of an object from
creation to termination. State chart diagrams are also used for forward and reverse engineering of
a system. But the main purpose is to model reactive system.
24
Fig 2.9: State chart diagram for registration
25
Fig 2.10: State chart diagram storing details
26
Fig 2.11: State chart diagram for data retrieval
27
Fig 2.12: State chart diagram for hall ticket generation
28
Fig 2.13: State chart diagram for seating plan
29
2.2.2 SEQUENCE DIAGRAM:
A sequence diagram in Unified Modeling Language (UML) is a kind of interaction
diagram that shows how processes operate with one another and in what order. It is a construct of
a Message Sequence Chart.
Sequence diagrams are sometimes called event diagrams, event scenarios, and timing
diagrams. A sequence diagram shows, as parallel vertical lines (lifelines), different processes or
objects that live simultaneously, and, as horizontal arrows, the messages exchanged between
them, in the order in which they occur. This allows the specification of simple runtime scenarios
in a graphical manner.
If the lifeline is that of an object, it demonstrates a role. In order to display interaction,
messages are used. These are horizontal arrows with the message name written above them.
Solid arrows with full heads are synchronous calls, solid arrows with stick heads are
asynchronous calls and dashed arrows with stick heads are return messages.
Activation boxes, or method-call boxes, are opaque rectangles drawn on top of lifelines
to represent that processes are being performed in response to the message (Execution
Specifications in UML).
Objects calling methods on themselves use messages and add new activation boxes on
top of any others to indicate a further level of processing. When an object is destroyed (removed
from memory), an X is drawn on top of the lifeline, and the dashed line ceases to be drawn
below it (this is not the case in the first example though). It should be the result of a message,
either from the object itself, or another.
A message sent from outside the diagram can be represented by a message originating
from a filled-in circle (found message in UML) or from a border of sequence diagram (gate in
UML).
30
Fig 2.14: Sequence diagram for Student Registration
31
Fig 2.15: Sequence diagram to save details
32
Fig 2.16: Sequence diagram to store time table
33
Fig 2.17: Sequence diagram to retrieve data
34
Fig 2.18: Sequence diagram to generate hall tickets
35
Fig 2.19: Sequence diagram to generate D-Form
36
2.3 CLASS BASED MODELLING:
Class-based Modeling, or more commonly class-orientation, refers to the style of objectoriented
programming in which inheritance is achieved by defining classes of objects; as
opposed to the objects themselves (compare Prototype-based programming).
The most popular and developed model of OOP is a class-based model, as opposed to an
object-based model. In this model, objects are entities that combine state (i.e., data), behavior
(i.e., procedures, or methods) and identity (unique existence among all other objects). The
structure and behavior of an object are defined by a class, which is a definition, or blueprint, of
all objects of a specific type. An object must be explicitly created based on a class and an object
thus created is considered to be an instance of that class. An object is similar to a structure, with
the addition of method pointers, member access control, and an implicit data member which
locates instances of the class (i.e. actual objects of that class) in the class hierarchy (essential for
runtime inheritance features).
2.3.1 CLASSES IDENTIFIED:
Class Name : Student
Attribute : Name, Regd_no, Department
Operations : Register(),printPage(),retrieveForm()
Class Name : Adminstrator
Attribute : Username,Password
Operations : validateStudentDetails(regNo), saveDetails(),storeTimetable(deptId,
regulation,semester),retrieveData(choice), allTicketGeneration(deptId,
regulation,semester),seatingPlanGeneration(roomno,
DeptId[]),d_FormGeneration(deptId, Semester, Regulation)
37
Fig 2.20: Class Diagram for Exam Cell Automation System
38
2.3.2 COLLABORATION DIAGRAMS
A Sequence diagram is dynamic, and, more importantly, is time ordered. A Collaboration
diagram is very similar to a Sequence diagram in the purpose it achieves; in other words, it
shows the dynamic interaction of the objects in a system. A distinguishing feature of a
Collaboration diagram is that it shows the objects and their association with other objects in the
system apart from how they interact with each other. The association between objects is not
represented in a Sequence diagram.
A Collaboration diagram is easily represented by modeling objects in a system and
representing the associations between the objects as links. The interaction between the objects is
denoted by arrows. To identify the sequence of invocation of these objects, a number is placed
next to each of these arrows.
A sophisticated modeling tool can easily convert a collaboration diagram into a sequence
diagram and the vice versa. Hence, the elements of a Collaboration diagram are essentially the
same as that of a Sequence diagram.
39


3.1 COMPONENT LEVEL CLASS DESIGN:
This chapter discusses the portion of the software development process where the design
is elaborated and the individual data elements and operations are designed in detail. First,
different views of a “component” are introduced. Guidelines for the design of object-oriented
and traditional (conventional) program components are presented.
3.1.1 What is a Component?
This section defines the term component and discusses the differences between object
oriented, traditional, and process related views of component level design.
Object Management Group OMG UML defines a component as “… a modular,
deployable, and replaceable part of a system that encapsulates implementation and exposes a set
of interfaces.”
3.1.2 An Object Oriented View
A component contains a set of collaborating classes. Each class within a component has
been fully elaborated to include all attributes and operations that are relevant to its
implementation. As part of the design elaboration, all interfaces (messages) that enable the
classes to communicate and collaborate with other design classes must also be defined. To
accomplish this, the designer begins with the analysis model and elaborates analysis classes (for
components that relate to the problem domain) and infrastructure classes (or
components that provide support services for the problem domain).
3.2 ARCHITECTURAL DESIGN
3.2.1 Procedural Steps for Design:
• The systematic analysis principles applied to function and behavior should also be
applied to data.
• All data structures and the operations to be performed on each should be identified.
44
• A data dictionary should be established and used to define both data and program
design.
• Low level data design decisions should be deferred until late in the design process.
• The representation of data structure should be known only to those modules that must
make direct use of the data contained within the structure.
• A library of useful data structures and the operations that may be applied to them should
be developed.
3.2.2 ARCHITECTURAL DESIGN DIAGRAM
Fig: 3.1 Context Level Architecture
45
CHAPTER 4
SYSTEM IMPLEMENTATION
4.1 INTRODUCTION TO JSP
JavaServer Pages (JSP) is a technology for developing web pages that support dynamic content
which helps developers insert java code in HTML pages by making use of special JSP tags, most
of which start with <% and end with %>.
A JavaServer Pages component is a type of Java servlet that is designed to fulfill the role of a
user interface for a Java web application. Web developers write JSPs as text files that combine
HTML or XHTML code, XML elements, and embedded JSP actions and commands.
Using JSP, you can collect input from users through web page forms, present records from a
database or another source, and create web pages dynamically.
JSP tags can be used for a variety of purposes, such as retrieving information from a database or
registering user preferences, accessing JavaBeans components, passing control between pages
and sharing information between requests, pages etc.
4.1.1 WHY USE JSP?
JavaServer Pages often serve the same purpose as programs implemented using the Common
Gateway Interface (CGI). But JSP offer several advantages in comparison with the CGI.
Performance is significantly better because JSP allows embedding Dynamic Elements in HTML
Pages itself instead of having a separate CGI files.
JSP are always compiled before it's processed by the server unlike CGI/Perl which requires the
server to load an interpreter and the target script each time the page is requested.
JavaServer Pages are built on top of the Java Servlets API, so like Servlets, JSP also has access
to all the powerful Enterprise Java APIs, including JDBC, JNDI, EJB, JAXP etc.
JSP pages can be used in combination with servlets that handle the business logic, the model
supported by Java servlet template engines.
46
Finally, JSP is an integral part of Java EE, a complete platform for enterprise class applications.
This means that JSP can play a part in the simplest applications to the most complex and
demanding.
4.1.2 ADVANTAGES OF JSP:
Following is the list of other advantages of using JSP over other technologies:
vs. Active Server Pages (ASP): The advantages of JSP are twofold. First, the dynamic part is
written in Java, not Visual Basic or other MS specific language, so it is more powerful and easier
to use. Second, it is portable to other operating systems and non-Microsoft Web servers.
vs. Pure Servlets: It is more convenient to write (and to modify!) regular HTML than to have
plenty of println statements that generate the HTML.
vs. Server-Side Includes (SSI): SSI is really only intended for simple inclusions, not for "real"
programs that use form data, make database connections, and the like.
vs. JavaScript: JavaScript can generate HTML dynamically on the client but can hardly interact
with the web server to perform complex tasks like database access and image processing etc.
vs. Static HTML: Regular HTML, of course, cannot contain dynamic information.
4.2 CASCADING STYLE SHEETS:
Cascading style sheets (CSS) is a style language used to describe the presentation
semantics (the look and formatting) of a document written in a markup language. It’s most
common application is to style web pages written in HTML and XHTML. CSS is a designed
primarily to enable the separation of document content (written in HTML or a similar markup
language) from document presentation, including elements such as the layout, colors, and fonts.
This separation can improve content accessibility, provide more pages to share formatting, and
reduce complexity and repetition in the structural content (such as by allowing for table less web
design). CSS can also allow the same markup page to be presented in different styles for
different rendering methods, such as on-screen in print by voice. A style sheet consists of a list of
rules. Each rule-set consists of one or more selectors and a declaration block. A declaration –
block consists of a list of declarations in braces. Each declaration itself consists of a property, a
47
colon (Smile, a value. If there are multiple declarations in a block, a semi colon (Wink must be inserted
to separate each declaration. In CSS, selectors are used to declare which of the markup elements
a style applies to, a kind of match expression. Selectors may apply to all elements of a specific
type, or only those elements that match a certain attribute; elements may be matched depending
on how they are placed relative to each other in the markup code, or on how they are nested
within the Document Object Model.
4.2.1 CSS SOURCES:
CSS information can be provided by various sources. CSS style information can be either
attached as a separate document or embedded in the HTML document. Multiple style sheets can
be imported. Different style can be applied depending on the output device being used; for
example, the screen version can be quite different from the printed version, so that authors can
tailor the presentation appropriately for each medium.
Priority scheme for CSS sources (from highest to lowest priority):
Author styles (provided by the web pages author), in the form of:
Inline styles, inside the HTML document, style information on a single element, specified
using the “style” attribute.
Embedded style, blocks of CSS information inside the HTML itself.
External style sheets, i.e., a separate CSS file referenced from the document.
4.2.2 ADVANTAGES
• CSS is used to separate the document presentation from document content written in
markup languages.
• Style sheet writers can think about the visual presentation of the document without
bothering about the document content.
• CSS reduces development time.
• The size of a document using external style sheet is comparatively smaller and hence,
downloaded time is also smaller
48
• CSS speeds up overall response time.
• CSS provides many more style attributes for defining the look and feel of web pages,
than plain HTML.
4.3 INTRODUCTION TO MYSQL:
MySQL is a fast, easy-to-use RDBMS used for databases on many web sites. Speed was
the developer’s main focus from the beginning. In the interest of speed, they made the decision
to offer fewer features than their major competitors (for instance, Oracle and Sybase). However,
even though MySQL is less full featured than its commercial competitors, it has all the features
needed by the large majority of database developers. It’s easier to install and use than its
commercial competitors.
MySQL is developed, marketed, and supported by MySQL AB, which is a Swedish company.
The company licenses it in two ways:
Open source software: MySQL is available via the GNU GPL (General Public License) for no
charge. Anyone who can meet the requirements of the GPL can use the software for free.
Commercial license: MySQL is available with a commercial license for those who prefer it to
the GPL. If a developer wants to use MySQL as part of a new software product and wants to sell
the new product, rather than release it under the GPL, the developer needs to purchase a
commercial license.
4.3.1 ADVANTAGES OF MYSQL:
MySQL is a popular database with Web developers. Its speed and small size make it ideal for a
Web site. It is open source, which means free, and we have the foundation of its popularity.
It’s fast. The main goal of the folks who developed MySQL was speed. Consequently, the
software was designed from the beginning with speed in mind.
It’s inexpensive. MySQL is free under the open source GPL license, and the fee for a
commercial license is very reasonable.
49
It’s easy to use. We can build and interact with a MySQL database by using a few simple
statements in the SQL language, which is the standard language for communicating with
RDBMSs.
It can run on many operating systems. MySQL runs on a wide variety of operating systems —
Windows, Linux, Mac OS, most varieties of UNIX (including Solaris, AIX, and DEC UNIX),
FreeBSD, OS/2, Irix, and others.
Technical support is widely available. A large base of users provides free support via mailing
lists. The MySQL developers also participate in the e-mail lists. We can also purchase technical
support from MySQL AB for a very small fee.
It’s secure. MySQL flexible system of authorization allows some or all database privileges (for
example, the privilege to create a database or delete data) to specific users or groups of users.
Passwords are encrypted.
4.4 INTRODUCTION TO TOMCAT WEB SERVER
Apache Tomcat (or simply Tomcat, formerly also Jakarta Tomcat) is an open source web
server and servlet container developed by the Apache Software Foundation (ASF). Tomcat
implements the Java Servlet and the JavaServer Pages (JSP) specifications from Sun
Microsystems, and provides a "pure Java" HTTP web server environment for Java code to run in.
Apache Tomcat includes tools for configuration and management, but can also be configured by
editing XML configuration files.
4.5. INTRODUCTION TO XAMPP
XAMPP stands for Cross-Platform (X), Apache (A), MySQL (M), PHP (P) and Perl (P). It is a
simple, lightweight Apache distribution that makes it extremely easy for developers to create a
local web server for testing purposes. Everything you need to set up a web server – server
application (Apache), database (MySQL), and scripting language (PHP) – is included in a simple
extractable file. XAMPP is also cross-platform, which means it works equally well on Linux,
Mac and Windows. Since most actual web server deployments use the same components as
XAMPP, it makes transitioning from a local test server to a live server is extremely easy as well.
50
4.5.1 WHAT’S INCLUDED IN XAMPP?
XAMPP has four primary components. These are:
1. Apache: Apache is the actual web server application that processes and delivers web content
to a computer. Apache is the most popular web server online, powering nearly 54% of all
websites.
2. MySQL: Every web application, howsoever simple or complicated, requires a database for
storing collected data. MySQL, which is open source, is the world’s most popular database
management system. It powers everything from hobbyist websites to professional platforms like
WordPress.
3. PHP: PHP stands for Hypertext Preprocessor. It is a server-side scripting language that
powers some of the most popular websites in the world, including WordPress and Facebook. It is
open source, relatively easy to learn, and works perfectly with MySQL, making it a popular
choice for web developers.
4. Perl: Perl is a high-level, dynamic programming language used extensively in network
programming, system admin, etc. Although less popular for web development purposes, Perl has
a lot of niche applications.
Different versions of XAMPP may have additional components such as phpMyAdmin,

Raymondnof

Hello I have a deal for you.
There are luxury towers in Bat Yam right on the sea and the price is going to rise a lot this year looking to make a very big profit or bring in customers and take a percentage.

You Interested in hearing details?