EX. NO.

: DATE:

CASE TOOLS

Introduction:
CASE tools known as Computer-aided software engineering tools is a kind of component-based development which allows its users to rapidly develop information systems. The main goal of case technology is the automation of the entire information systems development life cycle process using a set of integrated software tools, such as modeling, methodology and automatic code generation. Component based manufacturing has several advantages over custom development. The main advantages are the availability of high quality, defect free products at low cost and at a faster time. The prefabricated components are customized as per the requirements of the customers. The components used are pre-built, ready-tested and add value and differentiation by rapid customization to the targeted customers. However the products we get from case tools are only a skeleton of the final product required and a lot of programming must be done by hand to get a fully finished, good product.

Characteristics of CASE:
Some of the characteristics of case tools that make it better than customized development are; It is a graphic oriented tool. It supports decomposition of process. Some typical CASE tools are: Unified Modeling Language Data modeling tools, and Source code generation tools

Introduction to UML (Unified Modeling Language):

The UML is a language for specifying, constructing, visualizing, and documenting the software system and its components. The UML is a graphical language with sets of rules and semantics. The rules and semantics of a model are expressed in English in a form known as OCL (Object Constraint Language). OCL uses simple logic for specifying the properties of a system. The UML is not intended to be a visual programming language. However it has a much closer mapping to object-oriented programming languages, so that the best of both can be obtained. The UML is much simpler than other methods preceding it. UML is appropriate for modeling systems, ranging from enterprise information system to distributed web based application and even to real time embedded system. It is a very expensive language addressing all views needed to develop and then to display system even though understand to use. Learning to apply UML effectively starts forming a conceptual mode of languages which requires learning. Three major language elements: UML basic building blocks Rules that dictate how this building blocks put together

 Some common mechanism that apply throughout the language The primary goals in the design of UML are: 1. Provides users ready to use, expressive visual modeling language as well so they can develop and exchange meaningful models. 2. Provide extensibility and specialization mechanisms to extend the core concepts. 3. Be independent of particular programming languages and development processes. 4. Provide formal basis for understanding the modeling language. 5. Encourage the growth of the OO tools market. 6. Support higher-level development concepts. 7. Integrate best practices and methodologies. Every complex system is best approached through a small set of nearly independent views of a model. Every model can be expressed at different levels of fidelity. The best models are connected to reality. The UML defines nine graphical diagrams: 1. Class diagram 2. Use-case diagram 3. Behavior diagram 3.1. Interaction diagram 3.1.1. sequence diagram 3.1.2. collaboration diagram 3.2. state chart diagram 3.3. activity diagram 4. Implementation diagram 4.1 component diagram 4.2 deployment diagram

1. UML class diagram:

The UML class diagram is also known as object modeling. It is a static analysis diagram. These diagrams show the static structure of the model. A class diagram is a connection of static model elements, such as classes and their relationships, connected as a graph to each other and to their contents.

2. Use-case diagram:
The functionality of a system can be described in a number of different usecases, each of which represents a specific flow of events in a system. It is a graph of actors, a set of use-cases enclosed in a boundary, communication, associations between the actors and the use-cases, and generalization among the use-cases.

3. Behavior diagram:
It is a dynamic model unlike all the others mentioned before. The objects of an object oriented system are not static and are not easily understood by static diagrams.

The behavior of the classs instance (an object) is represented in this diagram. Every use-case of the system has an associated behavior diagram that indicates the behavior of the object. In conjunction with the use-case diagram we may provide a script or interaction diagram to show a time line of events. It consists of sequence and collaboration diagrams.

4. Interaction diagram
It is the combination of sequence and collaboration diagram. It is used to depict the flow of events in the system over a timeline. The interaction diagram is a dynamic model which shows how the system behaves during dynamic execution.

5. State chart diagram:

It consists of state, events and activities. State diagrams are a familiar technique to describe the behavior of a system. They describe all of the possible states that a particular object can get into and how the object's state changes as a result of events that reach the object. In most OO techniques, state diagrams are drawn for a single class to show the lifetime behavior of a single object.

6. Activity diagram:
It shows organization and their dependence among the set of components. These diagrams are particularly useful in connection with workflow and in describing behavior that has a lot of parallel processing. An activity is a state of doing something: either a real-world process, or the execution of a software routine.

7. Implementation diagram:
It shows the implementation phase of the systems development, such as the source code structure and the run-time implementation structure. These are relatively simple high level diagrams compared to the others seen so far. They are of two subdiagrams, the component diagram and the deployment diagram.

8. Component diagram:
These are organizational parts of a UML model. These are boxes to which a model can be decomposed. They show the structure of the code itself. They model the physical components such as source code, user interface in a design. It is similar to the concept of packages.

9. Deployment diagram:
The deployment diagram shows the structure of the runtime system. It shows the configuration of runtime processing elements and the software components that live in them. They are usually used in conjunction with deployment diagrams to show how physical modules of code are distributed on the system.

Notation elements:
These are explanatory parts of UML model. They are boxes which may apply to describe and remark about any element in the model. They provide the information for understanding the necessary details of the diagrams.

Relations in the UML:

These are four kinds of relationships used in an UML diagram, they are: Dependency Association Generalization Realization

Dependency:
It is a semantic relationship between two things in which a change one thing affects the semantics of other things. Graphically a dependency is represented by a non-continuous line.

Association:
It is a structural relationship that describes asset of links. A link is being connected among objects. Graphically association is represented as a solid line possibly including label.

Generalization:
It is a specialized relationship in which the specialized elements are substitutable for object of the generalized element. Graphically it is a solid line with hollow arrow head parent.

Realization:
It is a semantic relation between classifiers. Graphically it is represented as a cross between generalization and dependency relationship. Where UML can be used: UML is not limited to modeling software. In fact it is expressive to model non-software such as to show in structure and behavior of health case system and to design the hardware of the system.

Conceptual model be UML:

UML you need to form the conceptual model of UML. This requires three major elements: UML basic building blocks. Rules that dictate how this building blocks are put together. Some common mechanism that apply throughout the language. Once you have grasped these ideas, you may be able to read. UML create some basic ones. As you gain more experience in applying conceptual model using more advanced features of this language.

Building blocks of the UML:

The vocabulary of UML encompasses these kinds of building blocks.

Use CASE definition: Description:

A use case is a set of scenarios tied together by a common user goal. A use case is a behavioral diagram that shows a set of use case actions and their relationships.

Purpose:
The purpose of use case is login and exchange messages between sender and receiver (Email client).

Main flow:
First, the sender gives his id and enters his login. Now, he enters the message to the receiver id.

Alternate flow:
If the username and id by the sender or receiver is not valid, the administrator will not allow entering and Invalid password message is displayed.

Pre-condition:
A person has to register himself to obtain a login ID.

Post-condition:
The user is not allowed to enter if the password or user name is not valid.

Class diagram: Description:

A class diagram describes the type of objects in system and various kinds of relationships that exists among them. Class diagrams and collaboration diagrams are alternate representations of object models. During analysis, we use class diagram to show roles and responsibilities of entities that provide email client system behaviors design. We use to capture the structure of classes that form the email client system architecture. The classes used in system are: 1. 2. 3. 4. user login s ds

A class diagram is represented as: <<Class name>> <<Attribute 1>> <<Attribute n>> <<Operation ()>>

Relationship used:
A change in one element affects the other

Generalization:
It is a kind of relationship

State chart: Description:

The state chart diagram made the dynamic behavior of individual classes. State chart shows the sequences of states that an object goes through events and state transitions. A state chart contains one state start and multiple end states.

The important objectives are:

Decision:
It represents a specific location state chart diagram where the work flow may branch based upon guard conditions.

Synchronization:
It gives a simultaneous workflow in a state chart diagram. They visually define forks and joints representing parallel workflow.

Forks and joins:

A fork construct is used to model a single flow of control. Every work must be followed by a corresponding join. Joints have two or more flow that unit into a single flow.

State:
A state is a condition or situation during a life of an object in which it satisfies condition or waits for some events.

Transition:
It is a relationship between two activities and between states and activities.

Start state:
A start state shows the beginning of a workflow or beginning of a state machine on a state chart diagram.

End state:
It is a final or terminal state.

Activity diagram Description:

Activity diagram provides a way to model the workflow of a development process. We can also model this code specific information such as class operation using activity diagram. Activity diagrams can model different types of diagrams. There are various tools involved in the activity diagram.

Activity:

An activity represents the performance of a task on duty. It may also represent the execution of a statement in a procedure.

Decision:
A decision represents a condition on situation during the life of an object, which it satisfies some condition or waits for an event.

Start state:
It represents the condition explicitly the beginning of a workflow on an activity.

Object flow:
An object on an activity diagram represents the relationship between activity and object that creates or uses it.

Synchronization:
It enables us to see a simultaneous workflow in an activity.

End state:
An end state represents a final or terminal state on an activity diagram or state chart diagram.

Sequence diagram: Description:

A sequence diagram is a graphical view of scenario that shows object interaction in a time based sequence what happens first what happens next. Sequence diagrams are closely related to collaboration diagram. The main difference between sequence and collaboration diagram is that sequence diagram show time based interaction while collaboration diagram shows objects associated with each other. The sequence diagram for the e-mail client system consists of the following objectives:

Object:
An object has state, behavior and identity. An object is not based is referred to as an instance. The various objects in e-mail client system are: User Website

 Login Groups

Message icon:
A message icon represents the communication between objects indicating that an action will follow. The message icon is the horizontal solid arrow connecting lifelines together.

Collaboration diagram: Description:

Collaboration diagram and sequence diagrams are alternate representations of an interaction. A collaboration diagram is an interaction diagram that shows the order of messages that implement an operation or a transaction. Collaboration diagram is an interaction diagram that shows the order of messages that implement an operation or a transaction. Collaboration diagram shows object s, their links and their messages. They can also contain simple class instances and class utility instances. During, analysis indicates the semantics of the primary and secondary interactions. Design, shows the semantics of mechanisms in the logical design of system. Toggling between the sequence and collaboration diagrams When we work in either a sequence or collaboration diagram, it is possible to view the corresponding diagram by pressing F5 key.

EX. NO.: DATE:

ATM SYSTEM

Aim:
To create a system to perform Bank ATM transaction

Problem statement:
This system is build for the bank client and the manager. The bank client must be able to deposit and withdraw amount from his/her accounts using the ATM machine. Each transaction must be recorded and the client must be able to review all transactions performed in his/her account. Recorded transactions must include the date, time, transaction type, amount and account balance after the transaction. The bank manager must be able to view the ATM machine status that is the total balance of the ATM machine, todays withdrawal, todays balance and the limitations of the machine. The bank client is provided by login verification. If it is valid he/she will access their account otherwise an appropriate message is displayed to the client.

Software requirements:
Microsoft visual basic 6.0 is used as front-end for our project and ms-access is used as back-end to store the data.

USE-CASE diagram:
The ATM transaction use cases in our system are: 1. Login 2. Withdraw 3. Mini statement 4. ATM machine status 5. Deposit

Actors involved:
1. User 2. Bank manager

USE-CASE name: Login

The user enters a user name and password. If it is valid, the users account becomes available. If it is invalid, an appropriate message is displayed to the user.

USE-CASE name: Withdraw

The user tries to withdraw an amount from his or her checking account. The amount is less than or equal to the checking accounts balance, the transaction is performed and the available information is displayed. The system creates a record of the transaction and the display confirmation message is displayed to the client.

USE-CASE name: Mini statement

The bank user requests a history of transactions for a checking account. The system displays the transaction history for the checking account. The transaction history consists of amount, date, transaction type and balance of the particular account.

USE-CASE name: ATM machine status

The bank manager enters a username and password. If it is valid, the bank manager accesses the machine status. If it is invalid, an appropriate message is displayed to the user.

USE-CASE name: Deposit

The bank user requests the system to deposit money to an account. The user accesses the account for which a deposit is going to be made and enters the amount. The system creates a record of the transaction and an appropriate confirmation message (display confirmation) is displayed to the client. The transaction must include the date, type, amount and account balance after the transaction.

SOFTWARE TESTING
There are four basic types of testing 1. Black-box testing 2. White-box testing 3. Top-down testing 4. Bottom-up testing

TESTING
The extent of testing a system is controlled by many factors, such as the risks involved, limitation on resources, and deadlines. In light of these issues, we must deploy a testing strategy that does the "best" job of finding defects in a product within the given constraints. There are many testing strategies, but most testing uses a

combination of these: black box testing, while box testing,top-down testing, and bottom-up testing. However, no strategy or combination of strategies trulycan prove the correctness of a system; it can establish only its "acceptability".

BLACK BOX TESTING

The concept of the black box is used to represent a system whose inside workings are not available for inspection. In a black box, the test item is treated as "black", since its logic is unknown;all that is known is what does in what comes out, or the input and output. Weinberg describes writing a user manual does not show the internal logic, because the users of the system do not care about what is inside the system.

WHITE BOX TESTING

White box testing assusmes that the specific logic is important and must be tested to guarantee the system's proper functioning. The main use of the white box is in error-based testing, when you already have tested all objects of an application and all external or public methods of an object that you believe to be of greater importance. In while box testing, you are looking for bugs that have a low probability of execution, have been carelessly implemented, or were overlooked previously. One form of white box testing called path testing, makes certain that each path in an object's method is executed at least once during testing. Two types of path testing are statement testing coverage and branch testing coverage.

Statement testing coverage:

The main idea of statement testing coverage is to test every statement in the objects method by executing it al least once. Murray states, "testing less than this for new software is unconscionable and should be criminalized". However realistically, it is impossible to test a program on every single input, so you never can be sure that the program will not fail on some input.

Branch testing coverage:

The main idea of branch testing coverage is to perform enough tests to ensure that every branch alternative has been executed at least once under some test. As is statement testing coverage, it is unfeasible to fully test any program of considerable size.Most debugging tools are excellent in statement and branch testing coverage. White box testing is useful for error based testing.

TOP-DOWN TESTING
Top-down testing assumes that the main logic or object interactions and system messages of the application need more testing that an individual objects

methods or supporting logic. A top-down strategy can detect the serious design flaws early in the implementation. In theory, top-down testing should find critical design errors early in the testing process and significantly improve the quality of the delivered software because of the iterative nature of the test. A top-down strategy testing the user interface and event-driven systems. Testing the user interface using a top-down approach means testing interface navigation. This serves two purposes, according to Conger. First, the top-down approach can test the navigation through screens and verify that it matches the requirements. Second, user can see, at an early stage, how the final application will look and feel. This approach also is useful for scenario based testing. Top-down testing is useful to test sub system and system integration.

BOTTOM-UP TESTING
Bottom-up testing starts with the details of the system and proceeds to higher levels by a progressive aggregation of details until they collectively fir the requirements for the system. Here, you test each object, then combine them and test theri interaction and messages passed among objects by utilizing the top-down approach. In bottom-up testing, you start with methods and classes that call or rely on no others. You test them thoroughly. Then you progress to the next level up; those methods and classes that use only the bottom level ones already tested. Next, you test combination of bottom two layers. Proceed until you are testing the entire program. This strategy makes sense because you are checking the behaviour of a piece of code before it is use by another. Bottom-up testing leads to integration testing,which leads to system testing.

VARIOUS OTHER TESTING: Regression Testing:

All Passed Tests are repeated with the revised program, which can discover errors introduced during the debugging process.

Unit Testing:
The test process that is made module by module is known as Unit Testing.

Integration Testing:
The test process that can be performed to any module directly without going through all the above modules is known as Integration Testing.

System Testing:

The test process that is performed after the completion of the whole process is known as System Testing.

Use-case diagram for ATM system

Class diagram
The class diagram, also referred to as object modeling is the main static analysis diagram. The main task of object modeling is to graphically show what each object will do in the problem domain. The problem domain describes the structure and the relationships among objects. The ATM system class diagram consists of four classes: 1. User class 2. ATM machine status 3. Account 4. Transaction

1) User class:
It consists of four attributes and two operations. The attributes are user name, password, address and DOB. The operations of this class are read (), display () and write ().

2) ATM machine status:

The attributes of this class are ATM balance, todays withdrawal, todays balance, and limitations. The operations are login verification (), ATM status () and display confirmation ().

3) Account:
The attributes are account no. and balance and the operations are withdraw (), deposit () and display availability ().

4) Transaction:
The attributes of this class are account no, transaction type, data, amount, balance and the operations are mini statement () and create transaction ().

Class diagram for ATM system

Sequence diagram:
A sequence diagram represents the sequence and interactions of a given USECASE or scenario. Sequence diagrams can capture most of the information about the system. Most object to object interactions and operations are considered events and events include signals, inputs, decisions, interrupts, transitions and actions to or from users or external devices. An event also is considered to be any action by an object that sends information. The event line represents a message sent from one object to another, in which the form object is requesting an operation be performed by the to object. The to object performs the operation using a method that the class contains. It is also represented by the order in which things occur and how the objects in the system send message to one another. The sequence diagram for each USE-CASE that exists when a user withdraws, deposits, needs information about ATM machine status and account are drowned.

Sequence and collaboration diagram for deposit process

The diagrams show the entire deposit process in an ATM system. The user has to login to the ATM machine and deposit the amount of money as required by the user. The user may wish to get a ministatement and a screen about the details of the transaction. Sequence and collaboration diagram for login

The diagrams show the process of login by the user to the ATM system. The user has to enter his details. The details entered are verified by the system and the user is approved if the details match, otherwise an appropriate error message is displayed.

Sequence and collaboration diagram for checking machine status

The Administrator of the ATM system has to maintain the details about the ATM, He has to check if there is enough money in the ATM and if the ATM is functional without major errors. For this, he may check the ATM machine status occasionally. The process is shown in the above diagrams.

Sequence and collaboration diagram for printing ministatement

After a transaction is carried out successfully, the user must get a ministatement to tell him his accounts details such as balance and transaction number. This process is depicted in the above diagrams. Sequence and collaboration diagram for withdraw process

The user can make withdraw money from his account. The process is depicted in the diagrams above. The user has to login to the system using his username and password, which are verified by the system. After successful verification, the user can choose the amount of money he wants to withdraw from his account. The amount specified by the user is checked by the system to make sure there is enough balance in his account to carry out the transaction. After the transaction is carried out the resulting amount is displayed and the details are updated to the database.

ATM Base Code:

// Source file: java/ATM.java package java; public class ATM { private int pin; private int amt;

private int accno; ATM() { } /** @roseuid 4CAABA1901A5 */ public void withdraw() { } /** @roseuid 4CAABA1F02DE */ public void deposit() { } /** @roseuid 4CAABA260196 */ public ATM() { } } ATM Deposit: // Source file: deposit.java import java.ATM; public class deposit extends ATM { private int amt; deposit() { } /** @roseuid 4CAABCAC0232 */ public void minbalance() { } /** @roseuid 4CAABCB8005D */ public void amtdeposit() { } /** @roseuid 4CAABCC102BF */

public void Deposit() { } } ATM Details: // Source file: details.java import java.ATM; public class details extends ATM { private int accno; private string ename; private string bname; details() { } /** @roseuid 4CAABBCE029F */ public void cusdetails() { } /** @roseuid 4CAABBD50222 */ public void bankdetails() { } /** @roseuid 4CAABBDD0128 */ public void opname() { } } ATM Validity: // Source file: validity.java import java.ATM; public class validity extends ATM { private int pin; validity() { } /**

@roseuid 4CAABCF60186 */ public void checkpwd() { } /** @roseuid 4CAABCFD034B */ public validity() { } } ATM Withdraw: // Source file: withdraw.java import java.ATM; public class withdraw extends ATM { private int amt; withdraw() { } /** @roseuid 4CAABAD90251 */ public void overdraft() { } /** @roseuid 4CAABAE300FA */ public void minbal() { } /** @roseuid 4CAABAE70242 */ public withdraw() { } }

RESULT: Thus the system for ATM is created and executed. The output is verified.

EX. NO.: DATE:

STUDENT MARK ANALYSIS SYSTEM

AIM:
To create a system to analyze the students marks stored in the database.

PROBLEM STATEMENT:
The purpose of this system is to analyze and perform operation on data stored in the database and to provide authentication to avoid unauthorized access by using MS-Access as back end and VB to use as the front end. The entire system is divided into various modules and it has its own objects and classes.

Reports are provided on their basis:

Student marks Average Percentage The main advantage in our system is that data entry becomes very easy and other manipulation, updating can be done easily.

Usecase Diagram:
The student mark analyzing system usecase diagram in our system are, 1. Login 2. Enter the details 3. Process and store details 4. Generate mark and rank list 5. View mark list 6. Logout

Actors Involved:
1. Staff 2. Student 3. Database

Login:
The user enters the user name and password and choose if the user is an database or staff if the entered details are valid the account become available.

Enter the details:

The staff enters the details of the student and these details are stored in the database.

Process and store the details:

The student details are taken from the database processed here and stored in the database.

View mark list:

This usecase is used to display details of student. If the student searched for is not available an appropriate message is displayed.

Logout:
After all the necessary operations are complete. This use case is used to logout of current account.

Class Diagram:
This class diagram is a graphical representation of all the classes used in the system and their operations, attribute and relationships. The mark analsing system make use of the following class: 1. student 2. staff

student:
It consists of details of all the student present in the database. The attribute present in this class are student register no,result,marksheet,nosubject,subcode, subname,passmark,maxmark, totalaverage. The object of this class is created as soon as the student registers the marks. The operations available to this class are login, enter the details, process and store details, generate and marks list, view marklist and logout.

Staff:
It consists of 5 attributes and 3 operations. The attributes are username, password, subcode, subname, marks. The operations are login(), enterdetails(), logout().

Software requirements:
Microsoft Visual Basic 6.0 is used as front- end for our project and MSAccess is used as back-end to store the data.

SOFTWARE TESTING

There are four basic types of testing 1. Black-box testing 2. White-box testing 3. Top-down testing 4. Bottom-up testing

TESTING
The extent of testing a system is controlled by many factors, such as the risks involved, limitation on resources, and deadlines. In light of these issues, we must deploy a testing strategy that does the "best" job of finding defects in a product within the given constraints. There are many testing strategies, but most testing uses a combination of these: black box testing, while box testing,top-down testing, and bottom-up testing. However, no strategy or combination of strategies trulycan prove the correctness of a system; it can establish only its "acceptability".

BLACK BOX TESTING

The concept of the black box is used to represent a system whose inside workings are not available for inspection. In a black box, the test item is treated as "black", since its logic is unknown;all that is known is what does in what comes out, or the input and output. Weinberg describes writing a user manual does not show the internal logic, because the users of the system do not care about what is inside the system.

WHITE BOX TESTING

White box testing assusmes that the specific logic is important and must be tested to guarantee the system's proper functioning. The main use of the white box is in error-based testing, when you already have tested all objects of an application and all external or public methods of an object that you believe to be of greater importance. In while box testing, you are looking for bugs that have a low probability of execution, have been carelessly implemented, or were overlooked previously. One form of white box testing called path testing, makes certain that each path in an object's method is executed at least once during testing. Two types of path testing are statement testing coverage and branch testing coverage. Statement testing coverage: The main idea of statement testing coverage is to test every statement in the objects method by executing it al least once. Murray states, "testing less than this for new software is unconscionable and should be criminalized". However realistically, it is impossible to test a program on every single input, so you never can be sure that the program will not fail on some input. Branch testing coverage: The main idea of branch testing coverage is to perform enough tests to ensure that every branch alternative has been executed at least once under some test.

As is statement testing coverage, it is unfeasible to fully test any program of considerable size.Most debugging tools are excellent in statement and branch testing coverage. White box testing is useful for error based testing.

TOP-DOWN TESTING
Top-down testing assumes that the main logic or object interactions and system messages of the application need more testing that an individual objects methods or supporting logic. A top-down strategy can detect the serious design flaws early in the implementation. In theory, top-down testing should find critical design errors early in the testing process and significantly improve the quality of the delivered software because of the iterative nature of the test. A top-down strategy testing the user interface and event-driven systems. Testing the user interface using a top-down approach means testing interface navigation. This serves two purposes, according to Conger. First, the top-down approach can test the navigation through screens and verify that it matches the requirements. Second, user can see, at an early stage, how the final application will look and feel. This approach also is useful for scenario based testing. Top-down testing is useful to test sub system and system integration.

BOTTOM-UP TESTING
Bottom-up testing starts with the details of the system and proceeds to higher levels by a progressive aggregation of details until they collectively fir the requirements for the system. Here, you test each object, then combine them and test theri interaction and messages passed among objects by utilizing the top-down approach. In bottom-up testing, you start with methods and classes that call or rely on no others. You test them thoroughly. Then you progress to the next level up; those methods and classes that use only the bottom level ones already tested. Next, you test combination of bottom two layers. Proceed until you are testing the entire program. This strategy makes sense because you are checking the behaviour of a piece of code before it is use by another. Bottom-up testing leads to integration testing,which leads to system testing.

VARIOUS OTHER TESTING: Regression Testing:

All Passed Tests are repeated with the revised program, which can discover errors introduced during the debugging process.

Unit Testing:
The test process that is made module by module is known as Unit Testing.

Integration Testing:
The test process that can be performed to any module directly without going through all the above modules is known as Integration Testing.

System Testing:
The test process that is performed after the completion of the whole process is known as System Testing. USE CASE DIAGRAM:

lo gin

S t aff us e rn am e : S tring P as s w o rd : S tring S ubc o de : V a rian t s ub na m e : S trin g M a rk s : Inte ger Log in () E nterde tails () Lo go ut()

E nt er th e det ails

P roc es s a nd s tore de t ails D a tab as e G ene rate m ark and ra nk lis t

S t u dent R e gis t e r no : Int e ge r R es u lt : In te ge r view d etails () log in() V iew ra nk lis t()

vie w m ark lis t

Lo go ut

CLASS DIAGRAM:

C o lle g e c o lln a m e : S t rin g

R a n k lis t N o . S t u d e n t s : In t e g e r R a n k n o : In t e g e r S tuden t R e g is t e r n o : In t e g e r R e s u lt : In t e g e r V ie w d e t a ils () L o g in () V ie w ra n k lis t () S t a ff U s e rn a m e : S t rin g P a s s w o rd : S t rin g S u b c o d e : V a r ia n t S u b n a m e : S trin g M a rk s : In t e g e r L o g in () E n t e rd e t a ils () L o g o u t () Legacy s y s in t _ re c o rd e x t_ re c o rd R e m a rk s : S t rin g M o d ify () U p d a t e () o p n a m e () G e n e ra t e R a n k lis t () R e s u lt ()

M a rk s h e e t N o . s u b je c t s : In t e g e r S u b c o d e : V a ria n t S u b n a m e : S t rin g P a s s m a r k : In t e g e r M a x m a rk : In t e g e r G e n e ra t e ra n k lis t () V ie w m a rk s ( ) M a in t a in ()

L o g in Id : In t e g e r P a s s w o rd : S t rin g V e rify () S t a rt () P a s s w o rd () M a in t a in ()

Sequence Diagram:

It represents the sequences and interaction of a given usecase or scenario. Sequence diagram can capture most of the information about the system. Most objects to objects interactions and operations are considered events and events include signals, input, decision interrupt transaction and actions to or from user or external device. An event also is considered to be any action by an object that sends information. The event line represents a message from one objects to another in which the form objects is requesting an operation using a method that the class contains. It is also represented by the order in which things access and how the objects in the system send message to one another. The sequence diagram for each use case that exists when a user log in, enter the details, process and store details, generate mark and ranklist, logout in the system.

Sequence Diagram for Student Mark Analyzing System

L o g i n : L o g Mn a r k s h e e t :A n a ly s is : R a n k l i s t : i S t a ff : SSt auffd e n t : S t u d e n t t M a rk s h e e t S y s te m R a n k lis t P a s s w o rd ( ) M a i n t a in ( ) V ie w d e ta ils ( ) M a rk s ( ) P ro c e s s in g ( )

R e s u lt ( )

V i e w r a n k li s t ( )

Collaboration Diagram for Student Mark Analyzing System

3 : vie w d e t a i ls ( ) 1 : P a s s w o rd ( ) S tu de n t : S tu d e n t 2 : M a i n t a in ( ) L o g in : L o g in 7 : V ie w r a n k lis t ( ) 4 : M a rk s ( ) M a rk s h e e t : M a rk s h e e t

5 : P r o c e s s in g ( ) S t a ff : S t a ff

R a n k li s t : R a n k li s t 6 : R e s u lt ( )

A n a ly s is : S y s te m

Table requirement: There are two tables required. They are: Student profile table:

In this table, we get the details of the students like name, fathers name, date of birth, age, regulation, hobbies, e-mail id, address, blood group and contact number. It also has fields to search a particular student details, academic details and to modify the existing data. Academic table: In this table, we get the name, register no, department, marks for each subject, total and average. It also has fields to search , add, update and to calculate the percentage.

Activity Diagram:

Enter the system Login Current Login access? no yes Set of operation Viewmarkli st yes no Access denied

Enter the details Process and store the details

Generate marklist

logout

// Source file: College.java public class College { private string collname; College() { } } // Source file: Student.java public class Student {

private integer register_no; private integer result; Student() { } /** @roseuid 4CB2DC3E0227 */ public void view_details() { } /** @roseuid 4CB2DC4400DE */ public void Login() { } /** @roseuid 4CB2DC460080 */ public void ViewrankList() { } } // Source file: Staff.java public class Staff { private string username; private string password; private variant subcode; private string subname; private int marks; Staff() { } /** @roseuid 4CB2DCD10221 */ public void login() { } /** @roseuid 4CB2DCD403C6 */ public void enterdetails() { } /** @roseuid 4CB2DCD900B8 */ public void logout() {

} } // Source file: Marksheet.java public class Marksheet { private int no._of_subjects; private variant subcode; private string subname; private int passmark; private int maxmark; Marksheet() { } /** @roseuid 4CB2DD3303C8 */ public void generateranklist() { } /** @roseuid 4CB2DD3903E6 */ public void viewmarks() { } /** @roseuid 4CB2DD3D01F2 */ public void maintain() { } } // Source file: Legacysys.java public class Legacysys { private int int_record; private int ext_record; private String remarks; Legacysys() { } /** @roseuid 4CB2DD7702E3 */ public void Modify() { } /** @roseuid 4CB2DD7B00B0 */ public void Update() {

} /** @roseuid 4CB2DD7D0275 */ public void opname() { } } // Source file: Login.java public class Login { private int Id; private string password; Login() { } /** @roseuid 4CB2DDB00358 */ public void verify() { } /** @roseuid 4CB2DDB300E6 */ public void start() { } /** @roseuid 4CB2DDB5002B */ public void password() { } /** @roseuid 4CB2DDB60395 */ public void maintain() { } } // Source file: Ranklist.java public class Ranklist { private int No_of_students; private int rank_no; Ranklist() { } /** @roseuid 4CB2DDF10293

*/ public void generateranklist() { } /** @roseuid 4CB2DDF8010B */ public void result() { } }

RESULT:
Thus the system for Student mark analysis is created and executed. The output is verified. Ex. NO.: DATE: Aim: To create a computer system to process employees payroll. Problem statement: This system is built for employee and manager. The employee can view his salary and the manager can add a new employee, update employee details and calculate and credit the salary. The employee and manager can log into the system providing their respective user names at login, if the entered input is incorrect an appropriate message is displayed. System requirements: Microsoft visual basic 6.0 is used as front-end for our project and ms-access as our back-end. Use-case diagram: The payroll use cases in our system are: 1 .Login 2. Add employee 3. Update employee details 4. Delete employee 5. Calculate salary 6. View employee details

Employee Payroll system

7. Logout Actors involved: 1. Manager 2. Employee Use-case name: Login The user enters the username and password and chooses if the user is employee or administrator. If entered details are valid, the users account becomes available. If it is invalid, an appropriate message is displayed to the user.

Use-case name: Add employee Only the manager has access to this use-case. The manager has to provide the details of the employee to create an account for a new employee. If the employee added already exits an appropriate message is displayed. Use-case name: Update employee details This use-case can be accessed only by the manager and not by the employee. The desired employee is searched for and the details of the employee are updated with new entries. If the employee searched for is not available an appropriate message is displayed. Use-case name: Delete employee This use-case can also be used only by the manager. It is used to delete the record of an employee if it is not necessary. The employee identity is provided by the manager which is searched for and if it is found, it is deleted. If it is not found an appropriate message is displayed. Use-case: calculate salary This use-case is used to calculate the salary of the employee after adding allowances and deducting as necessary. The net salary is displayed. This use-case can be used by both employee and by the administrator. The employee details are searched for and the net salary is calculated. Use-case: View employee details This use-case is used to display details of the employee. If the employee searched for is not available, an appropriate message is displayed.

Use-case: logout After all the necessary operations are complete, this use-case is used to logout of the current account. SOFTWARE TESTING There are four basic types of testing 1. Black-box testing 2. White-box testing 3. Top-down testing 4. Bottom-up testing

TESTING The extent of testing a system is controlled by many factors, such as the risks involved, limitation on resources, and deadlines. In light of these issues, we must deploy a testing strategy that does the "best" job of finding defects in a product within the given constraints. There are many testing strategies, but most testing uses a combination of these: black box testing, while box testing,top-down testing, and bottom-up testing. However, no strategy or combination of strategies trulycan prove the correctness of a system; it can establish only its "acceptability". BLACK BOX TESTING The concept of the black box is used to represent a system whose inside workings are not available for inspection. In a black box, the test item is treated as "black", since its logic is unknown;all that is known is what does in what comes out, or the input and output. Weinberg describes writing a user manual does not show the internal logic, because the users of the system do not care about what is inside the system. WHITE BOX TESTING White box testing assusmes that the specific logic is important and must be tested to guarantee the system's proper functioning. The main use of the white box is in error-based testing, when you already have tested all objects of an application and all external or public methods of an object that you believe to be of greater importance. In while box testing, you are looking for bugs that have a low probability of execution, have been carelessly implemented, or were overlooked previously. One form of white box testing called path testing, makes certain that each path in an object's method is executed at least once during testing. Two types of path testing are statement testing coverage and branch testing coverage. Statement testing coverage:

The main idea of statement testing coverage is to test every statement in the objects method by executing it al least once. Murray states, "testing less than this for new software is unconscionable and should be criminalized". However realistically, it is impossible to test a program on every single input, so you never can be sure that the program will not fail on some input. Branch testing coverage: The main idea of branch testing coverage is to perform enough tests to ensure that every branch alternative has been executed at least once under some test. As is statement testing coverage, it is unfeasible to fully test any program of considerable size.Most debugging tools are excellent in statement and branch testing coverage. White box testing is useful for error based testing.

TOP-DOWN TESTING Top-down testing assumes that the main logic or object interactions and system messages of the application need more testing that an individual objects methods or supporting logic. A top-down strategy can detect the serious design flaws early in the implementation. In theory, top-down testing should find critical design errors early in the testing process and significantly improve the quality of the delivered software because of the iterative nature of the test. A top-down strategy testing the user interface and event-driven systems. Testing the user interface using a top-down approach means testing interface navigation. This serves two purposes, according to Conger. First, the top-down approach can test the navigation through screens and verify that it matches the requirements. Second, user can see, at an early stage, how the final application will look and feel. This approach also is useful for scenario based testing. Top-down testing is useful to test sub system and system integration. BOTTOM-UP TESTING Bottom-up testing starts with the details of the system and proceeds to higher levels by a progressive aggregation of details until they collectively fir the requirements for the system. Here, you test each object, then combine them and test theri interaction and messages passed among objects by utilizing the top-down approach. In bottom-up testing, you start with methods and classes that call or rely on no others. You test them thoroughly. Then you progress to the next level up; those methods and classes that use only the bottom level ones already tested. Next, you test combination of bottom two layers. Proceed until you are testing the entire program. This strategy makes sense because you are checking the behaviour of a piece of code before it is use by another. Bottom-up testing leads to integration testing,which leads to system testing.

VARIOUS OTHER TESTING: Regression Testing: All Passed Tests are repeated with the revised program, which can discover errors introduced during the debugging process. Unit Testing: The test process that is made module by module is known as Unit Testing.

Integration Testing: The test process that can be performed to any module directly without going through all the above modules is known as Integration Testing. System Testing: The test process that is performed after the completion of the whole process is known as System Testing. Use-case diagram for payroll system

Class diagram: The class diagram is a graphical representation of all the classes used in the system and their operations, attributes and relationships. The payroll system makes use of the following classes: 1. System 2. Employee details 3. Employee salary 1) System It consists of two attributes and two operations. The attributes are username and password. The operations used are login () and logout (). 2) Employee details

It is used to store the personal details of the employee, such as name, employee id, gender and age. The operations available in this class are view(), add employee(), edit employee details(), view employee details(), delete employee details(). 3) Employee salary It is used to store the salary details of the employee such as basic pay, house rent allowance, dearness allowance, provident fund and insuranece. The operations available are calculate net salary(), view salary details(), update salary details() and deduce fine().

Class diagram for payroll system

Sequence diagram

A sequence diagram represents the sequence and interactions of a given usecase or scenario. Sequence diagrams can capture most of the information about the system. Most object-to-object interactions and operations are considered events and events include signals, inputs, decisions, interrupts, transitions and actions to or from users or external devices. An event also is considered to be any action by an object that sends information. The event line represents a message from one object to another, in which the from object is requesting an operation be performed by the to object. The to object performs the operation using a method that the class contains. It is also represented by the order in which things occur and how the objects in the system send message to one another. The sequence diagram for each use-case that exists when a user logs in, adds, views, updates or deletes records in the system.

Sequence diagram and collaboration for adding an employee

For the adding and an diagram The show

use case of an employee, a sequence interaction are drawn. diagrams that

administrator can only add a new employee. Sequence and collaboration diagram for calculating the net salary

The net salary is calculated by adding the salary details such as basic hra, da, etc., and deducing the insurance and pf amount. Sequence and collaboration diagram for deleting an employee

Only the administrator has privilege to delete an employee. The employee record which has to be deleted is selected by the administrator and deleted.

Sequence and collaboration diagram for editing an employees details

Only the administrator has the privilege to edit employee details. The employee details are selected and edited by the administrator and saved to the database. Sequence and collaboration diagram for viewing employee salary

The employee may wish to view his salary details. An employee may see only his own salary details and not that of anyone else.

Activity Diagram for Employee Payroll System:

Login

A dd em p

M odify em p Details Delete em p

V iew em ployee

Calc ulate s alary

Logout

State chart Diagram for Employee Payroll System:

e m p lo y e e e ve n e ve n e ve n t t t A c d a d l /c ua ld a d t e e m p m o d ify / m o d ify e m p e d v e e l ne tt e c / a d l c e u l e l a t et e e/ m c a p l e n d e x it / lo g o u t

S ta rt e n try / L o g in v ie w

e v e n t v ie w / v ie w e m p
System code:

// Source file: sys.java import java.emp_details; public class sys extends emp_details { private string userid; private string pass; sys() { } /** @roseuid 4CA1664E0237 */ public void login() { } /** @roseuid 4CA166510025 */ public void logout() { } } Emp_details code: // Source file: java/emp_details.java package java; import emp_salary; public class emp_details extends emp_salary { private string name; private integer emp_id; private string gender; private integer age; emp_details() { } /** @roseuid 4CA1658A0126 */ public void view() { } /** @roseuid 4CA1658E0000 */

public void add_emp() { } /** @roseuid 4CA16592014C */ public void edit_emp() { } /** @roseuid 4CA1659900D5 */ public void view_emp() { } /** @roseuid 4CA1659F01A6 */ public void delete_emp() { } } Emp_salary code: // Source file: emp_salary.java public class emp_salary { private int basic; private int hra; private int da; private int pf; private int lic; emp_salary() { } /** @roseuid 4CA1669A0161 */ public void calc_net() { } /** @roseuid 4CA166A102D1 */ public void view_sal() { } /** @roseuid 4CA166A702E9 */

public void edit_sal() { } /** @roseuid 4CA166AD02C4 */ public void deduce_fine() { } /** @roseuid 4CA166B60059 */ public void view() { } }

RESULT: Thus the documentation for employee payroll system is created. The output is verified.

Ex. NO.: DATE: Introduction:

AIRLINE TICKET RESERVATION SYSTEM

The manual system of ticket reservation takes more time and the number of reservations per day is limited. To increase the efficiency of the process, we go for online ticket reservation system. This system supports online ticket booking. Problem statement This system is built for user to directly access the system online to book tickets. The user can book, print, delete tickets without the help of a clerk. The administrator has control over the adding flights available for booking and has control over deleting flights that are not necessary. The administrator and user can both enter the system using their respective login details System requirements Microsoft visual basic 6.0 is used as the front-end for our project and msaccess is used as the back-end. Use-case diagram The online ticket reservation system uses the following use cases: 1. Login 2. Book ticket 3. Print ticket 4. Cancel ticket 5. View flight 6. Add flight 7. Delete flight 8. Logout Actors involved 1) Administrator 2) Passenger Use-case name: login The user enters a username and a password. And if the entered details are valid, the users details are brought to the screen; if they are invalid then an appropriate message is displayed.

Use-case name: Book ticket The user is allowed to book a ticket on the flight he requires and the date and time as is necessary for the user. The user has to provide details such as name, flight number, date of travel, departure time, and can view the price of the ticket. Use-case name: Print ticket

The user after booking a ticket can print a copy of the ticket reserved. The user has to provide the details about ticket number for searching in the database and passenger name for confirming passenger identity. Use-case name: Cancel ticket A passenger can decide to cancel a ticket after the ticket is booked. The passenger has to provide details about ticket for searching and details about him for confirmation of identity. Use-case name: View flight The passenger can view the flights available in the database for deciding which flights ticket he wishes to book. The passenger can view the details of flights such as, flight number, Flight Company, price, departure and arrival times. Use-case name: Add flight Only the administrator has privilege to add flights. The administrator can add the flight on which tickets can be booked by the passengers. The administrator has to provide details about a new flight such as flight number, flight company name, price, departure time, date of travel. Use-case name: Delete flight The administrator also has the privilege to delete flights that are not necessary. The administrator has to provide details about the flight for searching and inform any passengers that have booked tickets on the flight about the change and make necessary arrangements. Use-case name: Logout After the necessary operations have been performed on the system, the user can choose to logout from the system.

SOFTWARE TESTING There are four basic types of testing 1. Black-box testing 2. White-box testing 3. Top-down testing 4. Bottom-up testing

TESTING The extent of testing a system is controlled by many factors, such as the risks involved, limitation on resources, and deadlines. In light of these issues, we must deploy a testing strategy that does the "best" job of finding defects in a product within the given constraints. There are many testing strategies, but most testing uses a combination of these: black box testing, while box testing,top-down testing, and bottom-up testing. However, no strategy or combination of strategies trulycan prove the correctness of a system; it can establish only its "acceptability". BLACK BOX TESTING The concept of the black box is used to represent a system whose inside workings are not available for inspection. In a black box, the test item is treated as "black", since its logic is unknown;all that is known is what does in what comes out, or the input and output. Weinberg describes writing a user manual does not show the internal logic, because the users of the system do not care about what is inside the system. WHITE BOX TESTING White box testing assusmes that the specific logic is important and must be tested to guarantee the system's proper functioning. The main use of the white box is in error-based testing, when you already have tested all objects of an application and all external or public methods of an object that you believe to be of greater importance. In while box testing, you are looking for bugs that have a low probability of execution, have been carelessly implemented, or were overlooked previously. One form of white box testing called path testing, makes certain that each path in an object's method is executed at least once during testing. Two types of path testing are statement testing coverage and branch testing coverage. Statement testing coverage: The main idea of statement testing coverage is to test every statement in the objects method by executing it al least once. Murray states, "testing less than this for new software is unconscionable and should be criminalized". However realistically, it is impossible to test a program on every single input, so you never can be sure that the program will not fail on some input. Branch testing coverage: The main idea of branch testing coverage is to perform enough tests to ensure that every branch alternative has been executed at least once under some test. As is statement testing coverage, it is unfeasible to fully test any program of considerable size.Most debugging tools are excellent in statement and branch testing

coverage. White box testing is useful for error based testing.

TOP-DOWN TESTING Top-down testing assumes that the main logic or object interactions and system messages of the application need more testing that an individual objects methods or supporting logic. A top-down strategy can detect the serious design flaws early in the implementation. In theory, top-down testing should find critical design errors early in the testing process and significantly improve the quality of the delivered software because of the iterative nature of the test. A top-down strategy testing the user interface and event-driven systems. Testing the user interface using a top-down approach means testing interface navigation. This serves two purposes, according to Conger. First, the top-down approach can test the navigation through screens and verify that it matches the requirements. Second, user can see, at an early stage, how the final application will look and feel. This approach also is useful for scenario based testing. Top-down testing is useful to test sub system and system integration. BOTTOM-UP TESTING Bottom-up testing starts with the details of the system and proceeds to higher levels by a progressive aggregation of details until they collectively fir the requirements for the system. Here, you test each object, then combine them and test theri interaction and messages passed among objects by utilizing the top-down approach. In bottom-up testing, you start with methods and classes that call or rely on no others. You test them thoroughly. Then you progress to the next level up; those methods and classes that use only the bottom level ones already tested. Next, you test combination of bottom two layers. Proceed until you are testing the entire program. This strategy makes sense because you are checking the behaviour of a piece of code before it is use by another. Bottom-up testing leads to integration testing,which leads to system testing. VARIOUS OTHER TESTING: Regression Testing: All Passed Tests are repeated with the revised program, which can discover errors introduced during the debugging process. Unit Testing: The test process that is made module by module is known as Unit Testing.

Integration Testing: The test process that can be performed to any module directly without going through all the above modules is known as Integration Testing. System Testing: The test process that is performed after the completion of the whole process is known as System Testing.

Use-case diagram for airline reservation

Class diagram The class diagram is a graphical representation of all the classes used in the system and their operations, attributes and relationships. The online ticket reservation system makes use of the following classes: o Ticket system

o Flight details o Ticket Ticket system It consists of two attributes and two operations. The attributes are username and password. The operations used are login () and logout (). Flight details It stores the details of all the flights such as flight number, Flight Company, flight capacity, and cost. The operations available are add (), delete () and view (). Ticket It records the details of every ticket booked such as ticket number, passenger name, and flight number, from place, to place, date of travel, departure time, arrival time, and price. The operations available are add (), delete (), view (), and print ().

Class diagram for airline reservation system

Sequence diagram A sequence diagram represents the sequence and interactions of a given usecase or scenario. Sequence diagrams can capture most of the information about the

system. Most object-to-object interactions and operations are considered events and events include signals, inputs, decisions, interrupts, transitions and actions to or from users or external devices. An event also is considered to be any action by an object that sends information. The event line represents a message from one object to another, in which the from object is requesting an operation be performed by the to object. The to object performs the operation using a method that the class contains. It is also represented by the order in which things occur and how the objects in the system send message to one another. The sequence diagram for each use-case that exists when a user logs in, adds, views, updates or deletes records in the system.

Sequence and collaboration diagram for adding a flight

The Administrator has the privilege to add flight. He has to provide details about the new flight that is being created in the database.

Sequence and collaboration diagram for booking a ticket

A passenger can book a ticket by himself. He can view the flight details he wants to book a ticket on and as per his necessity may book an appropriate ticket.

Sequence and collaboration diagram for canceling a ticket

Canceling a ticket can be performed by the passenger himself. He may view the ticket he wants and cancel it.

Sequence and collaboration diagram for deleting a flight

A flight can be deleted only by the administrator. The flight to be deleted is selected and removed from the database.

Sequence and collaboration diagram for printing a ticket

The passenger may choose to print a ticket after booking a ticket. The ticket which is booked is selected and printed by the passenger.

Activity Diagram for Airline Ticket Reservation System:

Login

Book the ticket Add flight Delete the ticket Delete flight View the flight Print the ticket

Logout

State Chart Diagram for Airline Ticket Reservation System:

T ic k e t flig h t e ve n t B o o k / B o o k th e v e n t C e a v n e c n e t l V/ Ci e a w n / c V e e v e n t P r in t / P r in t t h e S ta rt e n try / L o g in F lig h t 1 e v e n t A d d / A d d t h e fli g h t e v e n t D e le te / D e le t e t h e fl E n d e x it / L o g o u e t ic k il e t wh e t tic k e

Ticket System code: // Source file: java/ticket_system.java

package java; import flight_details; public class ticket_system extends flight_details { private string username; private string password; ticket_system() { } /** @roseuid 4CA17884025F */ public void log_in() { } /** @roseuid 4CA1788901B2 */ public void log_out() { } } Ticket code: // Source file: java/ticket_system.java package java; import flight_details; public class ticket_system extends flight_details { private string username; private string password; ticket_system() { } /** @roseuid 4CA17884025F */ public void log_in() { } /** @roseuid 4CA1788901B2 */ public void log_out() {

} } Flight_details: // Source file: flight_details.java public class flight_details { private integer flight_no; private string flight_company; private integer flight_capacity; private integer flight_cost; flight_details() { } }

RESULT: Thus the documentation for airline reservation system is created. The output is verified. Ex. NO.: Course Registration System DATE: Aim To create a system through which students can register to the courses desired by them.

Problem statement The system is built to be used by students and managed by an administrator. The student and employee have to login to the system before any processing can be done. The student can see the courses available to him and register to the course he wants. The administrator can maintain the course details and view all the students who have registered to any course. System requirements Microsoft visual basic 6.0 is used as the front end of our project and ms-access as the back end. Use-case diagram The course registration system has the following use-cases Login View course details Registration Display details Maintain course details Logout The actors involved in the system are 1. Student 2. Administrator Use-case name: Login The user enters the username and password and chooses if the user is student or administrator. If entered details are valid, the users account becomes available. If it is invalid, an appropriate message is displayed to the user.

Use-case name: View course details In this use case, a student can search all the courses available to him and choose the best course he wants. The student can view the course duration, faculty and department of the courses he may choose. Use-case name: Registration When a student has successfully chosen a course, he can register to that course. Upon registration, the students details are stored in the database.

Use-case name: Display details After registration to any course, the student may see the details of his current course. He may wish to know details about fees and other information. The administrator also has the privilege to display details of the the students and the corresponding course for which they have registered. Use-case name: Maintain course details The administrator has to perform the duties of maintaining the course details. Any change to the course structure is maintained by the administrator. Use-case name: Logout After all the desired transactions are made, the user may choose to logout from the system to save all he changes they have made. SOFTWARE TESTING There are four basic types of testing 1. Black-box testing 2. White-box testing 3. Top-down testing 4. Bottom-up testing

TESTING The extent of testing a system is controlled by many factors, such as the risks involved, limitation on resources, and deadlines. In light of these issues, we must deploy a testing strategy that does the "best" job of finding defects in a product within the given constraints. There are many testing strategies, but most testing uses a combination of these: black box testing, while box testing,top-down testing, and bottom-up testing. However, no strategy or combination of strategies trulycan prove the correctness of a system; it can establish only its "acceptability". BLACK BOX TESTING The concept of the black box is used to represent a system whose inside workings are not available for inspection. In a black box, the test item is treated as "black", since its logic is unknown;all that is known is what does in what comes out, or the input and output. Weinberg describes writing a user manual does not show the internal logic, because the users of the system do not care about what is inside the system. WHITE BOX TESTING

White box testing assusmes that the specific logic is important and must be tested to guarantee the system's proper functioning. The main use of the white box is in error-based testing, when you already have tested all objects of an application and all external or public methods of an object that you believe to be of greater importance. In while box testing, you are looking for bugs that have a low probability of execution, have been carelessly implemented, or were overlooked previously. One form of white box testing called path testing, makes certain that each path in an object's method is executed at least once during testing. Two types of path testing are statement testing coverage and branch testing coverage. Statement testing coverage: The main idea of statement testing coverage is to test every statement in the objects method by executing it al least once. Murray states, "testing less than this for new software is unconscionable and should be criminalized". However realistically, it is impossible to test a program on every single input, so you never can be sure that the program will not fail on some input. Branch testing coverage: The main idea of branch testing coverage is to perform enough tests to ensure that every branch alternative has been executed at least once under some test. As is statement testing coverage, it is unfeasible to fully test any program of considerable size.Most debugging tools are excellent in statement and branch testing coverage. White box testing is useful for error based testing. TOP-DOWN TESTING Top-down testing assumes that the main logic or object interactions and system messages of the application need more testing that an individual objects methods or supporting logic. A top-down strategy can detect the serious design flaws early in the implementation. In theory, top-down testing should find critical design errors early in the testing process and significantly improve the quality of the delivered software because of the iterative nature of the test. A top-down strategy testing the user interface and event-driven systems. Testing the user interface using a top-down approach means testing interface navigation. This serves two purposes, according to Conger. First, the top-down approach can test the navigation through screens and verify that it matches the requirements. Second, user can see, at an early stage, how the final application will look and feel. This approach also is useful for scenario based testing. Top-down testing is useful to test sub system and system integration. BOTTOM-UP TESTING Bottom-up testing starts with the details of the system and proceeds to higher levels by a progressive aggregation of details until they collectively fir the requirements for the system. Here, you test each object, then combine them and test theri interaction and messages passed among objects by utilizing the top-down

approach. In bottom-up testing, you start with methods and classes that call or rely on no others. You test them thoroughly. Then you progress to the next level up; those methods and classes that use only the bottom level ones already tested. Next, you test combination of bottom two layers. Proceed until you are testing the entire program. This strategy makes sense because you are checking the behaviour of a piece of code before it is use by another. Bottom-up testing leads to integration testing,which leads to system testing. VARIOUS OTHER TESTING: Regression Testing: All Passed Tests are repeated with the revised program, which can discover errors introduced during the debugging process. Unit Testing: The test process that is made module by module is known as Unit Testing. Integration Testing: The test process that can be performed to any module directly without going through all the above modules is known as Integration Testing. System Testing: The test process that is performed after the completion of the whole process is known as System Testing.

Use-case diagram for course registration system

Class diagram

The class diagram is a graphical representation of all the classes used in the system and their operations, attributes and relationships. The course registration system makes use of the following classes: 1. Stud(student details) 2. Administrator 1) Stud It consists of the details of all the students present in the database. The attributes present in this class are student id, password, name, age, sex, course and attendance. The object of this class is created as soon as the student registers to a course. The operations available to this class are login (), logout (), confirmation (), register (), and view course details (). 2) Administrator It consists of details of all the courses available to the student. The attributes present in this class are username, password, course fees, fees due, marks, and attendance. The operations available to this class are login (), logout (), ma course details (), display course (), and confirmation ().

Class diagram for course registration system

Sequence diagram

A sequence diagram represents the sequence and interactions of a given usecase or scenario. Sequence diagrams can capture most of the information about the system. Most object-to-object interactions and operations are considered events and events include signals, inputs, decisions, interrupts, transitions and actions to or from users or external devices. An event also is considered to be any action by an object that sends information. The event line represents a message from one object to another, in which the from object is requesting an operation be performed by the to object. The to object performs the operation using a method that the class contains. It is also represented by the order in which things occur and how the objects in the system send message to one another. The sequence diagram for each use-case that exists when a user logs in, adds, views, updates or deletes records in the system.

Sequence and collaboration diagram for login to the system

Users have to first login to the system before performing any operation. The user has to provide the necessary details to the system for login.

Sequnce and collabaration diagram for logout

When the necessary operations have been performed on the system, the user may choose to save the changes and logout from the system.

Sequence and collabaration diagram for registration to a course

After login, the student has to register to a course of his choice. The student can view all the courses available to him and register to a course suitable to him. The student may view the course details before registration.

Sequence and collaboration diagram for viewing course details

A student may wish to view course details before registration. For this, the student has to first login and select the course details he wishes to see.

Sequence and collaboration diagram for maintaining course details

Course details may be changed as per the requirement every year. So the administrator can edit the details of the course as necessary.

Activity Diagram for Course Registration System:

State Chart Diagram for Course Registration System:

Administrator code: // Source file: Administrator.java public class Administrator { private integer userid; private string passwd; private integer coursefees; private string feesdue; private integer marks; private integer attendence; Administrator() { } /** @roseuid 4CA16E8D004B */

public void login() { } /** @roseuid 4CA16E90025F */ public void logout() { } /** @roseuid 4CA16E9303E6 */ public void macourse_details() { } /** @roseuid 4CA16E9B01B3 */ public void display_course() { } /** @roseuid 4CA16EA4024A */ public void conformation() { } } Student code: // Source file: java/stud.java package java; import Administrator; public class stud extends Administrator { private integer sid; private string passwd; private int age; private string sex; private string course; private integer attendence; stud() { } /** @roseuid 4CA16D9D00A1 */

public void logon() { } /** @roseuid 4CA16DA0019B */ public void logout() { } /** @roseuid 4CA16DA40092 */ public void conformation() { } /** @roseuid 4CA16DAA0025 */ public void register() { } /** @roseuid 4CA16DAD012F */ public void viewcourse_details() { } }

RESULT: Thus the documentation for course registration system is created. The output is verified. EX. NO.: QUIZ SYSTEM DATE: AIM: To design a quiz system by using case tools and generate code using java. HARDWARE AND SOFTWARE REQUIREMENTS:

Pentium 4 processor 128 MB RAM 40 GB Hard disk Rational Rose Enterprise Edition

PROGRAM ANALYSIS AND PROJECT PLANNING: In this quiz system 3 actors namely participant, compirer and audience are used. A database is maintained about the details about the participants and their score details. The compirer ask the questionw to a participant. The participant answer the question or passes it. Scores are allotted based on either the participant answers or passes it. DATA MODELING: Use case diagram: In the use case diagram, actors and the various activities among them are initialized. Its used for visualizing the use case. It comprised of use cases and actors. Actors: An actor is a role that an user plays with respect to the system. He can also play more than one role. An actor can also be an external system that needs some information from the current system. The actors used in this system are patients, expert systems and medical database. USE CASE: An use case is a scenario tied together by a common user goal. An use case diagram displays the relationship among actors and use cases. An use case is an external view of a system that represents some action, the user might perform in order to complete the task. The use case in the quiz system are: Register for name: The participant registers their name for the quiz game. Ask Question: The compirer asks question to the participant. Answers question: The participant answers the question or makes a pass to the audience. Keep record of mark: The compirer records the score of the participant. Questions passed to audience: The questions are passed to the audience if the participant does not answer. Calculates the participant score:

The compirer calculates the participant score and determines if the participant wins or loses a game. SOFTWARE TESTING There are four basic types of testing 1. Black-box testing 2. White-box testing 3. Top-down testing 4. Bottom-up testing TESTING The extent of testing a system is controlled by many factors, such as the risks involved, limitation on resources, and deadlines. In light of these issues, we must deploy a testing strategy that does the "best" job of finding defects in a product within the given constraints. There are many testing strategies, but most testing uses a combination of these: black box testing, while box testing,top-down testing, and bottom-up testing. However, no strategy or combination of strategies trulycan prove the correctness of a system; it can establish only its "acceptability". BLACK BOX TESTING The concept of the black box is used to represent a system whose inside workings are not available for inspection. In a black box, the test item is treated as "black", since its logic is unknown;all that is known is what does in what comes out, or the input and output. Weinberg describes writing a user manual does not show the internal logic, because the users of the system do not care about what is inside the system. WHITE BOX TESTING White box testing assusmes that the specific logic is important and must be tested to guarantee the system's proper functioning. The main use of the white box is in error-based testing, when you already have tested all objects of an application and all external or public methods of an object that you believe to be of greater importance. In while box testing, you are looking for bugs that have a low probability of execution, have been carelessly implemented, or were overlooked previously. One form of white box testing called path testing, makes certain that each path in an object's method is executed at least once during testing. Two types of path testing are statement testing coverage and branch testing coverage. Statement testing coverage: The main idea of statement testing coverage is to test every statement in the objects method by executing it al least once. Murray states, "testing less than this for new software is unconscionable and should be criminalized". However realistically, it is impossible to test a program on every single input, so you never can be sure that the

program will not fail on some input. Branch testing coverage: The main idea of branch testing coverage is to perform enough tests to ensure that every branch alternative has been executed at least once under some test. As is statement testing coverage, it is unfeasible to fully test any program of considerable size.Most debugging tools are excellent in statement and branch testing coverage. White box testing is useful for error based testing. TOP-DOWN TESTING Top-down testing assumes that the main logic or object interactions and system messages of the application need more testing that an individual objects methods or supporting logic. A top-down strategy can detect the serious design flaws early in the implementation. In theory, top-down testing should find critical design errors early in the testing process and significantly improve the quality of the delivered software because of the iterative nature of the test. A top-down strategy testing the user interface and event-driven systems. Testing the user interface using a top-down approach means testing interface navigation. This serves two purposes, according to Conger. First, the top-down approach can test the navigation through screens and verify that it matches the requirements. Second, user can see, at an early stage, how the final application will look and feel. This approach also is useful for scenario based testing. Top-down testing is useful to test sub system and system integration. BOTTOM-UP TESTING Bottom-up testing starts with the details of the system and proceeds to higher levels by a progressive aggregation of details until they collectively fir the requirements for the system. Here, you test each object, then combine them and test theri interaction and messages passed among objects by utilizing the top-down approach. In bottom-up testing, you start with methods and classes that call or rely on no others. You test them thoroughly. Then you progress to the next level up; those methods and classes that use only the bottom level ones already tested. Next, you test combination of bottom two layers. Proceed until you are testing the entire program. This strategy makes sense because you are checking the behaviour of a piece of code before it is use by another. Bottom-up testing leads to integration testing,which leads to system testing. VARIOUS OTHER TESTING: Regression Testing: All Passed Tests are repeated with the revised program, which can discover errors introduced during the debugging process.

Unit Testing: The test process that is made module by module is known as Unit Testing. Integration Testing: The test process that can be performed to any module directly without going through all the above modules is known as Integration Testing. System Testing: The test process that is performed after the completion of the whole process is known as System Testing.

Use Case diagram

Register

Compitete Compirer Central Computer

participant

Lose

W in Audience Ask Question

Class diagram
CentralSystemManagement mark : int participant Name : string registration() calculation() CentralSystemManagement()

Contestant name : string place : string gameResult : string register() compute() contestant()

Compirers namelist : string question : string answer : string askquestion() keepsmark() compirers()

Audiences name : string place : string answering() watching() Audiences()

Sequence diagram:

central system : participant : Audience : Compirer

1: register for name 2: Ask Question

3: Answer the question 4: keeps record of scores 5. Ask question

6. No answer 7. Question passed on to audience 8: Answer the question

9: Gets compliment

10: Calculate participant score 11: Sends score

12: Won the game

13: Lose the game

Collaboration diagram:

1: register for name 6: no answer

participant

7: question passed on to audience 2: ask questions 11: won the game 12: lose the game 9: gets complement 3: answer the questions 5: ask questions

audience

10: calculate the participant score 8: answer the question 4: keep record of score compirer central system

Activity diagram:

Login Check whether choosen opted game Yes Enter the game Register

Select correct game

NO

Enter the quiz If answered No Yes Marks get added Check high score Lose the game No Yes Won the game If answered No Yes Get compliments Say Pass

Audience

// Source file: CentralSystemManagement.java public class CentralSystemManagement { private int mark; private String participantName; CentralSystemManagement() { } /** @roseuid 4CB2D9CB02B2 */ public void registration() { } /** @roseuid 4CB2D9D1008E */ public void calculation() { }

/** @roseuid 4CB2D9D7011A */ public CentralSystemManagement() { } } // Source file: Contestant.java public class Contestant { private string name; private string place; private string gameResult; Contestant() { } /** @roseuid 4CB2DA7A02A8 */ public void register() { } /** @roseuid 4CB2DA7D00A4 */ public void compute() { } /** @roseuid 4CB2DA7F03A1 */ public void contestant() { } } // Source file: compirers.java public class compirers { private string namelist; private string question; private string answer; compirers() { } /** @roseuid 4CB2DAD00395 */ public void askquestion() {

} /** @roseuid 4CB2DAD703C3 */ public void keepsmark() { } /** @roseuid 4CB2DADE0170 */ public compirers() { } } // Source file: Audience.java public class Audience { private string name; private string place; Audience() { } /** @roseuid 4CB2DB1400CC */ public void answering() { } /** @roseuid 4CB2DB180010 */ public void watching() { } /** @roseuid 4CB2DB1A0204 */ public void audiences() { } }

RESULT: Thus the documentation for quiz registration system is created. The output is verified. EX. NO.: EXPERT SYSTEM DATE: AIM: To design a expert system by using case tools and generate code using java. Software requirements: Microsoft Visual Basic 6.0 is used as front- end for our project and MSAccess is used as back-end to store the data. PROGRAM ANALYSIS AND PROJECT PLANNING: The medical organization wants to automate treatment system based on symptoms which will reduce the time taken for treating the patient. All the

information about the various symptoms and corresponding medicines is stored in the medical database. The new system that will be created will use the medical database for information. Patients at various locations are allowed to access in medical database. The system will be developed will be distributed systems so the performance of the system during the peak time will be critical for the screen. Hence patients contact online with the expert system. He forwarded this symptoms to the experts system. This expert system contact with medical database contains prescription and medical database. DATA MODELING: i. Use case Diagram: In the use case diagram, actors and the various activities among them are initialized. Its used for visualizing the use case. It comprised of use cases and actors. Actors: An actor is a role that an user plays with respect to the system. He can also play more than one role. An actor can also be an external system that needs some information from the current system. The actors used in this system are patients, expert systems and medical database. USE CASE: An use case is a scenario tied together by a common user goal. An use case diagram displays the relationship among actors and use cases. An use case is an external view of a system that represents some action, the user might perform in order to complete the task. The use case in the expert system are: a. Symptoms: Symptoms of the patients are specified. b. Pharmacy: The specified medicines are provided. c. Prescriptions: Prescriptions are specified for the particular disease. SEQUENCE DIAGRAM: The flow of activities in which step-by-step process is called sequence diagram. In this stock maintenance system the flow of activities are: request for planning, enter the product name, check for availability, product available, request available, enter quantity, required quantity, order confirmed, enter product details, request product details, product details provided, display the product details. COLLABORATION DIAGRAM

In this sequence is indicated by numbering the message. Numbering the message makes it more difficult to see the sequence in order. After the completion of sequence diagram, by pressing the F5 key the collaboration diagram get automatically generated. SOFTWARE TESTING There are four basic types of testing 1. Black-box testing 2. White-box testing 3. Top-down testing 4. Bottom-up testing TESTING The extent of testing a system is controlled by many factors, such as the risks involved, limitation on resources, and deadlines. In light of these issues, we must deploy a testing strategy that does the "best" job of finding defects in a product within the given constraints. There are many testing strategies, but most testing uses a combination of these: black box testing, while box testing,top-down testing, and bottom-up testing. However, no strategy or combination of strategies trulycan prove the correctness of a system; it can establish only its "acceptability". BLACK BOX TESTING The concept of the black box is used to represent a system whose inside workings are not available for inspection. In a black box, the test item is treated as "black", since its logic is unknown;all that is known is what does in what comes out, or the input and output. Weinberg describes writing a user manual does not show the internal logic, because the users of the system do not care about what is inside the system. WHITE BOX TESTING White box testing assusmes that the specific logic is important and must be tested to guarantee the system's proper functioning. The main use of the white box is in error-based testing, when you already have tested all objects of an application and all external or public methods of an object that you believe to be of greater importance. In while box testing, you are looking for bugs that have a low probability of execution, have been carelessly implemented, or were overlooked previously. One form of white box testing called path testing, makes certain that each path in an object's method is executed at least once during testing. Two types of path testing are statement testing coverage and branch testing coverage. Statement testing coverage: The main idea of statement testing coverage is to test every statement in the

objects method by executing it al least once. Murray states, "testing less than this for new software is unconscionable and should be criminalized". However realistically, it is impossible to test a program on every single input, so you never can be sure that the program will not fail on some input. Branch testing coverage: The main idea of branch testing coverage is to perform enough tests to ensure that every branch alternative has been executed at least once under some test. As is statement testing coverage, it is unfeasible to fully test any program of considerable size.Most debugging tools are excellent in statement and branch testing coverage. White box testing is useful for error based testing. TOP-DOWN TESTING Top-down testing assumes that the main logic or object interactions and system messages of the application need more testing that an individual objects methods or supporting logic. A top-down strategy can detect the serious design flaws early in the implementation. In theory, top-down testing should find critical design errors early in the testing process and significantly improve the quality of the delivered software because of the iterative nature of the test. A top-down strategy testing the user interface and event-driven systems. Testing the user interface using a top-down approach means testing interface navigation. This serves two purposes, according to Conger. First, the top-down approach can test the navigation through screens and verify that it matches the requirements. Second, user can see, at an early stage, how the final application will look and feel. This approach also is useful for scenario based testing. Top-down testing is useful to test sub system and system integration. BOTTOM-UP TESTING Bottom-up testing starts with the details of the system and proceeds to higher levels by a progressive aggregation of details until they collectively fir the requirements for the system. Here, you test each object, then combine them and test theri interaction and messages passed among objects by utilizing the top-down approach. In bottom-up testing, you start with methods and classes that call or rely on no others. You test them thoroughly. Then you progress to the next level up; those methods and classes that use only the bottom level ones already tested. Next, you test combination of bottom two layers. Proceed until you are testing the entire program. This strategy makes sense because you are checking the behaviour of a piece of code before it is use by another. Bottom-up testing leads to integration testing,which leads to system testing. VARIOUS OTHER TESTING: Regression Testing:

All Passed Tests are repeated with the revised program, which can discover errors introduced during the debugging process. Unit Testing: The test process that is made module by module is known as Unit Testing. Integration Testing: The test process that can be performed to any module directly without going through all the above modules is known as Integration Testing. System Testing: The test process that is performed after the completion of the whole process is known as System Testing. Use case Diagram:

Expert system

Medical DB

patient

Pharmacy Prescription symptoms

Class diagram:

Patients Symptoms : String checking() patients()

Expert_system premedicine : String disease : String symptoms : String medical db() prescription() expert_system()

medical_db price : Integer medicine_name : String doctor_par() medical_db() Prescriptions medicine_name : String duration : Integer doctor_advice() prescription()

Sequence diagram:

Expert system : patient 1:Maintain 2:Forward symptoms 3:Analysis of symptoms

Medical DB

4:Diseases identified 5:Browse information 6:Prescription identified 7:Prescribe medicine 8:Exit

Collaboration Diagram:
2: Forward symptoms Expert System : patient 7: Prescribe medicine 8: Exit 4: Disease identified 6: Prescription identified Medical DB 1: Maintain 3: Analysis of symptoms 5: Browse information

Activity Diagram:

Connected with the expert system Invading the system Connect to the database Analyse the symptoms Diseases found Prescribed the medicine Information collected

Exit

CODINGS: Expert_system.java // Source file: java/Expert_system.java package java; public class Expert_system { private String premedicine; private String disease; private String symptoms; Expert_system() {

} /** @roseuid 4CAAC3C402CE */ public void medicaldb() { } /** @roseuid 4CAAC3CC0280 */ public void prescription() { } /** @roseuid 4CAAC3D600AB */ public void expert_system() { } } Expert System1.java: // Source file: java/Expert_system.java package java; import medical_db; import Prescriptions; public class Expert_system { private String premedicine; private String disease; private String symptoms; Expert_system() { } /** @roseuid 4CAAC3C402CE */ public void medicaldb() { } /** @roseuid 4CAAC3CC0280 */ public void prescription() { } /**

@roseuid 4CAAC3D600AB */ public void expert_system() { } } Medical_db.java // Source file: medical_db.java public class medical_db { private integer price; private String medicine_name; medical_db() { } /** @roseuid 4CAAC4CE037A */ public void doctor_par() { } /** @roseuid 4CAAC4D900CB */ public medical_db() { } } Patients.java // Source file: Patients.java import java.Expert_system; public class Patients extends Expert_system { private String Symptoms; Patients() { } /** @roseuid 4CAAC441008C */ public void checking() { } /** @roseuid 4CAAC44502EE

*/ public void patients() { } } Precriptions.java // Source file: Prescriptions.java public class Prescriptions { private string medicine_name; private integer duration; Prescriptions() { } /** @roseuid 4CAAC55403C8 */ public void doctor_advice() { } /** @roseuid 4CAAC55C0251 */ public void prescription() { } } Expert System2.java: // Source file: java/Expert_system.java package java; import medical_db; public class Expert_system extends medical_db { private string premedicine; private String disease; private string symptoms; Expert_system() { } /** @roseuid 4CAAC7E70222 */ public void medicaldb() { }

/** @roseuid 4CAAC7EF02BF */ public void prescription() { } /** @roseuid 4CAAC7F600EA */ public void expert_system() { } }

RESULT: Thus the documentation for expert system is created. The output is verified.

EX. NO.: DATE: AIM:

STOCK MAINTENANCE

To design a stock maintenance system using case tools and generate code using java. HARDWARE AND SOFTWARE REQUIREMENTS: Pentium 4 processor 128 MB RAM 40 GB Hard disk Rational Rose Enterprise Edition

PROGRAM ANALYSIS AND PROJECT PLANNING: In this stock maintenance system, two actors namely customer and inventory system are used. A database of centralized system is maintained which contains user and inventory management system. A user can view his details from user database which contains information such as product name, quality and price. The inventory management system database contains details such as price and quality of items that can be enquired and then ordered.

DATA MODELING: i. Use case Diagram: In the use case diagram, actors and the various activities among them are initialized. Its used for visualizing the use case. It comprised of use cases and actors. Actors: An actor is a role that an user plays with respect to the system. He can also play more than one role. An actor can also be an external system that needs some information from the current system. The actors used in this system are patients, expert systems and medical database. USE CASE: An use case is a scenario tied together by a common user goal. An use case diagram displays the relationship among actors and use cases. An use case is an external view of a system that represents some action, the user might perform in order to complete the task. The use case in the stock maintenance system are: a. Enter product name: Enter the names of product required and its availability is checked. b. Enter quantity: Enter the no. of items required. c. Request product details: The details about the product are required. SEQUENCE DIAGRAM: The flow of activities in which step-by-step process is called sequence diagram. In this stock maintenance system the flow of activities are: request for planning, enter the product name, check for availability, product available, request available, enter quantity, required quantity, order confirmed, enter product details, request product details, product details provided, display the product details. COLLABORATION DIAGRAM In this sequence is indicated by numbering the message. Numbering the message makes it more difficult to see the sequence in order. After the completion of sequence diagram, by pressing the F5 key the collaboration diagram get automatically generated. SOFTWARE TESTING There are four basic types of testing

1. Black-box testing 2. White-box testing 3. Top-down testing 4. Bottom-up testing TESTING The extent of testing a system is controlled by many factors, such as the risks involved, limitation on resources, and deadlines. In light of these issues, we must deploy a testing strategy that does the "best" job of finding defects in a product within the given constraints. There are many testing strategies, but most testing uses a combination of these: black box testing, while box testing,top-down testing, and bottom-up testing. However, no strategy or combination of strategies trulycan prove the correctness of a system; it can establish only its "acceptability". BLACK BOX TESTING The concept of the black box is used to represent a system whose inside workings are not available for inspection. In a black box, the test item is treated as "black", since its logic is unknown;all that is known is what does in what comes out, or the input and output. Weinberg describes writing a user manual does not show the internal logic, because the users of the system do not care about what is inside the system. WHITE BOX TESTING White box testing assusmes that the specific logic is important and must be tested to guarantee the system's proper functioning. The main use of the white box is in error-based testing, when you already have tested all objects of an application and all external or public methods of an object that you believe to be of greater importance. In while box testing, you are looking for bugs that have a low probability of execution, have been carelessly implemented, or were overlooked previously. One form of white box testing called path testing, makes certain that each path in an object's method is executed at least once during testing. Two types of path testing are statement testing coverage and branch testing coverage. Statement testing coverage: The main idea of statement testing coverage is to test every statement in the objects method by executing it al least once. Murray states, "testing less than this for new software is unconscionable and should be criminalized". However realistically, it is impossible to test a program on every single input, so you never can be sure that the program will not fail on some input. Branch testing coverage: The main idea of branch testing coverage is to perform enough tests to ensure that every branch alternative has been executed at least once under some test. As is statement testing coverage, it is unfeasible to fully test any program of considerable size.Most debugging tools are excellent in statement and branch testing

coverage. White box testing is useful for error based testing. TOP-DOWN TESTING Top-down testing assumes that the main logic or object interactions and system messages of the application need more testing that an individual objects methods or supporting logic. A top-down strategy can detect the serious design flaws early in the implementation. In theory, top-down testing should find critical design errors early in the testing process and significantly improve the quality of the delivered software because of the iterative nature of the test. A top-down strategy testing the user interface and event-driven systems. Testing the user interface using a top-down approach means testing interface navigation. This serves two purposes, according to Conger. First, the top-down approach can test the navigation through screens and verify that it matches the requirements. Second, user can see, at an early stage, how the final application will look and feel. This approach also is useful for scenario based testing. Top-down testing is useful to test sub system and system integration. BOTTOM-UP TESTING Bottom-up testing starts with the details of the system and proceeds to higher levels by a progressive aggregation of details until they collectively fir the requirements for the system. Here, you test each object, then combine them and test theri interaction and messages passed among objects by utilizing the top-down approach. In bottom-up testing, you start with methods and classes that call or rely on no others. You test them thoroughly. Then you progress to the next level up; those methods and classes that use only the bottom level ones already tested. Next, you test combination of bottom two layers. Proceed until you are testing the entire program. This strategy makes sense because you are checking the behaviour of a piece of code before it is use by another. Bottom-up testing leads to integration testing,which leads to system testing. VARIOUS OTHER TESTING: Regression Testing: All Passed Tests are repeated with the revised program, which can discover errors introduced during the debugging process. Unit Testing: The test process that is made module by module is known as Unit Testing. Integration Testing:

The test process that can be performed to any module directly without going through all the above modules is known as Integration Testing. System Testing: The test process that is performed after the completion of the whole process is known as System Testing.

Use case diagram

place order

customer inventory system

centralized system

enquiry

Class diagram
Centralized system prodName : string quantity : integer order() enquiry() centralizedsystem()

User prodNo : integer prodName : string price : integer order() enquiry() user()

InventoryMgmtSystem prodNo : integer quantity : integer price : integer order() enquiry() InventoryMgmtSystem()

Sequence diagram

: customer 1: request for planning

Inventory system

Central system

2: enter product name 3: check for availability 4: product available 5: request available 6: enter quality 7: required quantity available 8: order confirmed 9: enter prd details 10: request prod details 11: prd details provided 12: display the prd details

Collaboration diagram

central system : customer

10: request product details 3: check for availability

12: display the prd details 9: enter prd details 8: order confirmed Inventory system

4: product available 7: required quantity available 11: prd details provided

1: request for planning 2: enter product name 5: request available 6: enter quantity

Activity Diagram:

enter the option

no yes enter product name

if required

enter alternate name

no

if available yes enter the quantity

place the order

Get the product

CODING: CentralizedSystem.java // Source file: java/CentralizedSystem.java package java; public class CentralizedSystem { private string prodName; private integer quantity; CentralizedSystem() {

} /** @roseuid 4CAABFCF0177 */ public void order() { } /** @roseuid 4CAABFD2033C */ public void enquiry() { } /** @roseuid 4CAABFD70232 */ public CentralizedSystem() { } } InventoryMgmtSystem.java // Source file: InventoryMgmtSystem.java import java.CentralizedSystem; public class InventoryMgmtSystem extends CentralizedSystem { private integer prodNo; private integer quantity; private integer price; InventoryMgmtSystem() { } /** @roseuid 4CAAC184038A */ public void order() { } /** @roseuid 4CAAC1880196 */ public void enquiry() { } /** @roseuid 4CAAC18D006D */ public InventoryMgmtSystem() {

} } User.java // Source file: User.java import java.CentralizedSystem; public class User extends CentralizedSystem { private integer prodNo; private string prodName; private integer price; User() { } /** @roseuid 4CAAC0A1007D */ public void order() { } /** @roseuid 4CAAC0A40119 */ public void enquiry() { } /** @roseuid 4CAAC0A8031C */ public User() { } } CentralizedSystem.java // Source file: User.java import java.CentralizedSystem; public class User extends CentralizedSystem { private integer prodNo; private string prodName; private integer price; User() { }

/** @roseuid 4CAAC0A1007D */ public void order() { } /** @roseuid 4CAAC0A40119 */ public void enquiry() { } /** @roseuid 4CAAC0A8031C */ public User() { } }

RESULT: Thus the documentation for stock maintenance system is created. The output is verified.

EX. NO.: DATE:

LIBRARY SYSTEM

AIM: To design a library system by using case tools and generate code using java. HARDWARE AND SOFTWARE REQUIREMENTS: Pentium 4 processor 128 MB RAM 40 GB Hard disk Rational Rose Enterprise Edition

PROGRAM ANALYSIS AND PROJECT PLANNING: This system will enable a student to get books based whether they have a library card or membership. The librarian would first check whether the card is valid or not and then the validity of the card and if valid then the required book is issued and the process repeats again. DATA MODELING: i. Use case Diagram: In the use case diagram, actors and the various activities among them are initialized. Its used for visualizing the use case. It comprised of use cases and actors. Actors: An actor is a role that an user plays with respect to the system. He can also play more than one role. An actor can also be an external system that needs some information from the current system. The actors used in this system are patients, expert systems and medical database. USE CASE: An use case is a scenario tied together by a common user goal. An use case diagram displays the relationship among actors and use cases. An use case is an external view of a system that represents some action, the user might perform in order to complete the task. The use case in the library system are: 1. Issue This is used to issue the book to the customer. 2. Membership Enables member to get the books from library. 3. Validity Checks whether the card is valid or not. 4. Issue book Issues the book to the student. 5. Renewal

Renews the book and extends the period. 6. Return Deletes the record details of the book from the database. 7. Fine Gets the fine when the book returned after the due date. SEQUENCE DIAGRAM: The flow of activities in which step-by-step process is called sequence diagram. In this stock maintenance system the flow of activities are: request for planning, enter the product name, check for availability, product available, request available, enter quantity, required quantity, order confirmed, enter product details, request product details, product details provided, display the product details. COLLABORATION DIAGRAM In this sequence is indicated by numbering the message. Numbering the message makes it more difficult to see the sequence in order. After the completion of sequence diagram, by pressing the F5 key the collaboration diagram get automatically generated. SOFTWARE TESTING There are four basic types of testing 1. Black-box testing 2. White-box testing 3. Top-down testing 4. Bottom-up testing TESTING The extent of testing a system is controlled by many factors, such as the risks involved, limitation on resources, and deadlines. In light of these issues, we must deploy a testing strategy that does the "best" job of finding defects in a product within the given constraints. There are many testing strategies, but most testing uses a combination of these: black box testing, while box testing,top-down testing, and bottom-up testing. However, no strategy or combination of strategies trulycan prove the correctness of a system; it can establish only its "acceptability". BLACK BOX TESTING The concept of the black box is used to represent a system whose inside workings are not available for inspection. In a black box, the test item is treated as "black", since its logic is unknown;all that is known is what does in what comes out, or the input and output. Weinberg describes writing a user manual does not show the

internal logic, because the users of the system do not care about what is inside the system. WHITE BOX TESTING White box testing assusmes that the specific logic is important and must be tested to guarantee the system's proper functioning. The main use of the white box is in error-based testing, when you already have tested all objects of an application and all external or public methods of an object that you believe to be of greater importance. In while box testing, you are looking for bugs that have a low probability of execution, have been carelessly implemented, or were overlooked previously. One form of white box testing called path testing, makes certain that each path in an object's method is executed at least once during testing. Two types of path testing are statement testing coverage and branch testing coverage. Statement testing coverage: The main idea of statement testing coverage is to test every statement in the objects method by executing it al least once. Murray states, "testing less than this for new software is unconscionable and should be criminalized". However realistically, it is impossible to test a program on every single input, so you never can be sure that the program will not fail on some input. Branch testing coverage: The main idea of branch testing coverage is to perform enough tests to ensure that every branch alternative has been executed at least once under some test. As is statement testing coverage, it is unfeasible to fully test any program of considerable size.Most debugging tools are excellent in statement and branch testing coverage. White box testing is useful for error based testing. TOP-DOWN TESTING Top-down testing assumes that the main logic or object interactions and system messages of the application need more testing that an individual objects methods or supporting logic. A top-down strategy can detect the serious design flaws early in the implementation. In theory, top-down testing should find critical design errors early in the testing process and significantly improve the quality of the delivered software because of the iterative nature of the test. A top-down strategy testing the user interface and event-driven systems. Testing the user interface using a top-down approach means testing interface navigation. This serves two purposes, according to Conger. First, the top-down approach can test the navigation through screens and verify that it matches the requirements. Second, user can see, at an early stage, how the final application will look and feel. This approach also is useful for scenario based testing. Top-down testing is useful to test sub system and system integration. BOTTOM-UP TESTING

Bottom-up testing starts with the details of the system and proceeds to higher levels by a progressive aggregation of details until they collectively fir the requirements for the system. Here, you test each object, then combine them and test theri interaction and messages passed among objects by utilizing the top-down approach. In bottom-up testing, you start with methods and classes that call or rely on no others. You test them thoroughly. Then you progress to the next level up; those methods and classes that use only the bottom level ones already tested. Next, you test combination of bottom two layers. Proceed until you are testing the entire program. This strategy makes sense because you are checking the behaviour of a piece of code before it is use by another. Bottom-up testing leads to integration testing,which leads to system testing. VARIOUS OTHER TESTING: Regression Testing: All Passed Tests are repeated with the revised program, which can discover errors introduced during the debugging process. Unit Testing: The test process that is made module by module is known as Unit Testing. Integration Testing: The test process that can be performed to any module directly without going through all the above modules is known as Integration Testing. System Testing: The test process that is performed after the completion of the whole process is known as System Testing. Use case diagram

central system : customer

10: request product details 3: check for availability

12: display the prd details 9: enter prd details 8: order confirmed Inventory system

4: product available 7: required quantity available 11: prd details provided

1: request for planning 2: enter product name 5: request available 6: enter quantity

Class diagram

Library pin no : int no of books : int book name : char data : int fine : int author : char codeno : int validity() issuebook() return() student() details()

validity pin np : int check validity()

Book issue no of books : int book name : char chech no of books() issue books()

book return date : int fine : int check date() return book()

students name : char dept : char year : int b code no : int display student()

detail book name : char author : char b code no : int display det()

Sequence diagram

library : student

validity

issue

return

: librarian

1: pin no 2: check pin 3: no 4: validate password

5: get valid pin 6: yes 7: check no of books 8: no 9: book issue 10: yes 11: check date 12: pay the fine 13: book return 14: renewal

Collaboration diagram

5: get valid pin

1: pin no library 9: book issue 11: check date 6: yes 12: pay the fine 2: check pin 3: no validity

: student

7: check no of books

8: no 10: yes

4: validate password 14: renewal

13: book return

issue

return : librarian

Activity diagram

student come to lib no member yes allow in the library search book

disallow

book available yes issue book

no

return

renewal no

if extends due date yes

Pay fine

Exit

CODING: Librarybase: // Source file: Library.java public class Library { private int pin_no; private int no_of_books; private char book_name; private int data; private int fine; private char author; private int code_no; Library() { }

/** @roseuid 4CAAC37A0222 */ public void validity() { } /** @roseuid 4CAAC3870000 */ public void issuebook() { } /** @roseuid 4CAAC38B0128 */ public void return() { } /** @roseuid 4CAAC390000F */ public void student() { } /** @roseuid 4CAAC3930203 */ public void details() { } } Details: // Source file: detail.java public class detail extends Library { private char book_name; private char author; private int b_code_no; detail() { } /** @roseuid 4CAAC571038A */ public void display_det() { } } Students:

// Source file: students.java public class students extends Library { private char name; private char dept; private int year; private int b_code_no; students() { } /** @roseuid 4CAAC52902EE */ public void display_student() { } } Book_issue: // Source file: book_issue.java public class book_issue extends Library { private int no_of_books; private char book_name; book_issue() { } /** @roseuid 4CAAC3E2033C */ public void check_no_of_books() { } /** @roseuid 4CAAC3EE0000 */ public void issue_book() { } } Book_return: // Source file: book_return.java public class book_return extends Library { private int date; private int fine; book_return() {

} /** @roseuid 4CAAC46D01B5 */ public void check_date() { } /** @roseuid 4CAAC47302FD */ public void return_book() { } } Validity: // Source file: validity.java public class validity { private int pin_np; validity() { } /** @roseuid 4CAAC75F009C */ public void check_validity() { } }

RESULT: Thus the documentation for library system is created. The output is verified. EX. NO.: REMOTE PROCEDURE CALL IMPLEMENTATION DATE: AIM: To design a remote procedure call system by using case tools and generate code using java. HARDWARE AND SOFTWARE REQUIREMENTS: Pentium 4 processor 128 MB RAM 40 GB Hard disk Rational Rose Enterprise Edition

PROGRAM ANALYSIS AND PROJECT PLANNING: The new system will allow user to open as many E-mail as they wish. During the creation of new ID, the system asks for a name as ID and a password. The id must be unique. After creation of id, the user will be access his emails only after, he enter the correct id and password. In and e-mail system, a person can check mails, send mails, reply mails and get economy messages from and sending outgoing messages to a mail server. DATA MODELING:

Use case diagram: In the use case diagram, actors and the various activities among them are initialized. Its used for visualizing the use case. It comprised of use cases and actors. Actors: An actor is a role that an user plays with respect to the system. He can also play more than one role. An actor can also be an external system that needs some information from the current system. The actors used in this system are patients, expert systems and medical database. USE CASE: An use case is a scenario tied together by a common user goal. An use case diagram displays the relationship among actors and use cases. An use case is an external view of a system that represents some action, the user might perform in order to complete the task. The use case in the remote procedure call system are: Mail box Validate Sign I n Inbox Reply Draft Subscribe Outbox

SEQUENCE DIAGRAM: The flow of activities in which step-by-step process is called sequence diagram. In this stock maintenance system the flow of activities are: request for planning, enter the product name, check for availability, product available, request available, enter quantity, required quantity, order confirmed, enter product details, request product details, product details provided, display the product details. COLLABORATION DIAGRAM In this sequence is indicated by numbering the message. Numbering the message makes it more difficult to see the sequence in order. After the completion of sequence diagram, by pressing the F5 key the collaboration diagram get automatically generated. SOFTWARE TESTING There are four basic types of testing 1. Black-box testing

2. White-box testing 3. Top-down testing 4. Bottom-up testing TESTING The extent of testing a system is controlled by many factors, such as the risks involved, limitation on resources, and deadlines. In light of these issues, we must deploy a testing strategy that does the "best" job of finding defects in a product within the given constraints. There are many testing strategies, but most testing uses a combination of these: black box testing, while box testing,top-down testing, and bottom-up testing. However, no strategy or combination of strategies trulycan prove the correctness of a system; it can establish only its "acceptability". BLACK BOX TESTING The concept of the black box is used to represent a system whose inside workings are not available for inspection. In a black box, the test item is treated as "black", since its logic is unknown;all that is known is what does in what comes out, or the input and output. Weinberg describes writing a user manual does not show the internal logic, because the users of the system do not care about what is inside the system. WHITE BOX TESTING White box testing assusmes that the specific logic is important and must be tested to guarantee the system's proper functioning. The main use of the white box is in error-based testing, when you already have tested all objects of an application and all external or public methods of an object that you believe to be of greater importance. In while box testing, you are looking for bugs that have a low probability of execution, have been carelessly implemented, or were overlooked previously. One form of white box testing called path testing, makes certain that each path in an object's method is executed at least once during testing. Two types of path testing are statement testing coverage and branch testing coverage. Statement testing coverage: The main idea of statement testing coverage is to test every statement in the objects method by executing it al least once. Murray states, "testing less than this for new software is unconscionable and should be criminalized". However realistically, it is impossible to test a program on every single input, so you never can be sure that the program will not fail on some input. Branch testing coverage: The main idea of branch testing coverage is to perform enough tests to ensure that every branch alternative has been executed at least once under some test. As is statement testing coverage, it is unfeasible to fully test any program of considerable size.Most debugging tools are excellent in statement and branch testing coverage. White box testing is useful for error based testing.

TOP-DOWN TESTING Top-down testing assumes that the main logic or object interactions and system messages of the application need more testing that an individual objects methods or supporting logic. A top-down strategy can detect the serious design flaws early in the implementation. In theory, top-down testing should find critical design errors early in the testing process and significantly improve the quality of the delivered software because of the iterative nature of the test. A top-down strategy testing the user interface and event-driven systems. Testing the user interface using a top-down approach means testing interface navigation. This serves two purposes, according to Conger. First, the top-down approach can test the navigation through screens and verify that it matches the requirements. Second, user can see, at an early stage, how the final application will look and feel. This approach also is useful for scenario based testing. Top-down testing is useful to test sub system and system integration. BOTTOM-UP TESTING Bottom-up testing starts with the details of the system and proceeds to higher levels by a progressive aggregation of details until they collectively fir the requirements for the system. Here, you test each object, then combine them and test theri interaction and messages passed among objects by utilizing the top-down approach. In bottom-up testing, you start with methods and classes that call or rely on no others. You test them thoroughly. Then you progress to the next level up; those methods and classes that use only the bottom level ones already tested. Next, you test combination of bottom two layers. Proceed until you are testing the entire program. This strategy makes sense because you are checking the behaviour of a piece of code before it is use by another. Bottom-up testing leads to integration testing,which leads to system testing. VARIOUS OTHER TESTING: Regression Testing: All Passed Tests are repeated with the revised program, which can discover errors introduced during the debugging process. Unit Testing: The test process that is made module by module is known as Unit Testing. Integration Testing: The test process that can be performed to any module directly without going

through all the above modules is known as Integration Testing. System Testing: The test process that is performed after the completion of the whole process is known as System Testing.

subscribe

user

mail service

not a member

sign in

already a number

user account

check mail

account information

inbox

outbox

Class diagram:

User name : string gender : string nation : string userid : string pwd : string details()

Validation userid : string pwd : string valid() subscribe()

Inbox delte : string forward : string reply : string bulk : string move() mark()

Compose text : string addr : string id : string send() delivery rep()

address name : string id : string age : string add() save() remove()

Sequence Diagram
user validate mailbox Inbox Address signout

1: Enter id and password 2: valid pin 3. goto address book 4. return to mailbox

5. open inbox 6. return 7. sign out

Collaboration diagram
1: Enter id and password user validate 2: valid id mailbox 7: sign out

6: return 5: open inbox 4: return to mailbox Address

signout

3: go to address book

Inbox

Activity diagram:

mail service already a member no yes sign in

subscribe

validation

account page

compose

Inbox

sent items

Delete

Reply

Forward

Sign out

CODING: User: // Source file: user.java public class user { private string name; private string gender; private string nation; private string userid; private string pwd;

user() { } /** @roseuid 4CAAA39A00EA */ public void details() { } } Inbox: // Source file: Inbox.java public class Inbox extends validation { private string Delete; private string forward; private string reply; private string bulk; Inbox() { } /** @roseuid 4CAAA6340200 */ public void move() { } /** @roseuid 4CAAA6390155 */ public void mark() { } } Compose: // Source file: compose.java public class compose extends validation { private string text; private string addr; private string id; compose() { } /** @roseuid 4CAAA56B0155 */ public void send() { }

/** @roseuid 4CAAA56F00AA */ public void delivery_rep() { } } Address: // Source file: address.java public class address extends validation { private string name; private string id; private string age; address() { } /** @roseuid 4CAAA66F016C */ public void add() { } /** @roseuid 4CAAA67103BE */ public void save() { } /** @roseuid 4CAAA6740063 */ public void remove() { } } Validation: // Source file: validation.java public class validation extends user { private string userid; private string pwd; validation() { } /** @roseuid 4CAAA3FD02C4

*/ public void valid() { } /** @roseuid 4CAAA4020346 */ public void subscribe() { } }

RESULT: Thus the documentation for remote procedure call system is created. The output is verified.