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.

Prakasam Engineering College

Page 2

2. System Specifications

2.1 Software requirements: * Operating System

Win-98, win-xp, linux or any other Higher version ms access Java

* Back end * Front end

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.

Prakasam Engineering College

Page 3

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 objectoriented structure. But what does it mean?
Prakasam Engineering College Page 4

The object-oriented paradigm is a different way of viewing applications. With the objectoriented 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 1980s 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 mid1990s new iteration of methods began to appear these methods to incorporate each others 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 builders focus on delivering more useful features. Third, they expected that their collaboration would yield improvements in all

Prakasam Engineering College

Page 5

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.

Prakasam Engineering College

Page 6

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 users 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 actors 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 banks 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 actors 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.

Prakasam Engineering College

Page 7

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. 2. 3. 4. 5. Browse catalog and select items. Call sales representative. Supply shipping information. Supply payment information. Receive conformation number from salesperson.

These steps would generate this simple use case diagram:

browse catalog and select item s

call sales person

customer

give shipping info

give payment info

get confirm ation#

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
Prakasam Engineering College Page 8

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 well discuss in chapter5. Joes account, for egg, is an object. An account is a blueprint for the Joes 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 systems 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

Prakasam Engineering College

Page 9

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.

Prakasam Engineering College

Page 10

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.

Prakasam Engineering College

Page 11

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.

Prakasam Engineering College

Page 12

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

Prakasam Engineering College

Page 13

Sequence Diagram2
Object : Class1 Object : Class2 Object : Class3

Message1()

Message2() Return()

Return

Sequence Diagram3
an Order Entry Window: prepare() an Order:
a Delivery Item:

[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.

Prakasam Engineering College

Page 14

Sequence Diagram4
an Order Entry Window: prepare() an Order:
a Delivery Item:

[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, 3format can be used ,as the example below shows, or for more detailed and complex diagrams a 1,1.1,1.2,1.2.1scheme 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.

Prakasam Engineering College

Page 15

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
Prakasam Engineering College Page 16

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.

Prakasam Engineering College

Page 17

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
Prakasam Engineering College Page 18

activity2 there is a branch. The branch describes what activities will take place based on a set of 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.

Prakasam Engineering College

Page 19

Prakasam Engineering College

Page 20

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
Prakasam Engineering College Page 21

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.

Prakasam Engineering College

Page 22

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.

Prakasam Engineering College

Page 23

3.1.1 Economics Feasibility: In present system customer need to go billers 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.

Prakasam Engineering College

Page 24

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 administrators 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 hes 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.

Prakasam Engineering College

Page 25

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 administrators 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.
Prakasam Engineering College Page 26

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
Prakasam Engineering College Page 27

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.
Prakasam Engineering College Page 28

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.

Prakasam Engineering College

Page 29

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.

Prakasam Engineering College

Page 30

USECASE DIAGRAM FOR ENROLLING OF COPMPANIES:

Registration

Login

EventsGathering Corporate

Jobs and recruitment

RequiredInfo

Prakasam Engineering College

Page 31

USECASE DIAGRAM FOR REGISTRATION:

Name

Established date

Emailid
Corporate

Registration successful Database

Password

Alternating mailid

Security question

Prakasam Engineering College

Page 32

USECASE DIAGRAM FOR LOGIN:

Username

Registration successful

Corporate

Password

Database

Login failure

Submit

Forget password

Prakasam Engineering College

Page 33

USECASE DIAGRAM FOR EVENTS GATHERING:

revenue

Category

Corporate no of employees

Database

basic salary

Location

Prakasam Engineering College

Page 34

USECASE DIAGRAM FOR PROVIDING ALERTS:

Prakasam Engineering College

Page 35

CLASS DIAGRAMS
CLASS DIAGRAM FOR REGISTRATION:

Prakasam Engineering College

Page 36

CLASS DIAGRAM FOR LOGIN:

Prakasam Engineering College

Page 37

CLASS DIAGRAM FOR EVENT GATHERING:

Prakasam Engineering College

Page 38

CLASS DIAGRAM FOR PROVIDING ALERTS:

Prakasam Engineering College

Page 39

SEQUENCE DIAGRAMS:
SEQUENCE DIAGRAM FOR REGISTRATION:

:Browser

:webserver

:Database

: Corporate

Browse to Home page Req for Home Page

Resp for home page Select reg form

req reg page Get Registration

Return Registration Return

Response(reg)

Prakasam Engineering College

Page 40

SEQUENCE DIAGRAM FOR LOGIN:

:Browser

:DataBase

: Corporate

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

Prakasam Engineering College

Page 41

SEQUENCE DIAGRAM FOR EVENTS GATHERING:

:Webportal

:Database

:User

: Corporate

post the event

get information

return information

notify to user

apply for event forword application ack to webportal ack to user

Prakasam Engineering College

Page 42

SEQUENCE DIAGRAM FOR PROVIDING ALERTS:

:Webportal

:Database

:User

: Corporate

post the event

get information

return information

Alert to user

Prakasam Engineering College

Page 43

COLLABORATION DIAGRAM FOR REGISTERATION:

1: Browse to Home page 4: Select reg form :Browser : Corporate 9: Response(reg)

3: Resp for home page 8: Return

2: Req for Home Page 5: req reg page

6: Get Registration :webserv er 7: Return Registration :Databas e

Prakasam Engineering College

Page 44

COLLABORATION DIAGRAM FOR LOGIN:

1: user login account 3: Enter user id and password

:Browser
: Corporate 2: prompt for userid & password 6: go to home page on success 7: if failure error page

5: Return status

4: Verify

:DataBase

Prakasam Engineering College

Page 45

COLLABORATION DIAGRAM FOR EVENTS GATHERING:

4: notify to user 8: ack to user

:Webportal
5: apply for event

:User

2: get information

1: post the event 7: ack to webportal

6: forword application

3: return information

:Database

: Corporate

Prakasam Engineering College

Page 46

COLLABORATION DIAGRAM FOR PROVIDING ALERTS:

:User

: Corporate

1: post the event 4: Alert to user

3: return information

:Database
2: get information

:Webportal

Prakasam Engineering College

Page 47

ER-DIAGRAM:
Account details

User id

Username

Password

Account id

Respons e

Corporate

Local server

Get details Mobile no Location

First name Password

Last name

Address DB admin

User name

Date of birth

Match

Events gathering

Eid Ename Prakasam Engineering College

Action Page 48

DATABASE CREATION: LOGIN TABLE:

SNO 1. 2.

Fieldname Login Password

Datatype Varchar Varchar

Size 40 20

Constraint Primarykey

REGISTRATION TABLE:
SNO 1. 2. 3. 4. 5. 6. 7. 8. 9. Fieldname Firstname Lastname Mailid Password Confirmedpassword Date of birth Qualification Experience Salary Expectation Datatype Varchar Varchar Varchar Varchar Varchar Varchar Varchar Integer Integer Size 20 20 40 20 20 20 10 5 10 Constraint Primarykey

Primarykey

EVENTS GATHERING:
SNO 1. 2. 3. Fieldname Eid Ename Action Datatype Varchar Varchar Varchar Size 5 20 40 Constraint Primarykey

TABLE FOR JOB AND RECRUITMENT:

SNO 1. 2. Fieldname Jname Recure process Datatype Varchar Varchar Size 10 40 Constraint Primarykey

Gather required information:

Prakasam Engineering College Page 49

Sno 1. 2.

Fieldname Info name Discription

Datatype Varchar Varchar

Size 10 50

Constraint Primarkey

ALERTS TO STUDENTS:
Sno 1. 2. 3. Fieldname Alert name Handle type Discription Datatype Varchar Varchar Varchar Size 20 10 50 Constraint Primatkey

Prakasam Engineering College

Page 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.

Prakasam Engineering College

Page 51

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

Prakasam Engineering College

Page 52

Prakasam Engineering College

Page 53

Prakasam Engineering College

Page 54