A UML PROJECT ON

“COURSE REGISTRATION SYSTEM”

Overview: This paper presents a case study highlighting the best practices for designing and building a web-based auction system using   UML (Unified   Model   Language)   and component-based programming. We use the Use Case, Class, Sequence, and Component  Diagrams  offered  by UML for designing the system. This enables new functions to be added and updated easily.]

     

                                                         

S.NO	CONTENTS:
1	ABSTRACT
2	INTRODUCTION
2.1	EXISTING SYSTEM
2.2	PROPOSED SYSTEM
3	LITERATURE SURVEY
3.1	ABOUT UML
3.2	RATIONAL ROSE
3.3	DESCRIPTION ABOUT CASE STUDY
3.3.1	MODULE SPECIFICATION
3.3.2	FUNCTIONAL DECOMPOSITION AND STRUCTURE
4	SOFTWARE REQUIREMENTS
5	UML DIAGRAMS
5.1	DATA-FLOW DIAGRAMS
5.2	E-R DIAGRAMS
6	DATA DICTIONARY
7	TEST DATA GENERATION
8	COST AND RESOURCE ESTIMATION
9	USER-MANUAL
10	CONCLUSION AND REFERENCE

                                        1. ABSTRACT

The course reservation project helps the user to know the procedures followed in universities to enroll students for a particular course.   The limitation of the existing system are :the system is not efficient to meet the needs, the system is very slow and time consuming, not more than one choice can be given by a student, the number of seats left out and the course details cannot be known.   The problems that are overcome are the existing system uses spreadsheet as backend now the proposed system uses access as backend, the basic requirement of the system has being improved, its has become user friendly.   The proposed system is very efficient. Now a student can know the number of seats that are being allotted in a day. The person can even get the course detail. The report displays the number of students per course and the number of students allotted seat on a particular day. 

The different areas where we can use this application are:

·                    Any education institute can make use of it for providing information to student and instructor about the courses and content of the courses available .

Students can registre for courses available

·                    It can be used in universities and college  and modifications can be done easily according to requirements.

                                               2. INTRODUCTION

Online course reservation system is used to choose the course through online by the students .

They are provided with a catalog they can choose the course. The catalog contains the detailed     description about each course and also the availabilty of the course which help to decide on their own.

2.1)Existing system:

The existing system is very slow and time consuming, not more than one choice can be given by a student, the number of seats left out and the course details cannot be known. The problems that are overcome are the existing system uses spreadsheet as backend

2.2)proposed system:

The proposed system is very efficient. Now a student can know the number of seats that are being allotted in a day. The person can even get the course detail. The report displays the number of students per course and the number of students allotted seat on a particular day.

                                    3.LITERATURE SURVEY     

3.1)About UML:

The Unified Modeling Language (UML) is a standard language for specifying, visualizing, The Unified Modeling Language (UML) is a standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems. The UML represents a collection of best engineering practices that have proven successful in the modeling of large and complex systems.

The UML is a very important part of developing object oriented software and the software development process. The UML uses mostly graphical notations to express the design of software projects. Using the UML helps project teams communicate, explore potential designs, and validate the architectural UML-Unified modeling language

The Unified Modeling Language (UML) is used to specify, visualize, modify, construct and document the artifacts of an object-oriented software intensive system under development. UML offers a standard way to visualize a system's architectural blueprints, including elements such as:

An Overview of the UML:

 The UML is a language for

·                    Visualizing

·                    Specifying

·                    Constructing

·                    Documenting,

3.2)Rational rose:

Rational Rose is an object-oriented Unified Modeling Language (UML) software design tool intended for visual modeling and component construction of enterprise-level software applications.

In much the same way a theatrical director blocks out a play, a software designer uses Rational Rose to visually create (model) the framework for an application by blocking out classes with actors (stick figures), use case elements (ovals), objects (rectangles) and messages/relationships (arrows) in a sequence diagram using drag-and-drop symbols.

Rational Rose documents the diagram as it is being constructed and then generates code in the designer's choice of C++, Visual Basic, Java, Oracle8, CORBA or Data Definition Language.

Two popular features of Rational Rose are its ability to provide iterative development and roundtrip engineering. Rational Rose allows designers to take advantage of iterative development (sometimes called evolutionary development) because the new application can be created in stages with the output of one iteration becoming the input to the next. (This is in contrast to waterfall development where the whole project is completed from start to finish before a user gets to try it out.)

Then, as the developer begins to understand how the components interact and makes modifications in the design, Rational Rose can perform what is called "round-trip engineering" by going back and updating the rest of the model to ensure the code remains consistent.

Rational Rose is extensible, with downloadable add-ins and third-party partner applications. It supports COM/DCOM (ActiveX), JavaBeans, and Corba component standards.

3.3)Introduction of case study:

3.3.1) Module specification:

User Interface:-

The external users are students and instructors. The student logs in his account to choose courses and subsequently database gets updated.

Hardware Interface:-

The hardware interface used for handling the software will be computer and wireless MAN as the internet connection.

Software Interface:-

The Operating Systems can be any version of Windows which supports TCP/IP protocols and software for dynamic database.

Performance Requirements:-

The PCs used must be at least Pentium 4 machines so that they can give optimum performance of the product.

Software System Attributes:-

Reliability-The software should be highly reliable because any error could lead to loss of life and property.

Security- The software should be secured from unauthorized authentication.

Maintenance and Performance- The software needs regular maintanence as new features will get added based on improvement in technology.

Performance is always important in a software which has to be  operating 24*7 so there has to be a backup or alternate for the software.

Requirement Analysis:-

        Textual analysis: This covers the requirements and diagrams of the project. The complete process of online course registration system.

3.3.2) Functional decomposition and structure:

A hierarchy diagram shows the relationships between the modules of a computer program.

The vertical lines connecting the modules indicate the calling structure from the high-level modules to the lower- level modules. The little arrows next to the lines show the data that is passed between modules and contain the program logic to actually perform the functions.

Functionalities a student can perform in the system:

- Can edit his profile data i.e. address/homepage/email id information and update.

- Register a course

      - Constraints checked here include 

 MAX courses registered this semester, in our system its 3, 

 Course previously not registered, 

 Seats lefts in the course, 

 Prerequisite course registered and 

 Conflicts in timing with other currently registered courses.

- View his schedule

    - Drop course option is provided on this page

   - Can view textbook information of the courses department wise.

- Can view courses with prerequisite information

- Can view the list of courses using the day and period parameters.

- Can view courses previously taken along with grades information

Functionalities an Adminstrator  can implement in the system:

- Can view / edit information and also update.

- Can edit Course details - Details such as Seats left - to increase or decrease the capacity of the course (seats cannot be more than class capacity)

- Can add a new course to the database.

- The input parameters in the form are checked for valid input data before updating the database.

- Can view classroom availability as well as maximum capacity of classroom when course information is updated or new classroom is added

- Admin can view info of all the students registered in the courses

                              4.SOFTWARE REQUIREMENT SPECIFICATION 

Introduction:

Overview:

       Online Course Registration is a web-based program aimed to make easier and more convenient the class registration process, a hassle through whichstudents go every semester. Online Course Registration System attempts toalleviate these hassles by providing several services to students through theinternet.

Purpose:

     Online Course Registration System provides a way to search for classeswithout having to open a

course catalog, a way to “shop” around and view

various possible schedules, and finally, officially register for the chosen classes.

Overall Description:

Product Perspective:

The product should be able to provide effective and reliable access between student and the college database system. The student should get the apt and detailed information  from the website in order to make correct decisions.

Product functions:-

The product should provide a service for students to register courses with ease.

Database to update the student info and seats allotted.

General Constraints:-

Some desired features of the new system include: 

The ability to search/view course offerings on-line

 Provide transcripts on-line

 Evaluate prerequisites for courses against student records

 Inform students of registration stops and provide ability to resolve and registration conflict(s)

 Allow students to fill out applications for graduation and plans of study. 

     Server capacity is how many users can access or can be online at once. More is the number of users more will be the network traffic and hence the server comes in a down state. Personal firewall and updating is a tough task, it should be such that it should not block the network traffic, making the system slower. Firewall of the UMS should not collide with the firewall of the user system.

The various parts of the system are:

Login/Security–Login using user ID and password--will connect to server

Course Search –This will be a database system fairly similar to the current versionof Online Course Announcement  with the ability to search for courses withsearch keys: course number, professor, meeting time and department.

Course page –for each course in the database, there will be a view that will give the following information:- Course number, title- Instructor- Meeting Time- Location- Description- Number of credits- Number of students already registered

   Number of open slots- Waitlist if applicable- Exam Group

User Interface:

Login:

There will be a login screen into which the student enters a user ID and password.

Course Page:

Information displayed:- Course number, title- Instructor- Meeting Time- Location- Description- Number of credits- Number of students already registered- Number of open slots- Waitlist if applicable- Exam Group- Web site of corresponding Critical Review page

Non-Functional Requirements:

Performance–course search should be fast, despite many students accessing thedatabase at once

Testing–must test the database search

Reliability–Make sure still reliable with large number of users!

Ease of Use-make user interaction easy and obvious so that non-computer-proficient students can use the system

Outside Dependencies–connecting to server for login- accessing course information, or make dummy database

                                                                                                                                                                                                                                                                                                                                                 Student can make changes to his/her courses that are about to be taken for a semester in the future. All system (browser) interfaces are based ISO accepted industry standards for the WWW. Among others the online registration system will have the following functionalities:

 Student Profile 

- Student Address 

- Student Authentication/Change PIN 

- Email Address 

Registration 

- Registration Status  

- Course Status  

- Student’s Current Schedule 

- Register for a course

- Add or drop a course

- Course Evaluation Guide  

- Registration Schedule

Grades

- View past grades earned from each course taken up to the last completed semester.

- View grades 

- Keep a count of credits finished 

- Display a computed value of current Marks

Registration Assistance

Stop a registration request course for error conditions:

- Courses have scheduling conflict

- Course does not exist

- Course requires a prerequisite that is not met

- Course has already been registered and or completed

                                               5. DESIGNS

USE CASE DIAGRAM:

A Use Case diagram shows a set of use cases and actors and their relationship. Use Case diagram addresses the dynamic view of the system. The components of Use Case diagram are

1.     Use Cases

2.     Actors

3.     Relationships

1. Use Cases:  Use Case is a set of sequence of activities which yields an observable value and returns to an actor.

Notation:                                                             

           

                                        Use Case Name

2.  Actors: An Actor represents a human being or a machine who/which interacts with the system or initiates the activity to perform the behaviour of the system.

Notation :

3. Relationships: The Use Case diagram contains the following relationships. They are

a)     Dependency

b)    Association

c)     Generalization

a) Dependency: It is a semantic relationship; if we change the semantics of one thing (independent) may affect the changes in the other thing (dependent).

Notation:   

b) Association: It is a structural relationship which defines a set of links in between two objects.

   Notation:       Unidirectional                 

                             Bidirectional          

c) Generalization: It is a specialization/generalization relationship in which objects of the specialized relationship (child) are substitutable for the objects of generalized relationship (parent).

      Notation:

Common Modelling Technique:

1.     Identify the Actors.

2.     Identify the Use Cases.

3.     Identify the Relationships.

1.Identify the Actors: In this step the Actors involved in the system are being identified.

2.Identify the Use Cases: In this step the Use Cases or the set of activities involved in the system are being identified.

3.Identify the Relationships: In this step the relationship between the Use Cases and the Actors are being established

ACTIVITY DIAGRAM:

An activity diagram is a special kind of a statechart diagram that shows the flow from activity to activity within a system.

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

In UML an activity diagram is used to display the sequence of activities. Activity Diagrams show the workflow from a start point to the finish point detailing the many decision paths that exist in the progression of events contained in the activity.

They may be used to detail situations where parallel processing may occur in the execution of some activities. Activity Diagrams are useful for Business Modeling where they are used for detailing the processes involved in business activities.

The following sections describe the elements that constitute an Activity diagram:

-Activities: An activity is the specification of a parameterized sequence of behavior. An activity is shown as a round-cornered rectangle enclosing all the actions, control flows and other elements that make up the activity.

Notation:

-Actions: An action represents a single step within an activity. Actions are denoted by round cornered rectangles.

-Action Constraints: Constraints can be attached to an action. The following diagram shows an action with local pre- and post-conditions.

-Control Flow: A control flow shows the flow of control from one action to the next. Its notation is a line with an arrowhead.

-Initial Node: An initial or start node is depicted by a large black spot, as depicted below.

-Final Node: There are two types of final node: Activity and Flow final nodes. The activity final node is depicted as a circle with a dot inside. The flow final node is depicted as a circle with a cross inside.

-Fork and Join Nodes: Forks and joins have the same notation, either a horizontal or vertical bar

(the orientation is dependent on whether the control flow is running left to right or top to bottom).

They indicate the start and end of concurrent threads of control. The following diagram shows an example of their use.

A join is different from a merge in that the join synchronizes two inflows and produces a single outflow. The outflow from a join cannot execute until all inflows have been received. A merge passes any control flows straight through it.

Notation:             

CLASS DIAGRAM

Class:

A class diagram describes the static structure of the symbols in your new system.

It is a graphic presentation of the static view that shows a collection of declarative (static) model elements, such as classes, types, and their contents and relationships.

Classes are arranged in hierarchies sharing common structure and behaviour, and are associated with other classes.

Class diagrams are particularly useful for business modeling.

Business analysts can use class diagrams to model a business's current assets and resources, such as account ledgers, products, or geographic hierarchy.

A class diagram illustrates the graphical view of the static structure of a system. It is a collection of classes, interfaces, and their relationships.

A class diagram models the static structure of entities.

Modeling the static structure of classes, the class diagram shows each class's internal structure along with the relationship that the class has to other classes.

The UML representation of a class -- a class diagram -- is a rectangle containing three compartments stacked vertically.

Name:

Modeling the static structure of classes, the class diagram shows each class's internal structure along with the relationship that the class has to other classes. The top compartment shows the class's name.

                                              

                                 

                                                Figure: Class Name

Attributes:

The middle compartment lists the class's attributes. The attribute section of a class (the middle compartment) lists each. Class's attributes on a separate line. In business class diagrams, the attribute types usually correspond to units that make sense to likely readers of the diagram (i.e., minutes, dollars, etc.).

However, a class diagram that will be used to generate code needs classes whose attribute types are limited to the types provided by the programming language, or types included in the model that will also be implemented in the system.

    

  Figure: A generic Class diagram with Attribute List

Operations:

The class's operations are documented in the third (lowest) compartment of the class diagram's rectangle. Like attributes, the operations of a class are displayed in a list format, with each operation on its own line. Operations are documented using the following notation: name (parameter list): type of value returned.

When an operation has parameters, they are put inside the operation's parentheses; each parameter uses the format "parameter name : parameter type", which can include an optional indicator to show whether or not the parameter is input to, or output of, the operation. This optional indicator appears as an "[in]" or "[out]" .

                                                           

Figure: A generic Class diagram

Class diagrams are used in one of the following ways:

To model the vocabulary of a system and specify the abstraction and responsibilities.

To model simple collaborations to visualize and specify them and the relationships between the elements of a collaboration.

To mode the logical database schema. The class diagrams are a superset of the entity relationship diagram.

SEQUENCE DIAGRAM

A sequence diagram is an interaction diagram that emphasizes the time ordering of the messages.

A sequence diagram displays the time sequence of the objects participating in the interaction.

It consists of the vertical dimension (time) and horizontal dimension (different objects).

A sequence diagram depicts the sequence of actions that occur in a system.

It is a very useful tool to easily represent dynamic behavior of the system.

The invocation of methods in each object and thee order in which invocation occurs is sequence diagram.

Sequence diagram represents the interaction among different objects of a system.

A sequence diagram is made up of objects and messages and it is two dimensions in nature.

The vertical axis represents time during which the object exists during interaction.

This vertical line is called object lifeline.

The horizontal line represents different objects.

Elements in Sequence Diagram :

OBJECT: An object is important element in sequence diagram. It is n instance of a class. A sequence diagram shows interaction among objects over period of time.

MESSAGE: The interaction between objects in sequence diagram is represented as messages. The notation for messages varies depending on the type of message. Simple messages and special messages to create and destroy objects can be represented in a sequence diagram.

Each message is labeled with message name .The label can include arguments and some control information or a message that object send to it self-recursively. Here also the message can be of three types Simple message, Synchronous, Asynchronous.

COLLABORATION DIAGRAM

A collaboration diagram is an interaction diagram that emphasizes the structural organization of the objects that send and receive messages.

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

A collaboration diagram is an interaction diagram that shows similar information to sequence diagrams but its primary focus in on object relationships. On collaboration diagrams, objects are shown with association connectors between them. Messages are added to the associations and show as short arrows pointing in the direction of the message flow.

The sequence of messages is shown through a numbering scheme. Collaboration diagrams let you show a spatial organization of components and interactions rather than concentrating on the sequence of the interactions.

A collaboration diagram shows an interaction organized around the objects in the interaction and their links to each other. Unlike a Sequence diagram, a collaboration diagram shows the relationships among the objects.

On the other hand, a collaboration diagram does not show time as a separate dimension, so sequence numbers determine the sequence of messages and the concurrent threads. A collaboration diagram is a cross between a symbol diagram and Sequence diagram, in that it describes a specific scenario by numbered arrows that show the movement of messages during the course of a scenario.

The Collaboration diagram may be used to:

Describe a specific scenario by depicting the movement of messages between the objects Show a spatial organization of objects and their interactions, rather than the sequence of the interactions

STATE CHART DIAGRAM

State Chart:

A state chart diagram can be used to describe the behavior of an object. It is a graph of states as nodes and state transitions as directed edges. A state is displayed as rectangle, an edge as arrow. A node is labeled with the state name inside the bounds.

It may also be divided in two areas where the first contains the name and the other an activity in process while in this state, the start state, is a little empty circle. An end state is a double bordered circle.

State diagrams can be nested hierarchically, indicating sub state machines. Entering a sub state machine begins at starting state of the sub machine. Reaching an end state means leaving a sub state.

Initial state:

A condition at the beginning of the life of an object or an interaction during which it satisfies some condition, performs some action, or waits for some event.

                                                 
                                                               

                                            Figure: Initial state

Final state:

A condition at the end of the life of an object or an interaction during which it satisfies some condition, performs some action, or waits for some event.

                                                               

                                                    Figure: Final state

State:

A condition during the life of an object or an interaction during which it satisfies some condition, performs some action, or waits for some event.

                                                    

                                           Figure: State Chart Diagram

States:

States represent situations during the life of an object. You can easily illustrate a state in Smart Draw by using a rectangle with rounded corners.

                                                      

                                                                    Figure: States

History Indicator:

When a transition to a super state occurs, a History Indicator shows control resumes at the state within the super state that was current when the super state was interrupted.

                                                                           

                                                            Figure: History indicator

Transition:

A relationship between two states, indicates that an object in the first state will enter the second state and perform certain specified actions when a specified event occurs, if specified conditions are satisfied.

                                                                     event / action

                                                                 Figure: Transition

COMPONENT DIAGRAM

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 exist at compile time, at link time, at run times well as at more than one time.

Component diagram is a diagram that shows the organizations and dependencies among components types or a component diagram shows a set of components and their relationship.

A component diagram shows the dependencies amongst the software components, which includes source code components; binary code components are executable components.

A component diagram only has a description form and not an instance form. It basically contains components, interfaces and their relationships (dependency generalization, association and realization), apart from notes and constants. They may also contain packages or subsystems.

We use a component diagram to visualize the static aspects of the physical components and their relationship and to specify their details for construction.

Basic Component Diagram Symbols and Notations

Component:

A component is a physical building block of the system. It is represented as a rectangle with tabs.

                                                   

                                                            Figure: Component

Interface:

An interface describes a group of operations used or created by components.

 

         

                                                             Figure: Interface

Dependencies:

           Draw dependencies among components using dashed arrows.

                                                               

                                               Figure: Component with dependency

It is used in any of the following ways:

1.     model the source code.

2.     model the executable releases.

3.     model physical database.

4.     model adaptable systems.

DEPLOYMANE DIAGRAM

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

A deployment diagram shows the configuration of run time processing nodes and the components that live on them.

The deployment view contains the nodes instances connected by communication links deployment diagrams are used to visualize the static aspect of physical nodes and their relationships and specifies their details for constructions.

The main concepts of a deployment diagram are nodes and dependency and association relationships.

These diagrams may contain nodes and constraints apart from components these diagrams may also contain packages or subsystems.

Basic Deployment Diagram Symbols and Notations:

Node:

A node is a physical resource that executes code components.

                                             

                                                           Figure: Node

Association:

Association refers to a physical connection between nodes, such as Ethernet.

                                             

                                        Figure: Association between the nodes

Components and Nodes:

Place components inside the node that deploys them.

                                                     

Figure: Components and nodes

Relationships:

Dependency:

A dependency is a semantic relationship between two things in which a change to one thing may affect the semantics of the other thing. Graphically, a dependency is rendered as a dashed line, possibly directed, and occasionally including a label.

                                             

                                                   Figure: Dependency

Association:

An association is a structural relationship that describes a set of links, a link being a connection among objects. Graphically, an association is rendered as a solid line, possibly directed, occasionally including a label, and often containing other adornments, such as multiplicity and role names.

                                                   0…1

                                                   employer                        employee

                                                          Figure: Association

The deployment view usually addresses the distribution, delivery and installation of the parts that make up the physical system.

These diagrams can be used to model the static development view in one of the following ways:

mode embedded systems.

model client/server systems.

model fully developed systems.

                                                   5.1. DATA FLOW DIAGRAM

A structured analysis technique that employs a set of visual representations of the data that moves through the organization, he paths through which the data moves, and the processes that produce, use, and transform data.

A DFD shows what kinds of data will be input to and output from the system, where the data will come from and go to, and where the data will be stored. It does not show information about the timing of processes, or information about whether processes will operate in sequence or in parallel 

   The following are used in drawing dfds:

                                                         

An Example of a data flow diagram:

                            

DFD for Online Course Reservation System:

5.2.ER-DIAGRAM

An Entity-Relationship Model (ERM) is an abstract and conceptual representation of data. Entity-relationship modeling is a database modeling method, used to produce a type of conceptual schema or semantic data model of a system, often a relational database, and its requirements in a top-down fashion. Diagrams created by this process are called entity-relationship diagrams, ER diagrams.

The Building Blocks: Entities, Relationships, and Attributes:

An entity may be a physical object such as a house or a car, an event such as a house sale or a car service, or a concept such as a customer transaction or order.

A relationship captures how two or more entities are related to one another. Relationships can be thought of as verbs, linking two or more nouns.

Examples: an ‘owns’ relationship between a company and a computer, a supervises relationship between an employee and a department.

Every entity (unless it is a weak entity) must have a minimal set of uniquely identifying attributes, which is called the entity's primary key.

Entity-relationship diagrams don't show single entities or single instances of relations. Rather, they show entity sets and relationship sets. Example: a particular song is an entity. The collection of all songs in a database is an entity set. The eaten relationship between a child and her lunch is a single relationship. The set of all such child-lunch relationships in a database is a relationship set.

Connections

Two related entities.

An entity with an attribute.

A relationship with an attribute.

Two Related Entities

An Entity with an attribute

                            

ER Diagram for Online Course Reservation:

             

                                            6. DATA DICTIONARY

Student:

Field name	Data Type	Constraint
Name	String	Not Null
Address	Varchar2	Not Null
Marks	Int	Not Null
StudentID	Int	Primary key

Admin:

Field name	Data Type	Constraint
AdminID	Int	Primary key
Authenticate	String	Not Null
Reject	String	Not Null

                              7.  TEST DATA GENERATION

Introduction:

Testing presents an interesting anomaly for the software engineer. During earlier software engineering activities, the engineer attempts to build software from an abstract concept to a tangible product. Now comes testing. The engineer creates a series of test cases that are intended to “demolish” the software that has been built. In fact, testing is the one step in the software process that could be viewed (psychologically, at least) as destructive rather than constructive.

Software engineers are by their nature constructive people. Testing requires that the developer discard preconceived notions of the “correctness” of software just developed and overcome a conflict of interest that occurs when errors are uncovered.

If testing is conducted successfully (according to the objectives stated previously), it will uncover errors in the software. As a secondary benefit, testing demonstrates that software functions appear to be working according to specification, that behavioral and performance requirements appear to have been met. In addition, data collected as testing is conducted provide a good indication of software reliability and some indication of software quality as a whole. But testing cannot show the absence of errors and defects, it can show

Only that software errors and defects are present. It is important to keep this (rather gloomy) statement in mind as testing is being conducted.

Testing principles:

Before applying methods to design effective test cases, a software engineer must understand the basic principle that guide software testing:

All tests should be traceable to customer requirements

Tests should be planned long before testing begins

80 percent of all errors uncovered during testing will likely be traceable to 20 percent of all program components. The problem, of course, is to isolate these suspect components and to thoroughly test them.

Testing should being “in the small” and progress toward testing “in the large”.

Exhaustive testing is not possible

To be most effective an independent third party should conduct testing

A rich variety of test case design methods have evolved for software. These methods provide the developer with a systematic approach to testing. More important, methods provide a mechanism that can help to ensure the completeness of tests and provide the highest likelihood for uncovering errors in software.

Any engineered product (and most other things) can be tested in one of two ways:

Knowing the specified function that a product has been designed to perform, tests can be conducted that demonstrate each function is fully operational

While at the same time searching for errors in each function; (2) knowing the internal

Working of a product, tests can be conducted to ensure that “all gears mesh,” that is, internal operations are performed according to specifications and all internal components have been adequately exercised. The first test approach is called black box testing and the second, white-box testing.

v Testing performed were:

ü UNIT TESTING

ü INTEGRATION TESTING

ü DATABASE TESTING

ü RECOVERY TESTING

ü FUNCTIONALITY TESTING

§  SMOKE TEST

§  SANITY TEST

ü COMPATIBILITY TESTING

ü LOAD TESTING

ü SYSTEM TESTING

ü PERFORMANCE TESTING

ü USER ACCEPTANCE TESTING

White box testing

Sometimes called glass-box testing is a test case design method that uses the control structure of the procedural design to derive test cases. Using white-box testing methods, the software engineer can derive test cases that (1) guarantee that all independent paths within a module have been exercised at least once, (2) exercise all logical decisions on their true and false sides, (3) execute all loops at their boundaries and within their operational bounds, and (4) exercise internal data structures to ensure their validity.

White-box testing of software is predicated on close examination of procedural detail. Providing test cases that exercise specific sets of conditions and/or loops tests logical paths through the software. The “status of the program” may be examined at various points to determine if the expected or asserted status corresponds to the actual status. Basis path testing is a white-box testing technique first proposed by Tom McCabe. The basis path method enables the test case designer to derive a logical complexity measure of a procedural design and use this measure as a guide for defining a basis set of execution paths. Test cases derived to exercise the basis set are guaranteed to execute every statement in the program at least one time during testing.

In this system, the system was tested for the calculation matters were the data provided for giving the right output or not. If wrong data was provided then what it is throwing error or accepting

Black box testing:

Also called behavioral testing, focuses on the functional requirements of the software. That is, black box testing enables the software engineer to derive sets of input conditions that will fully exercise all functional requirements for a program. Black box testing is not an alternative to white-box techniques. Rather, it is a complementary approach that is likely to uncover a different class of error than white-box methods. When computer software is considered, black box testing alludes to tests that are conducted at the software interface. Although they are designed to uncover errors, black-box tests are used to demonstrate that software functions are operational, that input is

Properly accepted and output is correctly produced and that the integrity of external information is maintained. A black-box test examines some fundamental aspect of a system with a little regard for the internal logical structure of the software. Black-box testing attempts to find errors in the following categories:

1.     Incorrect or missing functions,

2.     Interface errors,

3.     Errors in data structures or external database access,

4.     Behavior or performance errors, and

5.     Initialization and termination errors. By applying back-box techniques, we derive a set of test cases that satisfy the following criteria:

a.                             Test cases that reduce, by a count that is greater than one, the number of additional test cases that must be designed to achieve reasonable testing and

b.                             Test cases that tell us something about the presence or absence of classes of errors, rather than an error associated only with the specific test at hand.

White-box testing should not, however, be dismissed as impractical. A limited number of for validity. The attributes of both black and white box testing can be combined to provide an approach that validates the software interface and selectively ensures that the internal workings of the software are correct.

Black box testing for this system was done to check the internal testing i.e, the system is working properly in each case or no. What kind of errors are there in database design.

Test data generation

Input	Behaviour	Output
Login id	Valid	Permission granted
Login id	Not valid	Permission not granted
Password	Valid	Permission granted
Password	Not valid	Permission not granted
Interview	Pass	Select applicant
Interview	Not pass	Reject applicant
Course	Available	Course registered
Course	Not avalaible	Course not registered
Allot seats	Seats available	Block seats
Allot seats	Seats not available	Cannot block seats

            8. COST AND RESOURCE ESTIMATION:

Software cost estimation is the process of predicting the effort required to develop a software system. Many estimation models have been proposed over the last 30 years.

Models may be classified into 2 major categories: algorithmic and non-algorithmic. Each has its own strengths and weaknesses. A key factor in selecting a cost estimation model is the accuracy of its estimates. Unfortunately, despite the large body of experience with estimation models, the accuracy of these models is not satisfactory.

Keywords: project estimation, effort estimation, cost models.

Introduction

Accurate cost estimation is important because:

• It can help to classify and prioritize development projects with respect to an overall business plan.

• It can be used to determine what resources to commit to the project and how well these resources will be used.

• It can be used to assess the impact of changes and support replanning.

• Projects can be easier to manage and control when resources are better matched to real needs.

• Customers expect actual development costs to be in line with estimated costs.

Software cost estimation involves the determination of one or more of the following estimates:

• effort (usually in person-months)

• project duration (in calendar time)

• cost (in dollars)

The three fundamental issues that need to be resolved are:

• Which software cost estimation model to use?

• Which software size measurement to use – lines of code (LOC), function points (FP), or feature point?

• What is a good estimate?

The widely practiced cost estimation method is expert judgment. For many years, project managers have relied on experience and the prevailing industry norms as a basis to develop cost estimate. However, basing estimates on expert judgment is problematic:

• This approach is not repeatable and the means of deriving an estimate are not explicit.

• It is difficult to find highly experienced estimators for every new project.

• The relationship between cost and system size is not linear. Cost tends to increase exponentially with size. The expert judgment method is appropriate only when the sizes of the current project and past projects are similar.

• Budget manipulations by management aimed at avoiding overrun make experience and data from previous projects questionable.

In the last three decades, many quantitative software cost estimation models have been developed. They range from empirical models such as Boehm’s COCOMO models to analytical models. An empirical model uses data from previous projects to evaluate the current project and derives the basic formulae from analysis of the particular database available. An analytical model, on the other hand, uses formulae based on global assumptions, such as the rates at which developer solve problems and the number of problems available.

A good software cost estimate should have the following attributes:

• It is conceived and supported by the project manager and the development team.

• It is accepted by all stakeholders as realizable.

• It is based on a well-defined software cost model with a credible basis.

• It is based on a database of relevant project experience (similar processes, similar technologies, similar environments, similar people and similar requirements).

• It is defined in enough detail so that its key risk areas are understood and the probability of success is objectively assessed.

Process of estimation

Cost estimation is an important part of the planning process. For example, in the top-down planning approach, the cost estimate is used to derive the project plan:

1. The project manager develops a characterization of the overall functionality, size, process, environment, people, and quality required for the project.

2. A macro-level estimate of the total effort and schedule is developed using a software cost estimation model.

3. The project manager partitions the effort estimate into a top-level work breakdown structure. He also partitions the schedule into major milestone dates and determines a staffing profile, which together forms a project plan.

The actual cost estimation process involves seven steps :

1. Establish cost-estimating objectives

2. Generate a project plan for required data and resources

3. Pin down software requirements

4. Work out as much detail about the software system as feasible

5. Use several independent cost estimation techniques to capitalize on their combined strengths

6. Compare different estimates and iterate the estimation process

7. After the project has started, monitor its actual cost and progress, and feedback results to project management

Software sizing

The software size is the most important factor that affects the software cost. This section describes five software size metrics used in practice. The line of code and function point are the most popular metrics among the five metrics.

Line of Code: This is the number of lines of the delivered source code of the software, excluding comments and blank lines and is commonly known as LOC . Although LOC is programming language dependent, it is the most widely used software size metric. Most models relate this measurement to the software cost. However, exact LOC can only be obtained after the project has completed. Estimating the code size of a program before it is actually built is almost as hard as estimating the cost of the program.

A typical method for estimating the code size is to use experts' judgment together with a technique called PERT . It involves experts' judgment of three possible code-sizes: Sl, the lowest possible size; Sh the highest possible size; and Sm, the most likely size. The estimate of the code-size S is computed as:

64 m h l S S SS+ +=PERT

can also be used for individual components to obtain an estimate of the software system by summing up the estimates of all the components. of the experts’ estimates and the rationale for the estimates.

Function points: This is a measurement based on the functionality of the program and was first introduced by Albrecht . The total number of function points depends on the counts of distinct(in terms of format or processing logic) types in the following five classes:

1. User-input types: data or control user-input types

2. User-output types: output data types to the user that leaves the system

3. Inquiry types: interactive inputs requiring a response

4. Internal file types: files (logical groups of information) that are used and shared inside the

system

5. External file types: files that are passed or shared between the system and other systems

Each of these types is individually assigned one of three complexity levels of {1 = simple, 2 =medium, 3 = complex} and given a weighting value that varies from 3 (for simple input) to 15(for complex internal files).

This initial function-point count is either directly used for cost estimation or is further modified by factors whose values depend on the overall complexity of the project. This will take into account the degree of distributed processing, the amount of reuse, the performance requirement, etc. The final function-point count is the product of the UFC unadjusted function-point counts and these project complexity factors. The advantage of the function-point measurement is that it can be obtained based on the system requirement specification in the early stage of software development

Extensions of function point: Feature point extends the function points to include algorithms as a new class. An algorithm is defined as the set of rules which must be completely expressed to solve a significant computational problem. Each algorithm used is given a weight ranging from 1 (elementary) to 10 (sophisticated algorithms) and the feature point is the weighted sum of the algorithms plus the function points. This measurement is especially useful for systems with few input/output and high algorithmic complexity, such as mathematical software, discrete simulations, and military

Applications.

Object points: This measurement is based on the number and complexity of

the following objects: screens, reports and 3GL components. Each of these objects is counted and given a weight ranging from 1 (simple screen) to 10 (3GL component) and the object point is the weighted sum of all these objects.It is easy to use at the early phase of the development cycle and also measures software size reasonably well, this measurement has been used in major estimation

models such as COCOMO II for cost estimation .

Cost estimation

There are two major types of cost estimation methods: algorithmic and non-algorithmic.

Algorithmic models vary widely in mathematical sophistication. Some are based on simple arithmetic formulas using such summary statistics as means and standard deviations.Others are based on regression models and differential equations . To improve the accuracy of algorithmic models, there is a need to adjust or calibrate the model to local circumstances. These models cannot be used off-the-shelf. Even with calibration the accuracy can be quite mixed

 Non-algorithmic Methods

Analogy costing: This method requires one or more completed projects that are similar to the new project and derives the estimation through reasoning by analogy using the actual costs of previous projects. Estimation by analogy can be done either at the total project level or at subsystem level. The total project level has the advantage that all cost components of the system will be considered while the subsystem level has the advantage of providing a more detailed assessment of the similarities and differences between the new project and the completed projects. The strength of this method is that the estimate is based on actual project experience.

Expert judgment: This method involves consulting one or more experts. The experts provide estimates using their own methods and experience. Expert-consensus mechanisms such as Delphi technique or PERT will be used to resolve the inconsistencies in the estimates. The Delphi technique works as follows:

1) The coordinator presents each expert with a specification and a form to record estimates.

2) Each expert fills in the form individually (without discussing with others) and is allowed to ask the coordinator questions.

3) The coordinator prepares a summary of all estimates from the experts (including mean or median) on a form requesting another iteration

4) Repeat steps 2)-3) as many rounds as appropriate.

Parkinson: Using Parkinson's principle “work expands to fill the available volume”  the cost is determined (not estimated) by the available resources rather than based on an objective assessment. If the software has to be delivered in 12 months and 5 people are available, the effort is estimated to be 60 person-months. Although it sometimes gives good estimation, this method is not recommended as it may provide very unrealistic estimates. Also, this method does not promote good software engineering practice.

Price-to-win: The software cost is estimated to be the best price to win the project. The estimation is based on the customer's budget instead of the software functionality. For example, if a reasonable estimation for a project costs 100 person-months but the customer can only afford 60 person-months, it is common that the estimator is asked to modify the estimation to fit 60 person months’ effort in order to win the project. This is again not a good practice since it is very likely to cause a bad delay of delivery or force the development team to work overtime.

Bottom-up: In this approach, each component of the software system is separately estimated and the results aggregated to produce an estimate for the overall system. The requirement for this approach is that an initial design must be in place that indicates how the system is decomposed into different components.

Top-down: This approach is the opposite of the bottom-up method. An overall cost estimate for the system is derived from global properties, using either algorithmic or non-algorithmic methods. The total cost can then be split up among the various components. This approach is more suitable for cost estimation at the early stage.

Algorithmic methods

The algorithmic methods are based on mathematical models that produce cost estimate as a function of a number of variables, which are considered to be the major cost factors. Any algorithmic model has the form:

Effort = f(x1, x2, …, xn)

where {x1, x2, …, xn} denote the cost factors. The existing algorithmic methods differ in two aspects: the selection of cost factors, and the form of the function f..

Cost factors

Besides the software size, there are many other cost factors. The most comprehensive set of cost factors are proposed and used by Boehm et al in the COCOMO II model . These cost factors can be divided into four types:

Product factors: required reliability; product complexity; database size used; required reusability; documentation match to life-cycle needs;

Computer factors: execution time constraint; main storage constraint; computer turnaround constraints; platform volatility;

Personnel factors: analyst capability; application experience; programming capability; platform experience; language and tool experience; personnel continuity;

Project factors: multisite development; use of software tool; required development schedule.

The above factors are not necessarily independent, and most of them are hard to quantify. In many models, some of the factors appear in combined form and some are simply ignored. Also, some factors take discrete values, resulting in an estimation function with a piece-wise form.

4.2.2 Linear models

Linear models have the form:

Effort = å= + n

i i i x a a

1 0

where the coefficients a1, …, an are chosen to best fit the completed project data. The work of

Nelson belongs to this type of models . Boehm's comment that "there are too many nonlinear interactions in software development for a linear model to work well"  is widely accepted.

4.2.3 Multiplicative models

Multiplicative models have the form:

Effort = Õ=

n

i

x

i

i a a

1 0

Again the coefficients a1, …, an are chosen to best fit the completed project data. Walston-Felix used this type of model with each xi taking on only three possible values: -1, 0, +1. Doty model  also belongs to this class with each xi taking on only two possible values: 0, +1. These two models seem to be too restrictive on the cost factor values.

 Power function models

Power function models have the general form:

Effort = a´Sb

where S is the code-size, and a, b are (usually simple) functions of other cost factors. This class contains two of the most popular algorithmic models in use, as follows:

COCOMO (Constructive Cost Model) models

This family of models was proposed by Boehm . The models have been widely accepted in practice. In the COCOMOs, the code-size S is given in thousand LOC (KLOC) and Effort is in person-month.

A) Basic COCOMO. This model uses three sets of {a, b} depending on the complexity of the software only:

(1) for simple, well-understood applications, a = 2.4, b = 1.05;

(2) for more complex systems, a = 3.0, b = 1.15;

(3) for embedded systems, a = 3.6, b = 1.20.

The basic COCOMO model is simple and easy to use. As many cost factors are not considered, it can only be used as a rough estimate.

B) Intermediate COCOMO and Detailed COCOMO. In the intermediate COCOMO, a nominal effort estimation is obtained using the power function with three sets of {a, b}, with coefficient a being slightly different from that of the basic COCOMO:

(1) for simple, well-understood applications, a = 3.2, b = 1.05

(2) for more complex systems, a = 3.0, b = 1.15

(3) for embedded systems, a = 2.8, b = 1.20

Then, fifteen cost factors with values ranging from 0.7 to 1.66 are determined . The overall impact factor M is obtained as the product of all individual factors, and the estimate is obtained by multiplying M to the nominal estimate.

VERIFICATION:

Testing against specification of system or component. Study it by examining its inputs and relatedoutputs. Key is to devise inputs that have a higher likelihood of causing outputs that reveal the presence of defects. Use experience and knowledge of domain to identify such test cases. Failingthis a systematic approach may be necessary. Equivalence partitioning is where the input to a program falls into a number of classes. E.g. positive numbers vs. negative numbers. Programs normally behave the same way for each member of a class. Partitions exist for both input andoutput. Partitions may be discrete or overlap. Invalid data (i.e. outside the normal partitions) is one or more partitions that should be tested. Test cases are chosen to exercise each portion. Also test boundary cases (atypical, extreme, zero) since these frequently show up defects. For completeness, test all combinations of partitions. Black box testing is rarely exhaustive (becauseone doesn't test every value in an equivalence partition) and sometimes fails to reveal corruptiondefects caused by "weird" combination of inputs. Black box testing should not be used to try andreveal corruption defects caused, for example, by assigning a pointer to point to an object of thewrong type. Static inspection (or using a better programming language!) is preferable for this.

Testing based on knowledge of structure of component (e.g. by looking at source code).Advantage is that structure of code can be used to find out how many test case need to be performed. Knowledge of the algorithm (examination of the code) can be used to identify theequivalence partitions. Path testing is where the tester aims to exercise every independentexecution path through the component. All conditional statements tested for both true and falsecases. If a unit has n control statements, there will be up to 2n possible paths through it. Thisdemonstrates that it is much easier to test small program units than large ones. Flow graphs are a pictorial representation of the paths of control through a program (ignoring assignments, procedure calls and I/O statements). Use flow graph to design test cases that execute each path.Static tools may be used to make this easier in programs that have a complex branching structure.Tools support. Dynamic program analyzers instrument a program with additional code.

  Typically this will count how many times each statement is executed. At end, print out report showingwhich statements have and have not been executed. Problems with flow graph derived testing:Data complexity not taken into account.Does not test all paths in combination.Really only possible at unit and module testing stages because beyond that complexity is too high.

 Interface testing

Usually done at integration stage when modules or sub-systems are combined. Objective is todetect errors or invalid assumptions about interfaces between modules. Reason these are notshown up in unit testing is that test case may perpetuate same incorrect assumption made bymodule designer. Particularly important when OO development has been used. Four types of interface:1. Parameter: data (or occasionally function references) passed from one unit to another.2. Shared memory: block of memory shared between units (e.g. global variable) .One places data thereand the other retrieves it.3. Procedural: object-oriented or abstract data type form of interface, encapsulating several procedures.4. Message passing: one sub-system requests a service by passing a message. Client-server interfacealso used by some OO architectures.

Testing process:

Best testing process is to test each subsystem separately, as we have done in my project. Best doneduring implementation. Best done after small sub-steps of the implementation rather than largechunks. Once each lowest level unit has been tested, units are combined with related units andretested in combination. This proceeds hierarchically bottom-up until the entire system is tested asa whole. Typical levels of testing:Unit -procedure, function, methodModule -package, abstract data type, classSub-system - collection of related modules, cluster of classes, method-message pathsAcceptance testing - whole system with real data (involve customer, user, etc)Alpha testing is acceptance testing with a single client (common for bespoke systems).Beta testing involves distributing system to potential customers to use and provide feedback. In, this project, Beta testing has been followed. This exposes system to situations and errors that mightnot be anticipated by us.

                                       9. USER MANUAL

INPUTS AND OUTPUTS

The major inputs and outputs and major functions of the system are follows:

Inputs:

·        user is registered and enter his user id and password for login.

·        user enter user id or date to track the user login information

·        New users give his completed personnel, address and phone details for registration.

·        User gives his user id, hint question, answer for getting the forgotten password.

·        User can select the courses for registration

·        The payment is done by credit or cash.

·        The user can change the courses in a given duration of time.

Outputs:

·        Users can have their own preferences.

·        The user defined data can store in the centralized database.

·        Administrator will get the login information of a particular user.

·        The new user’s data will be stored in the centralized database.

·        User can get his forgot password.

                                      

                               10.CONCLUSION

The Project was focussed on providing a feasible solutionto the problems faced by institutes while registering new students into the college. The work of manually calling in students interviewing them allotting courses is very hectic. The institute would become a madhouse with people running everwhere to get their work done. Hence, the designed model keeps tracks of students and instructors, which ensures an organized environment. It provides a wireless network for effective communication between the college db and studnets. The model has options for online payment or cash whichever is easy for the student. It is by far the most useful software that is being used on a daily basis among various institutions around the world.

Therefore I can conclude by saying that the designed model fulfills all requirements to ensure that it benefits institutions through modernized means.  

REFERENCES

1)www.wikipedia.com

2)”The Unified Modeling Language User Guide” second edition by Grady Booch,James Rumbaugh and Ivar Jacobson.

3)”The unified software development process”,Pearson Education,India,2008 by Ivar Jacobson,Grady Booch and James Rumbaugh.