Enrolling of Companies Into Web Portal

Introduction

Aim and Motivation:

The main motto of our project is to provide services to the corporate who has registered into our website. The corporate should be registered into the website by providing their details. After registration the website database maintains all the relevant company information and will generate a unique id and a password for authentication purpose. These details will be used for further reference of company with our web portal.

The students who have registered in the website can view the profile of company. Every registered corporate has the facility to update various events in the website and also get notified by mobile alerts to students who had registered in the website.

This events and coding related programs will be updated by various registered companies into our web site and our site gathers all that info in to our database and based on the schedule our administrator will provide alerts to all students through mobile or email.

The following functionalities are used in our project

• Corporate registration

• Corporate events gathering

• Corporate Jobs and recruitment process

• Gathering all required info

• Providing some alerts to students

Prakasam Engineering College Page 1

Existing System:

The traditional way of knowing about various companies and about their information is very disadvantageous. To know about any company we need to go through that website and also all the details will not be published in website for knowing completely about company and also difficult to various people to apply for jobs because lack of information about interview process and no of vacant positions etc.

Proposed System:-

Our proposed system alleviates all the drawbacks in existing system by introducing a common interface for both students and companies to mutually communicate each other allow user to apply for jobs directly based on the requirement criteria. This way of maintaining corporate information in a centralized manner allows various people to know about different company details in a common place.


2. System Specifications

2.1 Software requirements:

* Operating System Win-98, win-xp, linux or any other

* Back end Higher version ms access

* Front end Java

2.2 Hardware requirements:

The configuration for Pentium111 processor is

Net speed with 3.1mb Memory space 250GB Ram 2GB

2.3 About Software:

Overview of uml:

The Power of the unified modeling language is not limited to object oriented software

development.

More and more, the uml is being applied to other areas of software development, such as

data modeling , enhancing practitoners’ ability to communicate their needs and assessments to

the rest of the team. Data analysis primarily gathers data out of documented business

requirements.

The database itself traditionallyhas been described by notation called entity relationship diagram,

using graphic representation that is similar but not identical to that of the UML.The uml can be

used to describe the complete development of relational and object relational database from

business requirements through the physical data model .However modeling of the physical data

must express a detailed description of the database. This is done using Rational Rose software.


Data Modeling Profile for the uml

What is uml?

The unified Modeling Language (UML) is standard language for specifying visualizing, constructing and documenting the artifacts of software system, as well as for business modeling and other non software systems .he uml helps project teams communicate, explore potential designs, and validate the architectural design of the software.

Goals of UML

The primary goals in the design of the UML were:

1. Provide users with a ready-to-use, expressive visual modeling language so they can develop and exchange meaningful models.

2. Provide extensibility and specialization mechanism to extends the core concepts.

3. Be independent of particular programming language and developing process.

4. Provide a formal basis for understanding the modeling language.

5. Encourage the growth of the OO tools market.

6. Support higher level development concepts such as collaboration frame works, patterns and components.

7. Integrate best practices.

Introduction to the Object- Oriented Paradigm

Structured Programming was the mainstream in the earlier days of software engineering. Programmers begin developing standards blocks of code to perform operation like printing, and then copied and pasted that code into every application they wrote. While this reduced the development time for new application, it was difficult if a chain was needed in that block of code, because the developer had to make the change everywhere that code had been copied. Structured programming some challenges for which object-oriented programming was designed to solve. With object oriented programming, developers create blocks of code, called objects. These objects are then used by the various applications. Should one of the objects required modification; a developer needs to make the change only once. Companies are rushing out to adopt this technology and integrate it into their existing application. In fact of , most applications being developed today are object-oriented. Some languages, such as Java, require an object-oriented structure. But what does it mean?


The object-oriented paradigm is a different way of viewing applications. With the object-oriented approach, you divide an application into many small chunks, or objects, that are fairly independent of one another. We can then build the application by piecing all of these objects together, the different types of blocks. Once you have these building blocks, you can put them together to make your castel, once you build or buy some basics objects in the computer world, you can simply put them together to create new applications.

Why we use UML:

As the strategic value of software increases for many companies, the industry looks for techniques to automate the production of software and improve quality and reduce cost and time to market. This technique includes component technology, visual programming, patterns and frame works. Businesses also seek to manage the complexity of system as they increase in scope and scale. In particular, they recognized the need to solve recurring architectural problems, such as physical distribution, concurrency, replication, security, load balanced and fault tolerance. Additionally, the development for the world wide-web, while making some things similar, as exacerbated these architecture problems. The Unified Modeling Language (UML) was designed to respond to these needs.

History of UML

Identifiable Object-Oriented modeling languages began to appear between mid 1970 and the late 1980’s as various methodologists experimented with different approaches to object-oriented analysis and design. The number of indentified modeling languages increased from less than 10 to more than 50 during the period between 1989 to 1994. Many users of OO methods had trouble finding complete satisfaction one modeling language, fueling the “method wars”. By the mid-1990’s new iteration of methods began to appear these methods to incorporate each other’s techniques, and a few clearly prominent methods emerged.

The development of UML began in late 1994 when Grady Booch and Jim Rumbaugh of Rational Software Corporation began their work on unifying the Booch and OMT methods. In the fall of 1995, Ivar Jacobson and his Objectory Company joined Rational and this unification effort, merging in the OOSE (Object-Oriented Software Engineering) methods.

As the primary authors of the Booch, OMT, and OOSE methods, Grady Booch, Jim Rumbaugh, and Ivar Jacobson were motivated to create a unified modeling language for three reasons. First, these methods were already evolving toward each other independently. If made sense to continue that evaluation together rather than apart, eliminating the potential for any unnecessary and gratuitous differences that would further confuse users. Second, by unifying semantics and notation, they could bring some stability to the object-oriented marketplace, allowing projects to settle on one mature modeling language and letting tool builder’s focus on delivering more useful features. Third, they expected that their collaboration would yield improvements in all


three earlier methods, helping them to capture lessons learned and to address problems that none of their methods previously handled well.

Types of UML Diagrams:

Each UML diagram is designed to let developers and customers view a software system from a different perspective and in varying degrees of abstraction. Uml diagrams commonly created in visual modeling tools include:

Use Case Diagram displays the relationship among actors and use cases.

Class Diagram models class structure and contents using design elements such as classes, packages and objects. It also displays relationships such as containment, inheritance, associations and others.

Interaction Diagrams

Sequence Diagram displays the time sequence of the objects participating in the interaction. This consists of the vertical dimension (time) and horizontal dimension (different objects).

Collaboration Diagram displays an interaction organized around the objects and their links to one another. Numbers are used to show the sequence of messages.

State Diagram displays the sequence of states that an object of an interaction goes through during its life in response to received stimuli, together with its response and actions.

Activity Diagram displays a special state diagram where most of the state of the sates is action states and most of the truncations are trigged by completion of the actions in the source states. This diagram focuses on flows driven internal processing.

Physical Diagrams:

*Component Diagram displays the high level packaged structure of the code itself. Dependencies among components are shown, including source code components, binary code components, and executable components. Some components exeunt at compile time, at link time, at run time well as at more than one time.

*Deployment Diagram displays the configuration of run-time processing elements and the software components, process, and objects that live on them. Software component instances represent run-time manifestations of code units.


Use Case Diagram:

Use Case diagrams show the interactions between use case and actors. Use case represents system functionality, the requirements of the system from the user’s perspective. Actors represent the people or system that provide or receive information from the system; they are among the stakeholders of a system. Use Case diagrams, therefore, show which actors initiate use cases; they also illustrate that an actor’s receives information from a use case. In essence, a Use Case diagram can illustrate the requirements of the system. While Business Use Case diagrams are not concerned with what is automated, Use Case diagrams focus on just the automated processes. There is not a non-to-one relationship between business use cases and use cases. A single business use case may require 30 use cases, for example, to implement the process.

EX: Use Case diagram for an Automated Teller Machine (ATM) system.

This Use Case diagram shows the interaction between the use cases and actors of an ATM system. In this example, the bank’s customer initiates a number of use cases: Withdraw Money, Deposit Funds, Make Payment, View Balance, and Change PIN. A few of the relationships are worthy of further mention. The bank officer can also initiate the Change PIN use case. The Make Payment use case shows an arrow going to the credit system. External system may be actors and, in this case, the credit system is shown as an actor’s because it is external to the ATM system. The arrow going from a use case to actors illustrates that the use case, the Make Payment use case provides credit card payment information to the credit system. Much information can be gleaned from viewing Use Case diagrams. This one diagram shows the overall functionality of the system. Users, project managers, analysts, developers, quality assurance engineers, and anyone else interested in the system as a whole can view the system as a whole can view these diagrams and understand what the system is supposed to accomplish.

When to Use: Use Case Diagrams

Use case is used in almost every project. They are helpful in exposing requirements and planning the project. During the initial stage of a project most use cases should be defined, but as the project continues more might become visible.

How to Draw: Use Case Diagrams:

Use Cases are a relatively easy UML diagram to draw, but this is a very simplified example. This example Is only meant as an introduction to the UML and use cases. If you would like to learn more see the resource page for more detailed resources on UML.


Start by listing a sequence of step a user might take in order to complete an action. For example a user placing an order with a scale company might follow the steps.

1. Browse catalog and select items.2. Call sales representative.3. Supply shipping information.4. Supply payment information.5. Receive conformation number from salesperson.

These steps would generate this simple use case diagram:

browse catalog and select items

call sales person

give shipping info

give payment info

customer

get confirmation#

This example shows the customer as a actor because the customer is using the

odering system. The diagram takes the simple steps listed above and shows them as actions the

customer might perform. The salesperson could also be included in this use case diagram

because the salesperson is also interacting with the ordering system.

From this simple diagram the requirements of the ordering system can easily be delivered. The

system will need to be able to perform actions for all of the use cases listed. As the project


progresses other use cases might appear. The customer might have a need to add an item to an

order that has already been placed.

This diagram can easily be expanded until a complete description of the ordering system is

derived capturing all of the requirements that the system will need to perform.

Class diagrams:

Class diagrams show the interactions between classes can be seen the blueprint

for objects, as we’ll discuss in chapter5. Joe’s account, for egg, is an object. An account is a

blueprint for the Joe’s checking account; an account is a class. Classes contain the information

and behavior to check the PIN. A class diagram is created for each type of object in a sequence

or collaboration diagrams. The class diagram for the systems with draw money use case is

illustrated in. Introduction to UML Class diagram for the ATM system’s withdraw money use

case the class diagram above shows the relationships between the classes that implemented the

withdraw money use case. This is done with four classes: card Reader, Account, ATM screens,

and cash Dispenser.

Each class on a class diagram is represented by a rectangle divided into three

sections. The first section shows the class name. The second section shows the attributes the

class contains. An attribute a piece of information that is associated with the class. For example,

the account class contains three attributes: Account Number, PIN, and balance. The last section

the operations of the class contain four operations: Open, withdraw Funds, Deduct Funds, verify

Funds. The lines connecting cases show the communication relationship between the classes. For

instance, the Account class is connected with the ATM Scrrens because class because the two

directly communicate with each other. The Card Reader is not connecting to the cash Dispenser

because the two do not communicate. Another Point of interest is that some attributes and

operations have small padlocks to the left of them. The Account Number, PIN, and the balance

are all private attributes of the Account class.

Developer use case diagrams to actually develop the classes. Tools such as

Rose generate skeletal code for classes. Analyst use class diagrams to show the details of the

system. Architecture also looks at class diagrams to see the design of the system. If one class


contains too much functionality, an architect can see this in the class diagram and split out the

functionality into multiple classes. Should no relationship exit between classes?

Communicate with each other, an arc hitch or developer can see this too. Class diagrams should be

created to show the classes that work together in each use case, and comprehensive diagrams containing

whole system or subsystem can be created as well

When to Use: Class Diagrams

Class diagram are used in nearly all Object Oriented software designs. Use them to describe the

Classes of the system and their relationships to each other.

How to Draw: Class Diagrams

Class diagrams are some of the most difficult UML diagrams to draw. To draw detailed and

useful diagrams a person would have to study UML and Object Oriented principles for a long

time.Therefore, this page will give a very high level overview of the process. To find list of

where to find more information see the Resources page.

Before drawing a class diagram consider the three different perspectives of the system the

diagram will present; conceptual, specification, and implementation. Try not to focus on one

perspective and try see how they all work together.

When designing classes consider what attributes and operations it will have. Then try to

determine how instance of the classes will interact with each other. These are the very first steps

of many in developing a class diagram.However,using just these basic techniques one can

develop a complete view of the software system.


Corprate Customer

contactName : StringcreditRating : StringcreditLimit : Double

remind()billormonth()

Personal Customer

creditCard# : Long Integer

Order

data Received : DateisPrepaid : Booleannumber : Stringprice : Money

dispatch()close()

Customer

name : Stringaddress : String

creditRating()1** 1

This example is only meant as an introduction to the UML and use cases. If you would like to learn more

see the Resource page for more detailed resource on UML.

Interaction Diagrams:

Interaction diagrams model the behavior of use cases by describing the way groups of objects

interact to complete the task. The two kinds of interaction diagrams are sequence and

collaboration diagrams. This example is only meant as an introduction to the UML and

interaction diagrams. If you would like to learn more see the Resources page for a list of more

detailed resources on UML.


When to Use: Interaction Diagrams


Doing for several use cases use a state diagram To see a particular behavior over many use cases or threads use an activity diagram

How to draw: Interaction Diagram Sequence diagrams, collaboration diagrams can be used to demonstrate the interaction of objects in a use case. Sequence diagrams generally show the sequence of events that occur. Collaboration diagrams demonstrate how objects are statically connected. Both diagrams are relatively simple to draw and contain similar elements.

Sequence diagrams: Sequence diagrams demonstrate the behavior of objects in a use case by describing the objects the objects and the messages they pass. The diagrams read left to right and descending. the example below shows an object of class 1 start the behavior by sending a message to an object of class 2. Messages pass between the different objects until the objects of class 1 received the final message. Below is a slightly more complex example. The light blue vertical rectangle the objects activation while the green vertical dashed lines represent the life of the object. The green vertical rectangles represent when a particular object has control. The represent when the object is destroyed. This diagram also shows condition for messages to be sent to other object. The condition is listed between brackets next to the message. For example a has to be met before the object of class 2 can send a message() to the object of class 3.

Interaction diagrams are used when you want to model the behavior of several object in a use

case. They demonstrate how the objects collaborate for the behavior. Interaction diagrams do not

give a in depth representation of the behavior. If you want to see what a specific object is

Sequence diagram1

Object : Class1 Object : Class2 Object : Class3

The next diagram shows the beginning of a sequence diagram for placing an order. The object an order entry window is created and sends a message to an Order object to prepare the order.Notice the names of the objects are followed by colon. The Names of the classes the objects belong to do not have to be listed. However the colon is required to denote that it is the name of an object following the object Name: class Name naming system.

Next the Order object checks to see if the item is in stock and if the [In Stock] condition is met it sends a message to create a new Delivery Item object


Sequence Diagram2

Object : Class1 Object : Class2 Object : Class3

Message1()Message2()

Return()

Return

Sequence Diagram3

an Order Entry Window:

an Order: a Delivery Item:

prepare()[InStock] new()

The next diagrams add another conditional message to the order object. If the item is [OutOfStock]it sends a message back to the Order Entry Window object stating that the abject is out of stack.

This simple diagram shows the sequence that messages are passed between objects to complete a use case for ordering an item.


Sequence Diagram4

an Order Entry Window:

an Order: a Delivery Item:

prepare()[InStock] new()

[OutOfStock] Out of Stock Message()

Collaboration diagrams:

Collaboration diagrams are also relatively easy to draw .They show the relationship between objects and the order of messages passed between them. The objects are listed as icons and arrows indicate the messages being passed between them .The numbers next to the messages are called sequence numbers. As the name suggests, they show the sequence of the messages are they are passed between the objects. There are many acceptable sequence numbering schemes in UML. A simple 1, 2, 3…format can be used ,as the example below shows, or for more detailed and complex diagrams a 1,1.1,1.2,1.2.1…scheme can be used.

STATE DIAGRAMS:

State Diagrams are used to describe the behavior of a system. State diagrams describe all of the possible states of an object as event occurs. Each diagram usually represents objects of a single class and track the different states of its objects through the system.

When to use: State Diagrams

We use state diagrams to demonstrate the behavior of an object through many use cases of the system. Only the state diagrams for classes where it is necessary to understand the behavior of the object through the entire system. Not all classes will require a state diagram and state diagrams are useful for describing the collaboration ova all objects in a use case.


How to Draw: State Diagrams

State diagrams have very few elements. The basic elements are rounded boxes representing the

state of the object and arrows indicting the transition to the next state. The activity section of the

state symbol depicts what activities the object will be doing while it is in that state.

All state diagrams being with an initial state of the object. This is the state of the object when it

is created. After the initial state the object begins changing states. Conditions based on the

activities can determine what the next state the object transitions to.

Below is an example of a state diagram might look like for an Order object. When the object

enters the Checking state it performs the activity "check items." After the activity is completed

the object transitions to the next state based on the conditions [all items available] or [an item is

not available]. If an item is not available the order is canceled. If all items are available then the

order is dispatched. When the object transitions to the Dispatching state the activity "initiate


delivery" is performed. After this activity is complete the object transitions again to the

Delivered state.

State diagrams can also show a super-state for the object. A super-state is used when many

transitions lead to the a certain state. Instead of showing all of the transitions from each state to

the redundant state a super-state can be used to show that all of the states inside of the super-state

can transition to the redundant state. This helps make the state diagram easier to read.

The diagram below shows a super-state. Both the Checking and Dispatching states can transition

into the Canceled state, so a transition is shown from a super-state named Active to the state

Cancel. By contrast, the state Dispatching can only transition to the Delivered state, so we show

an arrow only from the Dispatching state to the Delivered state.


Activity Diagrams

When to Use: Activity Diagrams

Activity diagrams should be used in conjunction with other modeling techniques such as

interaction diagrams and state diagrams. The main reason to use activity diagrams is to model

the workflow behind the system being designed. Activity Diagrams are also useful for:

analyzing a use case by describing what actions need to take place and when they should

occur; describing a complicated sequential algorithm; and modeling applications with parallel

processes. 1

However, activity diagrams should not take the place of interaction diagrams and state diagrams.

Activity diagrams do not give detail about how objects behave or how objects collaborate. 1

How to Draw: Activity Diagrams

Activity diagrams show the flow of activities through the system. Diagrams are read from top to

bottom and have branches and forks to describe conditions and parallel activities. A fork is used

when multiple activities are occurring at the same time. The diagram below shows a fork after

activity1. This indicates that both activity2 and activity3 are occurring at the same time. After

activity2 there is a branch. The branch describes what activities will take place based on a set of


http://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/activity.htm#1

http://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/activity.htm#1

conditions. All branches at some point are followed by a merge to indicate the end of the

conditional behavior started by that branch. After the merge all of the parallel activities must be

combined by a join before transitioning into the final activity state.

Below is a possible activity diagram for processing an order. The diagram shows the flow of

actions in the system's workflow. Once the order is received the activities split into two parallel

sets of activities. One side fills and sends the order while the other handles the billing. On the

Fill Order side, the method of delivery is decided conditionally. Depending on the condition

either the Overnight Delivery activity or the Regular Delivery activity is performed. Finally the

parallel activities combine to close the order.



Physical Diagrams:

When to Use: Physical Diagrams

Physical diagrams are used when development of the system is complete. Physical diagrams are used to give descriptions of the physical information about a system.

How to Draw: Physical Diagrams

Many times the deployment and component diagrams are combined into one physical diagram. A combined deployment and component diagram combines the features of both diagrams into one diagram.

The deployment diagram contains nodes and connections. A node usually represents a piece of hardware in the system. A connection depicts the communication path used by the hardware to communicate and usually indicates a method such as TCP/IP.

The component diagram contains components and dependencies. Components represent the physical packaging of a module of code. The dependencies between the components show how changes made to one component may affect the other components in the system. Dependencies in a component diagram are represented by a dashed line between two or more components. Component diagrams can also show the interfaces used by the components to communicate to each other. 1


http://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/physical.htm#1

The combined deployment and component diagram below gives a high level physical description of the completed system. The diagram shows two nodes which represent two machines communicating through TCP/IP. Component2 is dependent on component1, so changes to component 2 could affect component1. The diagram also depicts component3 interfacing with component1. This diagram gives the reader a quick overall view of the entire system.

Private network with the regional ATM server. The ATM server executable will run on the regional ATM server. The regional ATM server will, in turn, communicate over the local area network (LAN) with the banking data base server running Oracle.

Lastly, a printer is connected to the regional ATM server. So, this one diagram shows us the physical set up for the system. Our ATM system will be following three-tier architecture with one tier each for the data base, regional server, and client. The Development diagram is used by the project manager, users, architect, and deployment staff to understand the physical layout of the system and where the various subsystems will resides.


DEPLOYMENT DIAGRAMS:

Deployment Diagrams are the last type of diagram we will discuss. The Deployment diagram shows the physical layout of the network and where the various components will reside. In our ATM example, the ATM system comprises many subsystems running on separate physical devices or nodes. The Deployment diagram illustrated in this tells us much about the layout of the system. The ATM client executable will run on multiple ATMs located at different sites.The ATM client will communicate over a private network with the regional ATM server.The ATM Server executable will run on the regional ATM server. The regional ATM server executable will run on the regional ATM server.The regional ATM server will in turn communicate over the local area networkwith the banking database server running Oracle.

Lastly a printer is connected to the regional ATM server.So,this one diagram shows us the physical setup for the system.Our ATM system will be following a three-tier architecture with one tier each for the database,regional server and client.The deployment diagram is used by the project manager,users,architectand deployment staff to understand the physical layout of the system and where the various subsystems will reside.This diagram helps the project manager communicate what the system will be like to the users. It also helps the staff responsible for deployment efforts.All of these diagrams together describe the system from several different perspectives.In we will discuss each of these diagrams more closely and show how they are generated in Rational Rose.You will also be given the details of rose,another aspect of softawre development projects deserves some attention-the process.

3. System Analysis & Design

3.1 Feasibility Study

All projects are feasible- given unlimited resources and infinite time! Unfortunately, the

development of computer-based system or product is more likely plagued by a security of

resources and difficult delivery dates. It is both necessary and prudent to evaluate the feasibility

of a project at the earliest possible time. Months or years of effort, thousands or millions of

dollars, and untold professional embarrassment can be averted if an ill-conceived system is

recognized early in the definition phase.

Feasibility and risk analysis are related in many ways. If project risk is great the

feasibility of producing quality software is reduced. During product engineering, however, we

concentrate our attention on four primary areas of interest.


3.1.1 Economics Feasibility:

In present system customer need to go biller’s place to pay the bill. So he/she needs to

spend some time to complete this protocol. It is time consuming process sometimes customer not

able to spend that much of time. In such a case needs to pay some additional payment to biller

for late payment.

If it is developed in electronic payment system, He can pay the bill from anywhere in the world. No need to travel to pay the bills. For doing this process electronically have to spend some time.

3.1.2 OPERATIONAL FEASIBILITY

In our application front end is developed using GUI. So it is very easy to the customer to enter the necessary information. But customer has some knowledge on using web applications before going to use our application

3.1.3 Technical Feasibility:

This application in going to be used in an Internet environment called www (World

Wide Web). So, it is necessary to use a technology that is capable of providing the networking

facility to the application. This application as also able to work on distributed environment.

Application on developed with J2EE (Java 2 Enterprise Edition Platform) Technology. One

major advantage in application is platform neutral. We can deploy and it in any operating

system.

GUI is developed using HTML to capture the information from the customer. HTML is used to

display the content language. It is very easy to develop a page/document using HTML some

RAD (Rapid Application Development) tools are provided to quickly design/develop our

application. So many objects such as button, text fields, and text area etc are providing to capture

the information from the customer.

We can this application in any OS. They can have their own security and transactional

advantages. But are the responsible for selecting suitable and secured OS, which is suitable to

our application.


3.2 ANALYSIS

3.2.1 Module Analysis:

The following are the modules in the system

1. Login

2. Test

3. Review

4. Report

1. Login:

This module provides a quality login window which is more secure than other login forms as

in a normal login window there are multiple logins available so that more than one person can

access to test with their individual login. But in this project there is only one login id i.e.

administrator id and password by which a person enter the site. Hence it is more secure and

reliable than previously used on-line test simulators.

Once the user enters to login he is asked for his basic details which are stored in the

administrator’s database. After the user gets registered with the site he is allowed to perform

access to all the features and modules of the site. The registered user then becomes the

authorized examinee for the site.

The User can view his previous test details and he can attend the exams on his interested

subjects/technology. He/She is also allowed to get his feedback from the examiner and the

administrator.

Pre conditions: The user is asked for his basic details in order to Login to the site if he’s

unregistered else the user can login with his Id and Password.

Post conditions: The user once logged in is allowed to have an access to all the details

of the exams to be conducted and he can also have a review of his previous results.


2. Test:

Test page is the most creative and important page in this project. It consists of 2 modules.

Subject selection: From the given choices the candidate can select his field (like C, C++ and

JAVA etc) for taking on with the test.

Utilities: It includes skipping and coming back to the question afterwards if needed. Giving the

list of attempted and un attempted questions and can go to any question directly and can either

attempt or change the answer of the already attempted question.

In this Test module the examinee can chose the subject of his choice and once opts for starting

the test the examiner activates the exam and the examinee is allowed to answer the test.The

moment he submits the examiner starts the evaluation and he updates the result to the

administrator’s database. The administrator then sends the result report to the examinee.

Pre condition: The Examinee has to select the subject of his/her choice (like C, C++ and JAVA

etc) for taking the test.

Post condition: After submitting the test, the examiner evaluates the paper and updates to the

administrator and then the Examinee can view the report of his result.

3. Review:

This module enables the user to have a detailed review and analysis of the tests he has taken previously.He also can get to know about the mistakes he has previously commited in the tests he has taken already.

Pre conditions: The user has to know about his performance.

Post conditions: The user is provided with analysis of his tests and he is aware of his capabilities in the respective technologies/subjects.

4. Report:

The users have the facility to review his/her performance sheets, the rating awarded for him and he is provided with to give and take the feedback to and from the administrator.

Pre conditions: The user just sends a request to the administrator for review.


Post conditions: The user is the displayed with the reports listing out his previous results ,the rating based on his performance and also he is supplied with his feedback.

3.2.2 Data Analysis

1) USE CASE DIAGRAMS:-

A 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 over view 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.

Use case diagrams are formally included in two modeling languages defined by the

OMG.

The Unified Modeling Language (UML) and the system modeling language (SysML) .

2) CLASS DIAGRAMS:-

The class diagram is the main building block in object oriented modeling. it is

used both for general conceptual modeling of the systematic of the application , and for detailed

modeling translating the models into programming code. The classes in a class diagram represent

the both the main objects and or interactions in the application and the objects to be

programmed. In the class diagram these classes are represented with boxes which contain three

parts:

A class with three sections

The upper part holds the name of the class

1. The Middle part contains the attribute of the class

2. The bottom part gives the methods or operations the class can take or undertake.

In the system design of a system, a number of classes are identified and grouped together in a

class diagram which helps to determine the statically relations between those objects. With

detailed modeling, the classes of the conceptual design are often split in a number of


subclasses.In orders to further describe the behavior of systems, these class diagrams can be

complemented by state diagram or UML state machine. Also instead of class diagrams Object

role modeling can be used if you just want to model the classes and their relationships.

SEQUENCE AND COLLABRATION DIAGRAMS

A sequence diagram shows, as parallel vertical lines, different process are objects that live

simultaneously, and, as horizontal arrows, the messages exchanged b/w them, in the order in

which they occur. This allows the specification of simple run time scenarios in a graphical

manner.

For instant, the UML 1.x diagram on the right describes the sequence of messages of a

restaurant system. This diagram represents a pattern ordering food and wine, drinking wine then

eating the food, and finally paying for the food.

E-R DIAGRAMS

The relation upon the system is structure through a conceptual ER-diagram, which

not only specifies the existential entities but also the standard Relation through which

the system exists and the cardinalities that are necessary for the system state to

continue.

The entity Relationship Diagram depicts the relationship between the data objects.

The ERD is the notation that is used to conduct the data modeling activity the

attributes of each data object noted is the ERD can be described resign a data objects

descriptions.

The set of primary components that are identified by the ERD are

Data object

Relationships

Attributes

Various types of indicators.

The primary purpose of the ERD is to represent data objects and their relationships.


It is a process of converting a relation to a standard form. The process is used to handle the

problems that can arise due to data redundancy i.e. repletion of data in the data base, maintain

data integrity as well as handling problems that can arise due to insertion, pupation, deletion

anomalies.

Decomposing is the process of splitting relation into multiple relations to eliminate anomalies

and maintain anomalies and maintain data integrity. To do this we use normal forms or rules for

structuring relation.

Insertion anomaly: In ability to add to data to the data base due to absence of other data.

Deletion anomaly: Unintended loss of data due to deletion of other data.

Update anomaly: In ability to add to data to the data base due to absence of other data.

Normal Forms:

Data in consistency resulting from data redundancy and partial update.

Normal Forms: These are the rules for structuring relations that eliminate anomalies.

First Normal Form:

A relation is said to be in first normal form if the values in the relation are atomic for

every attribute in the relation. By this we mean simply that no attribute value can be a set of

values or, as it is sometimes expressed, a repeating group.

Second Normal Form:

A relation is said to be in second Normal form is it is in first normal form and it should

satisfy any one of the following rules.

1) Primary key is a not a composite primary key

2) No non key attributes are present

3) Every non key attribute is fully functionally dependent on full set of primary key.


Third Normal Form:

A relation is said to be in third normal form if their exits no transitive dependencies.

Transitive Dependency:

If two non key attributes depend on each other as well as on the primary key then they are

said to be transitively dependent. The above normalization principals were applied to decompose

the data in multiple tables there by making the data to be maintained in a consistent state.


USECASE DIAGRAM FOR ENROLLING OF COPMPANIES :

Registration

Login

EventsGathering

Jobs and recruitment

RequiredInfo

Corporate


USECASE DIAGRAM FOR REGISTRATION:

Name

Established date

Emailid

Password

Alternating mailid

Corporate DatabaseRegistration successful

Security question


USECASE DIAGRAM FOR LOGIN:

Password

Username

Submit

Corporate Database

Registration successful

Forget password

Login failure


USECASE DIAGRAM FOR EVENTS GATHERING:

revenue

Category

no of employees

basic salary

Corporate Database

Location


USECASE DIAGRAM FOR PROVIDING ALERTS:

Corporate

untitled()

Jobs

Technofares

User

Webportal

Alerts through sms


CLASS DIAGRAMS

CLASS DIAGRAM FOR REGISTRATION:

Reginfo

JobInfo : stringCorpInfo : string

Giving()Getting()Approving()

JobInfo

Jobname : stringsalary : integerJobTimings : string

FurnishingDetails()

CorpInfo

corpDetails : string

Accepting()Approving()

Select Select


CLASS DIAGRAM FOR LOGIN:

user

f_fname : stringl_name : stringemail_add : string

post_message()

login

user_name : stringpassword : string

validate()

Webmaster

name : string

delete_moderator()delete_reg_mem()

database

Number : integerName : string

Request()Response()store()

1..*

1

1..*

1

Validates

Regular_member

user_name : stringpassword : string

open()

corporate_account

User_name : stringPassword : string

Open()Close()

Connections to individuals

11

Uses

0..*

1

0..*

1Contains

11

Uses

Moderator

reg_member : string

delete_reg_member()

1..*

1

1..*

1

Uses


CLASS DIAGRAM FOR EVENT GATHERING:

GatheringallReqinfo

Reqid : stringPassword : string

Open()Approval()

JobsAndRecruitmentprocc

Jobname : stringrecure process : string

Recruite()Approval()

ProvidingSomealerts

Alert id : integerAlert type : string

Alert()Approval()

Events Gathering

Event name : stringEvent id : integer

Open()Approval()

DB opere

optype : stringopid : integer

insert()modify()delete()

DB conn

id : integerpassword : string

connect()Close()

1..*

1..*

1..*

1..* 1..*

1..*

1..*

1..*


CLASS DIAGRAM FOR PROVIDING ALERTS:

1..*

1

Gatherig requirments

EidEname

Open()Close()

Provide alerts to user

AidAname

Reject()Approval()

1

1..*


SEQUENCE DIAGRAMS :

SEQUENCE DIAGRAM FOR REGISTRATION:

: Corporate

:Browser :webserver :Database

Browse to Home pageReq for Home Page

Resp for home page

Select reg formreq reg page

Get Registration

Return Registration

Return

Response(reg)


SEQUENCE DIAGRAM FOR LOGIN:

: Corporate

:Browser :DataBase

user login account

prompt for userid & password

Enter user id and password

Verify

Return status

go to home page on success

if failure error page


SEQUENCE DIAGRAM FOR EVENTS GATHERING:

:Webportal :User:Database

: Corporatepost the event

get information

return information

notify to user

apply for event

forword application

ack to webportal

ack to user


SEQUENCE DIAGRAM FOR PROVIDING ALERTS:

:Webportal :User:Database

: Corporatepost the event

get information

return information

Alert to user


COLLABORATION DIAGRAM FOR REGISTERATION:

: Corporate

:Browser

:webserver

:Database

1: Browse to Home page4: Select reg form

9: Response(reg)

2: Req for Home Page5: req reg page

3: Resp for home page8: Return

6: Get Registration

7: Return Registration


COLLABORATION DIAGRAM FOR LOGIN:

: Corporate

:Browser

:DataBase

1: user login account3: Enter user id and password

2: prompt for userid & password6: go to home page on success

7: if failure error page

4: Verify5: Return status


COLLABORATION DIAGRAM FOR EVENTS GATHERING:

:Webportal :User

: Corporate

:Database

2: get information

3: return information

4: notify to user8: ack to user

5: apply for event

1: post the event7: ack to webportal

6: forword application


COLLABORATION DIAGRAM FOR PROVIDING ALERTS:

:Webportal

:User

:Database

: Corporate

2: get information

3: return information

4: Alert to user

1: post the event


ER-DIAGRAM:

DATABASE CREATION:


Account detailsResponseAccount idPasswordUsernameUser id

Local server Corporate

Mobile no

Match

Date of birth

Last nameFirst name

Password

User name

Address

DB admin

Location

Get details

Events gathering

Action

Ename

Eid

LOGIN TABLE:

SNO Fieldname Datatype Size Constraint1. Login Varchar 40 Primarykey2. Password Varchar 20

REGISTRATION TABLE:

SNO Fieldname Datatype Size Constraint1. Firstname Varchar 20 Primarykey2. Lastname Varchar 203. Mailid Varchar 404. Password Varchar 205. Confirmedpasswor

dVarchar 20

6. Date of birth Varchar 207. Qualification Varchar 10 Primarykey8. Experience Integer 59. Salary Expectation Integer 10

EVENTS GATHERING:

SNO Fieldname Datatype Size Constraint1. Eid Varchar 5 Primarykey2. Ename Varchar 203. Action Varchar 40

TABLE FOR JOB AND RECRUITMENT:

SNO Fieldname Datatype Size Constraint1. Jname Varchar 10 Primarykey2. Recure process Varchar 40

Gather required information:

Sno Fieldname Datatype Size Constraint


1. Info name Varchar 10 Primarkey2. Discription Varchar 50

ALERTS TO STUDENTS:

Sno Fieldname Datatype Size Constraint1. Alert name Varchar 20 Primatkey2. Handle type Varchar 103. Discription Varchar 50


CONCLUSION:

It has been a great pleasure to work on this exciting project. This will provide better opportunities and guidance in future in developing projects independently. The system is operated at a high level of efficiency and all the examiners and examinees associated with the system understand its advantage.


Bibliography

References:

[1] Rational: “UML Resource Center”, www.rational.com,

[2] Smart Draw: “Draw Anything Easily”, www.smartdraw.com,

[3] Together soft: “A hands on Introduction For Developers”, www.togethersoft.com

[4].Geocities:”UML Examples”, www.geocities.com,

[5] James Rumbaugh, Michael Blaha, William Premerlani


http://www.geocities.com/

http://www.smartdraw.com/

http://www.rational.com/



Documents

Enrolling of Companies Into Web Portal