lab code - mrcet

156
4 LAB CODE 1. Students should report to the concerned lab as per the time table. 2. Students who turn up late to the labs will in no case be permitted to do the program schedule for the day. 3. After completion of the program, certification of the concerned staff in- charge in the observation book is necessary. 4. Student should bring a notebook of 100 pages and should enter the readings /observations into the notebook while performing the experiment. 5. The record of observations along with the detailed experimental procedure of the experiment in the immediate last session should be submitted and certified staff member in-charge. 6. Not more than 3-students in a group are permitted to perform the experiment on the set. 7. The group-wise division made in the beginning should be adhered to and no mix up of students among different groups will be permitted. 8. The components required pertaining to the experiment should be collected from stores in-charge after duly filling in the requisition form. 9. When the experiment is completed, should disconnect the setup made by them, and should return all the components/instruments taken for the purpose. 10. Any damage of the equipment or burn-out components will be viewed seriously either by putting penalty or by dismissing the total group of students from the lab for the semester/year. 11. Students should be present in the labs for total scheduled duration. 12. Students are required to prepare thoroughly to perform the experiment before coming to laboratory. 13. Procedure sheets/data sheets provided to the student‘s groups should be maintained neatly and to be returned after the experiment.

Upload: others

Post on 18-Dec-2021

7 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: LAB CODE - MRCET

4

LAB CODE

1. Students should report to the concerned lab as per the time table.

2. Students who turn up late to the labs will in no case be permitted to do

the program schedule for the day.

3. After completion of the program, certification of the concerned staff in-

charge in the observation book is necessary. 4. Student should bring a notebook of 100 pages and should enter the

readings /observations into the notebook while performing the experiment.

5. The record of observations along with the detailed experimental procedure of the experiment in the immediate last session should be

submitted and certified staff member in-charge. 6. Not more than 3-students in a group are permitted to perform the

experiment on the set.

7. The group-wise division made in the beginning should be adhered to and no mix up of students among different groups will be permitted.

8. The components required pertaining to the experiment should be collected from stores in-charge after duly filling in the requisition form.

9. When the experiment is completed, should disconnect the setup made by them, and should return all the components/instruments taken for the

purpose. 10. Any damage of the equipment or burn-out components will be viewed

seriously either by putting penalty or by dismissing the total group of students from the lab for the semester/year.

11. Students should be present in the labs for total scheduled duration.

12. Students are required to prepare thoroughly to perform the experiment before coming to laboratory.

13. Procedure sheets/data sheets provided to the student‘s groups should be maintained neatly and to be returned after the experiment.

Page 2: LAB CODE - MRCET

5

INDEX

SNO EXPERIMENT

NO. NAME OF THE EXPERIMENT

PAGE NO.

UNIFIED MODELING LANGUAGE

1 1 Introduction of UML CLASS DIAGRAM FOR ATM

11

2 2 Use case diagram for ATM 12

3 3 Sequence diagram for ATM 17

4 4 Collaboration diagram for ATM 19

5 5 State chart diagram for ATM 20

6 6 Activity diagram for ATM 22

7 7 Component diagram 24

8 8 Deployment diagram for ATM 26

SOFTWARE TESTING

9 1 Write a programs in C language in demonstration the working of the following constructs i) do..while ii) while..do iii) if…else iv)switch v) for

28

10 2

―A program for written in C language for Matrix Multiplication fails‖ introspect the causes for its failure and write down the possible reasons for its failure.

32

11 3 Take ATM system and study its system specifications and report various bugs.

34

12 4 Write the test cases for banking application 38

13 5 Create test plan document for library management system

43

14 6 Study of testing tool (e.g. winrunner) 47

15 7 Study of web testing tool (e.g. selenium) 51

16 8 Study of bug tracking tool (e.g. bugzilla) 60

17 9 Study of any test management tool (e.g. test director)

67

18 10 Study of any open source testing tool (e.g. test link)

69

Page 3: LAB CODE - MRCET

6

UNIFIED MODELING LANGUAGE

Introduction

The unified modeling language (UML) is a standard language for writing software blue prints.

The UML is a language for

Visualizing

Specifying

Constructing

Documenting

The artifacts of a software system:

UML is a language that provides vocabulary and the rules for combing words in that vocabulary for the purpose of communication.

A modeling language is a language whose vocabulary and rules focus on the concept and physical representation of a system. Vocabulary and rules of a language tell us how to create and real well formed models, but they don‘t tell you what model you should create and when should create them.

Visualizing

The UML is more than just a bunch of graphical symbols. In UML each symbol has well defined semantics. In this manner one developer can write a model in the UML and another developer or even another tool can interpret the model unambiguously.

SPECIFYING

UML is used fro specifying means building models that are precise, unambiguous and complete. UML addresses the specification of all the important analysis, design and implementation decisions that must be made in developing and deploying a software intensive system.

Constructing :

UML is not a visual programming language but its models can be directly connected to a variety of programming languages. This means that it is possible to map from a model in the UML to a programming language such as java, c++ or Visual Basic or even to tables in a relational database or the persistent store of an object-oriented database. This mapping permits forward engineering. The generation of code from a UML model into a programming language. The reverse engineering is also possible you can reconstruct a model from an implementation back into the UML.

Documenting

UML is a language for Documenting. A software organization produces all sorts of artifacts in addition to raw executable code. These artifacts include Requirements, Architecture, Design, Source code, Project plans, Test, Prototype, and Release. Such artifacts are not only the deliverables of a project, they are also critical in controlling, measuring and communicating about a system during its development and after its deployment.

Conceptual model of the UML:

Page 4: LAB CODE - MRCET

7

To understand the UML, we need to form a conceptual model of the language and this requires learning three major elements.

The UML Basic Building Blocks.

The Rules that direct how those building blocks may be put together. Some common mechanisms that apply throughout the UML. As UML describes the real time systems it is very important to make a conceptual model and then proceed gradually. Conceptual model of UML can be mastered by learning the following three major elements:

UML building blocks

Rules to connect the building blocks

Common mechanisms of UML

UML building blocks. The building blocks of UML can be defined as:

Things

Relationships

Diagrams

Things:

Things are the most important building blocks of UML. Things can be:

Structural

Behavioral

Grouping

Annotational

Structural things:

The Structural things define the static part of the model. They represent physical a

conceptual elements. Following are the brief descriptions of the structural things.

Class:

Class represents set of objects having similar responsibilities.

Interface:

Interface defines a set of operations which specify the responsibility of a class

Use case:

Use case represents a set of actions performed by a system for a specific goal.

Component:

Component describes physical part of a system.

Node: A node can be defined as a physical element that exists at run time.

Behavioral things:

A behavioral thing consists of the dynamic parts of UML models. Following are the behavioral things:

Interaction:

Interaction is defined as a behavior that consists of a group of messages exchanged among elements to accomplish a specific task.

State machine:

Page 5: LAB CODE - MRCET

8

State machine is useful when the state of an object in its life cycle is important. It defines the sequence of states an object goes through in response to events. Events are external factors responsible for state change.

Grouping things

Grouping things can be defined as a mechanism to group elements of a UML model together. There is only one grouping thing available.

Package: Package is the only one grouping thing available for gathering structural and behavioral things.

Annotational things: Annotational things can be defined as a mechanism to capture remarks, descriptions, and comments of UML model elements. Note is the only one Annotational thing available.

Note: A note is used to render comments, constraints etc of an UML element.

Relationships in UML:

Relationship is another most important building block of UML. It shows how

elements are associated with each other and this association describes the functionality of an application. There are four kinds of relationships available.

Dependency:

Dependency is a relationship between two things in which change in one element also affects the other one.

Association:

Association is basically a set of links that connects elements of an UML model. It also describes how many objects are taking part in that relationship.

Generalization:

Generalization can be defined as a relationship which connects a specialized element with a generalized element. It basically describes inheritance relationship in the world of objects.

Realization:

Realization can be defined as a relationship in which two elements are connected. One element describes some responsibility which is not implemented and the other one implements them. This relationship exists in case of interfaces.

UML Diagrams:

UML diagrams are the ultimate output of the entire discussion. All the elements,

Relationships are used to make a complete UML diagram and the diagram represents a system. The visual effect of the UML diagram is the most important part of the entire process. All the other elements are used to make it a complete one.

UML includes the following nine diagrams and the details are described in the following

Class diagram

Object diagram

Use case diagram

Sequence diagram

Collaboration diagram

Page 6: LAB CODE - MRCET

9

Activity diagram

Statechart diagram

Deployment diagram

Component diagram

ARCHITECTURE OF UML

Any real world system is used by different users. The users can be developers, testers, business people, analysts and many more. So before designing a system the architecture is made with different perspectives in mind. The most important part is to visualize the system from different viewer‘s perspective. The better we understand the better we make the system. UML plays an important role in defining different perspectives of a system. These perspectives are:

Design

Implementation

Process

Deployment

And the centre is the Use Case view which connects all these four. A Use case represents the functionality of the system. So the other perspectives are connected with use case.

Design of a system consists of classes, interfaces and collaboration. UML provides class diagram, object diagram to support this. Implementation defines the components assembled together to make a complete physical system. UML component diagram is used to support implementation perspective.

Process defines the flow of the system. So the same elements as used in Design are also used to support this perspective.

Deployment represents the physical nodes of the system that forms the hardware. UML deployment diagram is used to support this perspective.

Automatic Teller Machine

Description of ATM System

The software to be designed will control a simulated automated teller machine (ATM) having a magnetic stripe reader for reading an ATM card, a customer console (keyboard and display) for interaction with the customer, a slot for depositing envelopes, a dispenser for cash, a printer for printing customer receipts, and a key-operated switch to allow an operator to start or stop the machine. The ATM will communicate with the bank‘s computer over an appropriate communication link. (The software on the latter is not part of the requirements for this problem.)

The ATM will service one customer at a time. A customer will be required to insert an ATM card and enter a personal identification number (PIN) – both of which will be sent to the bank for validation as part of each transaction. The customer will then be able to perform one or more transactions. The card will be retained in the machine until the customer indicates that he/she desires no further transactions, at which point it will be returned – except as noted below.

The ATM must be able to provide the following services to the customer:

1. A customer must be able to make a cash withdrawal from any suitable account linked to the card. Approval must be obtained from the bank before cash is dispensed.

Page 7: LAB CODE - MRCET

10

2. A customer must be able to make a deposit to any account linked to the card, consisting of cash and/or checks in an envelope. The customer will enter the amount of the deposit into the ATM, subject to manual verification when the envelope is removed from the machine by an operator. Approval must be obtained from the bank before physically accepting the envelope.

3. A customer must be able to make a transfer of money between any two accounts linked to the card.

4. A customer must be able to make a balance inquiry of any account linked to the card.

5. A customer must be able to abort a transaction in progress by pressing the Cancel key instead of responding to a request from the machine.

The ATM will communicate each transaction to the bank and obtain verification that it was allowed by the bank. Ordinarily, a transaction will be considered complete by the bank once it has been approved. In the case of a deposit, a second message will be sent to the bank indicating that the customer has deposited the

envelope. (If the customer fails to deposit the envelope within the timeout period, or presses cancel instead, no second message will be sent to the bank and the deposit will not be credited to the customer.)

If the bank determines that the customer‘s PIN is invalid, the customer will be required to re-enter the PIN before a transaction can proceed. If the customer is unable to successfully enter the PIN after three tries, the card will be permanently retained by the machine, and the customer will have to contact the bank to get it back.

If a transaction fails for any reason other than an invalid PIN, the ATM will display an explanation of the problem, and will then ask the customer whether he/she wants to do another transaction.

The ATM will provide the customer with a printed receipt for each successful transaction, showing the date, time, machine location, type of transaction, account(s), amount, and ending and available balance(s) of the affected account (―to‖ account for transfers).

The ATM will have a key-operated switch that will allow an operator to start and stop the servicing of customers. After turning the switch to the ―on‖ position, the operator will be required to verify and enter the total cash on hand. The machine can only be turned off when it is not servicing a customer. When the switch is moved to the ―off‖ position, the machine will shut down, so that the operator may remove deposit envelopes and reload the machine with cash, blank receipts, etc.

Page 8: LAB CODE - MRCET

11

EXPERIMENT: 1

Name of the experiment: Class diagram for ATM System

1. AIM: To design and implement class diagram for ATM system

2. THEORY:

The class diagram is a static diagram. It represents the static view of an application. Class diagram is not only used for visualizing, describing and documenting different aspects of a system but also for constructing executable code of the software application. The class diagram describes the attributes and operations of a class and also the constraints imposed on the system. The class diagram shows a collection of classes, interfaces, associations, collaborations and constraints. It is also known as a structural diagram.

Purpose:

The purpose of the class diagram is to model the static view of an application. The class diagrams are the only diagrams which can be directly mapped with object oriented languages and thus widely used at the time of construction. The UML diagrams like activity diagram, sequence diagram can only give the sequence flow of the application but class diagram is a bit different. So it is the most popular UML diagram in the coder community. So the purpose of the class diagram can be summarized as:

Analysis and design of the static view of an application.

Describe responsibilities of a system.

Base for component and deployment diagrams.

Forward and reverse engineering.

Contents: Class diagrams commonly contain the following things

Classes

Interfaces

Collaborations

Dependency, generalization and association relationships

ALGORITHM/ FLOWCHART/PSEUDO CODE:

Page 9: LAB CODE - MRCET

12

RESULT:

Input: _______________

Output: ______________

Inferences:

1. understand the concept of classes

2. identify classes and attributes and operations for a class

3. model the class diagram for the system

Sample input:

Class: Book

Book

Applications:

Online transaction

Online banking

Questions

1. What do you mean by class diagram?

2. What are properties of class diagram?

3. What are the common uses of class diagram?

4. What are the visibilities of class diagram?

5. What do you mean by classifiers?

6. What is the use of multiplicity in class diagram?

7. What is the scope of classifiers?

8. What are the relationships used in class diagrams?

9. What are the contents of class diagram?

10. What are the standard elements in class diagram?

Page 10: LAB CODE - MRCET

13

EXPERIMENT: 2

NAME OF EXPERIMENT: Use case diagram for ATM System.

AIM: To design and implement Use case diagram for ATM System.

THEORY: A Use case Diagram is a diagram that shows a set of Use cases and actors and their relationships. These diagrams are used to model the static use case view of a system.

To model a system the most important aspect is to capture the dynamic behaviour. To clarify a bit in details, dynamic behaviour means the behaviour of the system when it is running /operating. So only static behaviour is not sufficient to model a system rather dynamic behaviour is more important than static behaviour. In UML there are five diagrams available to model dynamic nature and use case diagram is one of them. Now as we have to discuss that the use case diagram is dynamic in nature there should be some internal or external factors for making the interaction. These internal and external agents are known as actors. So use case diagrams are

consists of actors, use cases and their relationships. The diagram is used to model the system/subsystem of an application. A single use case diagram captures a particular functionality of a system. So to model the entire system numbers of use case diagrams are used.

Purpose:

The purpose of use case diagram is to capture the dynamic aspect of a system. But this definition is too generic to describe the purpose. Because other four diagrams (activity, sequence, collaboration and Statechart) are also having the same purpose. So we will look into some specific purpose which will distinguish it from other four diagrams. Use case diagrams are used to gather the requirements of a system including internal and external influences. These requirements are mostly design requirements. So when a system is analyzed to gather its functionalities use cases are prepared and actors are identified.

So in brief, the purposes of use case diagrams can be as follows:

Used to gather requirements of a system.

Used to get an outside view of a system.

Identify external and internal factors influencing the system.

Show the interacting among the requirements are actors.

Page 11: LAB CODE - MRCET

14

ALGORITHM/ FLOWCHART/PSEUDO CODE:

RESULT:

Input: _______________

Output: ______________

Inferences:

1. Identification of use cases.

2. Identification of actors.

Sample input:

Actor: Student

Use case:

Withdrawal Use Case :

A withdrawal transaction asks the customer to choose a type of account to withdraw from (e.g. checking) from a menu of possible accounts, and to choose a dollar amount from a menu of possible amounts. The system verifies that it has sufficient money on hand to satisfy the request before sending the transaction to the bank. (If not, the customer is informed and asked to enter a different amount.) If the transaction is approved by the bank, the appropriate amount of cash is dispensed by the machine before it issues a receipt. A withdrawal transaction can be cancelled by the customer pressing the Cancel key any time prior to choosing the dollar amount.

User

Enter pin

Withdraw

Deposit

Balance enquiry

ATM

Admin Check

Cancel

Login

Page 12: LAB CODE - MRCET

15

Deposit Use Case

A deposit transaction asks the customer to choose a type of account to deposit to (e.g. checking) from a menu of possible accounts, and to type in a dollar amount on the keyboard. The transaction is initially sent to the bank to verify that the ATM can accept a deposit from this customer to this account. If the transaction is approved, the machine accepts an envelope from the customer containing cash and/or checks before it issues a receipt. Once the envelope has been received, a second message is sent to the bank, to confirm that the bank can credit the customer‘s account – contingent on manual verification of the deposit envelope contents by an operator later.

A deposit transaction can be cancelled by the customer pressing the Cancel key any time prior to inserting the envelope containing the deposit. The transaction is automatically cancelled if the customer fails to insert the envelope containing the

deposit within a reasonable period of time after being asked to do so.

Transfer Use Case

A transfer transaction asks the customer to choose a type of account to transfer from (e.g. checking) from a menu of possible accounts, to choose a different account to transfer to, and to type in a dollar amount on the keyboard. No further action is required once the transaction is approved by the bank before printing the receipt.

A transfer transaction can be cancelled by the customer pressing the Cancel key any time prior to entering a dollar amount.

Inquiry Use Case

An inquiry transaction asks the customer to choose a type of account to inquire about from a menu of possible accounts. No further action is required once the transaction is approved by the bank before printing the receipt. An inquiry transaction can be cancelled by the customer pressing the Cancel key any time prior to choosing the account to inquire about.

Validate User use case:

This usecase is for validate the user i.e. check the pin number, when the bank reports that the customer‘s transaction is disapproved due to an invalid PIN. The customer is required to re-enter the PIN and the original request is sent to the bank again. If the bank now approves the transaction, or disapproves it for some other reason, the original use case is continued; otherwise the process of re-entering the PIN is repeated. Once the PIN is successfully re-entered

If the customer fails three times to enter the correct PIN, the card is permanently

retained, a screen is displayed informing the customer of this and suggesting he/she contact the bank, and the entire customer session is aborted.

Print Bill use case

This usecase is for printing corresponding bill after transactions (withdraw or deposit or balance enquiry or transfer) are completed.

Update Account

This usecase is for updating corresponding user accounts after transactions (withdraw or deposit or transfer) are completed.

Page 13: LAB CODE - MRCET

16

Questions:

1. What do you mean by Use case diagram?

2. What are the common modeling techniques of use case diagram?

3. What do you mean by Use case.

4. What are common properties of Use case diagram?

5. What are the common uses of Use case diagram?

6. What are contents of Use case diagram?

7. What do you mean by extend relationship.

8. What do you mean by include relationship.

9. What is the f low of events in use cases

10. What do you mean by actor and how can you represent an actor

3. INTERACTION DIAGRAMS

We have two types of interaction diagrams in UML. One is sequence diagram and the other is a collaboration diagram. The sequence diagram captures the time sequence of message flow from one object to another and the collaboration diagram describes the organization of objects in a system taking part in the message flow.

So the following things are to identified clearly before drawing the interaction diagram:

1. Objects taking part in the interaction.

2. Message flows among the objects.

3. The sequence in which the messages are flowing.

4. Object organization.

Purpose:

1. To capture dynamic behaviour of a system.

2. To describe the message flow in the system.

3. To describe structural organization of the objects.

4. To describe interaction among objects.

Contents of a Sequence Diagram

Objects

Focus of control

Messages

Life line

Contents.

Contents of a Collaboration Diagram

Objects

Links

Messages

Page 14: LAB CODE - MRCET

17

EXPERIMENT: 3

Name of the experiment: Sequence diagram for ATM System

AIM: To design and implement Sequence diagram for ATM System.

THEORY: A Sequence diagram is an interaction diagram that emphasizes the time ordering of messages. This diagram is used to show the dynamic view of a system.

ALGORITHM/ FLOWCHART/PSEUDO CODE

ATM ADMIN

Check pin no

Pin valid/invalid

Check account

Display status

Check amount

Display status

Update account

Page 15: LAB CODE - MRCET

18

QUESTIONS:

11. What do you mean by sequence diagram?

12. What are the properties of Interaction diagram?

13. What do you mean by life line?

14. What are the common modeling techniques of Interaction diagram?

15. What are the common uses of Interaction diagram?

16. What are contents of Interaction diagram?

17. What do you mean by messages?

18. What do you mean by focus of control?

19. What do you mean by stereotype?

20. What do you mean by Interaction diagram?

Page 16: LAB CODE - MRCET

19

EXPERIMENT: 4

NAME OF EXPERIMENT: collaboration for ATM System.

AIM: To design and implement Use case diagram for ATM System.

THEORY: A Use case diagram is a diagram that shows a set of use cases and actors and their relationships. These diagrams are used to model the static use case view of a system.

ALGORITHM/ FLOWCHART/PSEUDO CODE

5. STATE CHART Diagram

Statechart diagram is used to model dynamic nature of a system. They define different states of an object during its lifetime. And these states are changed by events. So Statechart diagrams are useful to model reactive systems. Reactive systems can be defined as a system that responds to external or internal events.

Statechart diagram describes the flow of control from one state to another state. States are defined as a condition in which an object exists and it changes when some event is triggered. So the most important purpose of Statechart diagram is to model life time of an object from creation to termination.

Statechart diagrams are also used for forward and reverse engineering of a system. But the main purpose is to model reactive system.

Following are the main purposes of using Statechart diagrams:

1. To model dynamic aspect of a system.

2. To model life time of a reactive system.

3. To describe different states of an object during its life time.

4. Define a state machine to model states of an object.

Contents

Simply state and composite states

Transitions, including events and actions

Common use

They are use to model the dynamic aspects of a system.

Event ordered behavior of any kind of objects, to model reactive objects.

1. Identify the states of the objects.

2. Model the state diagram for the system.

:

ATM ADMIN

1: check pin no 3: check account 5: check amount

7: update account

2: pin valid/invalid 4: display status 6: display status

Page 17: LAB CODE - MRCET

20

EXPERIMENT: 5

NAME OF EXPERIMENT: State chart diagram for ATM System.

AIM: To design and implement State chart diagram for ATM System.

THEORY: A Statechart diagram shows a state machine, emphazing the flow of control from state to state .A state machine is a behavior that specifies the sequences of states an object goes through during its life time in response to events together with responses to those events. We can use these diagrams to model the dynamic view of a system.

ALGORITHM/FLOWCHART/PSEUDOCODE

RESULT:

Input: _______________

Output:______________

Inferences:

1. Identify the states of the objects.

2. Model the state diagram for the system.

Page 18: LAB CODE - MRCET

21

QUESTIONS:

1. What do you mean by state chart diagram?

2. What do you mean by state machine?

3. What do you mean by state?

4. What are common properties of state chart diagram?

5. What are the common uses of state chart diagram?

6. What are contents of state chart diagram?

7. What are twelve stereotypes that may be applied to dependency relationships?

8. What do you mean by dependency, generalization, association?

9. What are the steps to model the group the elements?

10. What do you mean by composite states?

Page 19: LAB CODE - MRCET

22

EXPERIMENT: 6

NAME OF EXPERIMENT: Activity diagram for ATM System.

AIM: To design and implement Activity diagram for ATM System.

THEORY: An activity diagram shows the flow from activity to activity .An activity is an ongoing non atomic execution within a state machine. Activities ultimately results in some action, which is made up of executable atomic computations. we can use these diagrams to model the dynamic aspects of a system.

Activity diagram is basically a flow chart to represent the flow form one activity to another. The activity can be described as an operation of the system. So the control flow is drawn from one operation to another. This flow can be sequential, branched or concurrent. Activity diagrams deals with all type of flow by using elements like fork, join etc.

Contents

Initial/Final State, Activity, Fork & Join, Branch, Swimlanes

Fork

A fork represents the splitting of a single flow of control into two or more concurrent flow of control. A fork may have one incoming transition and two or more outgoing transitions, each of which represents an independent flow of control. Below fork the activities associated with each of these path continues in parallel.

Join

A join represents the synchronization of two or more concurrent flows of control. A join may have two or more incoming transition and one outgoing transition. Above the join the activities associated with each of these paths continues in parallel.

Branching

A branch specifies alternate paths takes based on some Boolean expression Branch is represented by diamond Branch may have one incoming transition and two or more outgoing one on each outgoing transition, you place a Boolean expression shouldn‘t overlap but they should cover all possibilities.

Swimlane:

Swimlanes are useful when we model workflows of business processes to partition the activity states on an activity diagram into groups. Each group representing the business organization responsible for those activities, these groups are called Swimlanes .

Page 20: LAB CODE - MRCET

23

ALGORITHM/ FLOWCHART/PSEUDO CODE

RESULT:

Input: _______________

Output:______________

Inferences:

1. Identify the states of the objects.

2. Understand the transitions and events for various objects.

3. Model the state diagram for the system.

QUESTIONS:

1. What do you mean by state chart diagram?

2. What do you mean by state machine?

3. What do you mean by state?

4. What are common properties of state chart diagram?

5. What are the common uses of state chart diagram?

6. What are contents of state chart diagram?

7. What are twelve stereotypes that may be applied to dependency relationships?

8. What do you mean by dependency, generalization, association?

9. What are the steps to model the group the elements?

10. What do you mean by composite states?

Page 21: LAB CODE - MRCET

24

EXPERIMENT: 7

NAME OF EXPERIMENT: Component diagram for ATM System.

AIM: To design and implement Component diagram for ATM System.

THEORY:

Component diagrams are used to model physical aspects of a system. Now the question is what are these physical aspects? Physical aspects are the elements like executables, libraries, files, documents etc which resides in a node. So component diagrams are used to visualize the organization and relationships among components in a system. These diagrams are also used to make executable systems.

Purpose:

Component diagrams can be described as a static implementation view of a system. Static implementation represents the organization of the components at a particular moment.

A single component diagram cannot represent the entire system but a collection of diagrams are used to represent the whole.

Before drawing a component diagram the following artifacts are to be identified clearly:

Files used in the system.

Libraries and other artifacts relevant to the application.

Relationships among the artifacts.

Now after identifying the artifacts the following points needs to be followed:

Use a meaningful name to identify the component for which the diagram is to be drawn.

Prepare a mental layout before producing using tools.

Use notes for clarifying important points.

Now the usage of component diagrams can be described as:

1. Model the components of a system.

2. Model database schema.

3. Model executables of an application.

4. Model system‘s source code.

Contents: Components, Interfaces, Relationships

Page 22: LAB CODE - MRCET

25

ALGORITHM/ FLOWCHART/PSEUDO CODE

RESULT:

Input: _______________

Output:______________

Inferences:

1. Identify the states of the objects.

2. Model the state diagram for the system.

QUESTIONS:

1. What is a component diagram?

2. How components are used in component diagram?

3. What are the common properties of components?

4. What are the contents of deployment diagram?

Page 23: LAB CODE - MRCET

26

EXPERIMENT: 8

NAME OF EXPERIMENT: Deployment diagram for ATM System.

AIM: To design and implement Deployment diagram for ATM System.

THEORY:

Deployment diagrams are used to visualize the topology of the physical components of a system where the software components are deployed. So deployment diagrams are used to describe the static deployment view of a system. Deployment diagrams consist of nodes and their relationships.

Purpose:

The name Deployment itself describes the purpose of the diagram. Deployment diagrams are used for describing the hardware components where

software components are deployed. Component diagrams and deployment diagrams are closely related. Component diagrams are used to describe the components and deployment diagrams shows how they are deployed in hardware.

Contents: Nodes, Dependency & Association relationships

Page 24: LAB CODE - MRCET

27

RESULT:

Input: _______________

Output:______________

Inferences:

1. Identify the states of the objects .

2. Model the state diagram for the system.

QUESTIONS

1. What is a deployment diagram?

2. How components are used in deployment diagram?

3. What are the common properties of components?

4. What are the contents of deployment diagram?

5. What are the relationships used in deployment diagram?

6. What is node?

7. How nodes are related to components?

8. What is the purpose of a note in deployment diagram?

9. Enumerate the steps for modeling deployment diagram?

10. How can you organize the node?

Page 25: LAB CODE - MRCET

28

P1: Class diagram for Library Management System

Aim: Draw a Class Diagram for Library Management System

Contents:

Classes:

1. Librarian

Attributes: name Operations: Issue Books

Id Check availability

Charge for Books

Collect Fines

2. Staff

Attributes: name Operations: Refer Books

Id Take Books

Department Return Books

3. Student

Attributes: name Operations: Refer Books

Id Take Books

Branch Return Books

Year Pay fine

4. Book

Attributes: name Operations: Provides Information

Edition

Author

Cost

Two sub classes have to consider under the ―STAFF‖ and ―BOOK‖ classes with the same attributes and operations are:

Teaching staff Text Book

Non-Teaching Staff Gernals

Page 26: LAB CODE - MRCET

29

P2: Class diagram for Hospital Management System

Aim: Draw a Class Diagram for Hospital Management System

Contents:

Classes:

1. Hospital

Attributes: name Operations: Provide beds

Location Provide Machinery

Provide Wards

2. Doctor

Attributes: name Operations: Treats Patients

Id Provide Prescription

Specialization

3. Patient

Attributes: name Operations: Consult doctor

Disease Joins in hospital

Bed no. Buy Medicines

Pay Bill

4. Receptionist

Attributes: name Operations: Provide details

id Allot Bed

Receive Bill

Update Database

5. Database

Attributes: name Operations: Insert

Location Update

Delete

Page 27: LAB CODE - MRCET

30

P3: Class diagram for Hotel Management System

Aim: Draw a Class Diagram for Hotel Management System

Contents:

Classes:

1. Hotel

Attributes: name Operations: Provide Food

Location Provide Rooms

2. Customer

Attributes: name Operations: Order food

Phone No. Book a Room

Cancel Room

Pay Bill

Pay Tip

3. Receptionist

Attributes: name Operations: Provide Food

Phone No. Book a Room

Location Cancel Room

Charge Room

Collects bill

Update Details

4. Barer

Attributes: name Operations: Take Order

Id Serves Food

Receives Tip

Page 28: LAB CODE - MRCET

31

P4: Class diagram for Blood Bank Management System

Aim: Draw a Class Diagram for Blood Bank Management System

Contents:

Classes:

1. Administrator

Attributes: name Operations: Maintains Blood Bank

id Receives Blood

Sells Blood

Check Availability

2. Donor

Attributes: name Operations: Search Blood Bank

Phone No. Donates Blood

age Collects Amount

Location

Weight

Blood Group

3. Receiver

Attributes: name Operations: Search Blood Bank

Phone No. Buys Blood

age Pay Amount

Location

Weight

Blood Group

4. Doctor

Attributes: name Operations: Treats Patients

Id Identify disease

Specialization Provide Prescription

Instruct the patients to buy blood

5. Database

Attributes: name Operations: Insert Details

Location Update Details

Delete Details

Page 29: LAB CODE - MRCET

32

P5: Class diagram for Airline Reservation System

Aim: Draw a Class Diagram for Airline Reservation System

Contents:

Classes:

1 Airline

Attributes: Reservation availability Operations: Provide flight details

Confirm booking

2 Ticket vendor

Attributes: Name Operations: Reserve flight

Check availability

3 Passenger

Attributes: Name Operations: Request flight

Address Pay for ticket

SSN

4 Ticket

Attributes: Airline Name Operations: Verify Ticket

Ticket Price

Flight Date

Flight Time

Flight Number

Ticket Number

5 Ticket agent

Attributes: Vendor name Operations: Check availability

Vendor adress

6 Airline ticket vendor Operations: Check availability

Attributes: Airline Name

Airline Adress

P6: Class diagram for Student Mark Analyzing System

Aim: Draw a Class Diagram for Student Mark Analyzing System

Contents:

Classes:

1. Staff Member

Attributes: No of Subjects Operations: Calculates total

Marks Assigns Grade

Total Display Result

Page 30: LAB CODE - MRCET

33

Percentage

Grade

Roll No

2. Student

Attributes: Name Operations: Checks Result

Roll No

College Code

P7: Class diagram for Railway Reservation System Aim: Draw a Class Diagram for Railway Reservation System Contents:

Classes: 1. Clerk

Attributes: id Operations: Details of Form

Cancellation of

Form

2. Train

Attributes: Train number

Train name

3. Passenger

Attributes: Name Operations: Search ticket

Address Book ticket

Age Pay charges

Gender Modify form

Cancel ticket

4. Ticket

Attributes: pemo Operations: Fare amount

Status new ticket

Number of Persons deletes ticket

Type of charge

5. Payment

Attributes: Amount

6. Railway System

Attributes: Id Operations: Response

P8: Class diagram for Stock Maintenance Aim: Draw a Class Diagram for Stock Maintenance Contents:

Classes: 1. Product Purchase Details

Attributes: Pcode Operations: Add

PName Delete

Opening Stock update

Price clear

2. Purchase Details

Attributes: Pdate Operations: Purchase Save

Page 31: LAB CODE - MRCET

34

Pcode Purchase delete

Sname

Pqty

3. Sales Details

Attributes: Sdate Operations: Add Sales

Cname

pcode

price

City

4. Stock Details

Attributes: date Operations: Fare amount

cancel

P9: Class diagram for Tour Management System

Aim: Draw a Class Diagram for Tour Management System

Contents:

Classes:

1. MR_Form

Attributes: Request customer info

Modify customer info

Submit

Display customer info

2. MTS_Form

Attributes: Request tour add form

Display tour add form

Input tour details

Submit

3. PaymentForm

Attributes: Request for payment status

Submit

Select mode credit card

Display status

Display modes of payment

Display message payment done

4. VU_Form

Attributes: Input id

Input pwd

Submit

Request sign in

Display

Page 32: LAB CODE - MRCET

35

P10: Class diagram for Online Course Registration

Aim: Draw a Class Diagram for Online Course Registration

Contents:

Classes:

1. College

Attributes: No of course Operation: Display

Register number Check detail

Course code Confirmation

Fees details

2. Student

Attributes: Course

Register number

Course code

Fees details

Credit card transaction

P1: Use case diagram for Library Management System

Aim: Draw a Use case Diagram for Library Management System

Contents:

Actors:

1. Library (system)

2. Librarian

3. Teaching staff

4. Non-Teaching Staff

5. Student

Actions performed by these actors are same as that of Operations included in Class Diagram for Library Management System

P2: Use case diagram for Hospital Management System

Aim: Draw a Use case Diagram for Hospital Management System

Contents:

Actors:

1. Hospital (system)

2. Doctor

3. Patient

4. Receptionist

5. Data base (system)

Page 33: LAB CODE - MRCET

36

Actions performed by these actors are same as that of Operations included in Class Diagram for Hospital Management System

P3: Use case diagram for HOTEL Management System

Aim: Draw a Use case Diagram for HOTEL Management System

Contents:

Actors:

1. Hotel (system)

2. Customer

3. Receptionist

4. Barer

Actions performed by these actors are same as that of Operations included in Class Diagram for HOTEL Management System

P4: Use case diagram for Blood Bank Management System

Aim: Draw a Use case Diagram for Blood Bank Management System

Contents:

Actors:

1. Blood Bank (system)

2. Administrator

3. Donor

4. Receiver

5. Doctor

6. Database

Actions performed by these actors are same as that of Operations included in Class Diagram for Blood Bank Management System

P5: Use case diagram for Airline Reservation System

Aim: Draw a Use case Diagram for Airline Reservation System

Contents:

Actors:

1. Passenger

2. Reservation clerck

Actions performed by these actors are same as that of Operations

included in Class Diagram for Airline reservation System

Page 34: LAB CODE - MRCET

37

P6: Use case diagram for Student Mark Analyzing System

Aim: Draw a Use case Diagram for Student Mark Analyzing System

Contents:

Actors:

1. Staff Member 2. Student

USE CASES:

1. Number of Subjects.

2. Marks.

3. Total.

4. Percentage. 5. Grade

Actions performed by these actors are same as that of Operations included in Class Diagram for Student Mark Analyzing System.

P7: Use case diagram for Railway Reservation System

Aim: Draw a Use case Diagram for Railway Reservation System

Contents:

Actors:

1. Customer

2. Clerk

3. Railway Website

Actions performed by these actors are same as that of Operations

included in Class Diagram for Railway Reservation System

P8: Use case diagram for Stock Maintenance

Aim: Draw a Use case Diagram for Stock Maintenance

Contents:

Actors:

1. Administrator

2. Customer

3. Supplier

Actions performed by these actors are same as that of Operations included in Class Diagram for Stock Maintenance.

P9: Use case diagram for Tour Management system

Aim: Draw a Use case Diagram for Tour Management system

Contents:

Actors: 1. Administrator

Page 35: LAB CODE - MRCET

38

2. System user

3. Staff

4. Authorized customer

Actions performed by these actors are same as that of Operations included in Class Diagram for Tour Management system

P10: Use case diagram for Online Course Registration

Aim: Draw a Use case Diagram for Online Course Registration

Contents:

Actors: 1. System

2. Student

Actions performed by these actors are same as that of Operations included in Class Diagram for Online Course Registration

P1: Sequence diagram for Student Mark Analyzing System

Aim: Draw a Sequence diagram for Student Mark Analyzing System

Contents:

Objects:

1. Staff 2. Marks 3. Find total 4. Assign Grade 5. Student

The Operations included in Class Diagram for Student Mark Analyzing System are considered as time-ordering messages for sequence diagram.

P2: Sequence diagram for Library Management System

Aim: Draw a Sequence diagram for Library Management System

Contents:

OBjects:

1. Librarian

2. Teaching staff

3. Non-Teaching Staff

4. Student

5. Database/Server

The Operations included in Class Diagram for Library Management System are considered as time-ordering messages for sequence diagram

Page 36: LAB CODE - MRCET

39

P3: Sequence diagram for Hotel Management System

Aim: Draw a Sequence diagram for Hotel Management System

Contents:

OBjects:

1. Hotel (system)

2. Customer

3. Receptionist

4. Barer

The Operations included in Class Diagram for Hotel Management System are considered as time-ordering messages for sequence diagram.

P4: Sequence diagram for HOSPITAL Management System

Aim: Draw a Sequence diagram for HOSPITAL Management System

Contents:

OBjects:

1. Hospital (system)

2. Doctor

3. Patient

4. Receptionist

5. Data base (system)

The Operations included in Class Diagram for Hospital Management System are considered as time-ordering messages for sequence diagram.

P5: Sequence diagram for Blood Bank Management System

Aim: Draw a Sequence diagram for Blood Bank Management System

Contents:

OBjects:

a. Blood Bank (system)

b. Administrator

c. Donor

d. Receiver

e. Doctor

f. Database

The Operations included in Class Diagram for Blood Bank l Management System are considered as time-ordering messages for sequence diagram.

Page 37: LAB CODE - MRCET

40

P6: Sequence diagram diagram for AirLine Reservation System

Aim: Draw a Sequence diagram for Airline Reservation System

Contents:

Objects:

a. Reservation

b. Flight

c. Passenger

d. Aircraft

e. Credit card

The Operations included in Class Diagram for Airline Reservation System are considered as time-ordering messages for sequence diagram.

P7: Sequence diagram for Railway Reservation System

Aim: Draw a Sequence diagram for Railway Reservation System

Contents:

Objects:

1. Passenger

2. Clerk

3. Ticket

The Operations included in Class Diagram for Railway Reservation System are considered as time-ordering messages for sequence diagram.

P8: Sequence diagram for Stock Maintenance.

Aim: Draw a Sequence diagram for Stock Maintenance.

Contents:

Objects:

1. Login

2. Verifier

3. Database

The Operations included in Class Diagram for Stock Maintenance are considered as time-ordering messages for sequence diagram.

P9: Sequence diagram for Tour Management system

Aim: Draw a Sequence diagram for Tour Management system

Contents:

Objects:

1. Customer

2. Customer info forum

Page 38: LAB CODE - MRCET

41

3. RFT-controller

4. Tour info

5. Customer info

6. Tis interface

The Operations included in Class Diagram for Tour Management

system are considered as time-ordering messages for sequence diagram.

P10: Sequence diagram for Online course registration system

Aim: Draw a Sequence diagram for Online course registration System

Contents:

Objects:

1. System

2. Student

The Operations included in Class Diagram for Online course registration

system are considered as time-ordering messages for sequence diagram.

P1: Collaboration diagram for Student Mark Analyzing System

Aim: Draw a Collaboration diagram for Student Mark Analyzing System

Contents:

Objects:

1. Staff 2. Marks 3. Find total 4. Assign Grade 5. Student

P2: Collaboration diagram for Library Management System

Aim: Draw a Collaboration diagram for Library Management System

Contents:

Objects: .

1. Librarian

2. Teaching staff

3. Non-Teaching Staff

4. Student

5. Database/Server

Page 39: LAB CODE - MRCET

42

P3: Collaboration diagram for Hotel Management System Aim: Draw a Collaboration diagram for Hotel Management System

Contents:

Objects:

1. Hotel (system)

2. Customer

3. Receptionist

4. Barer

P4: Collaboration diagram for Hospital Management System Aim: Draw a Collaboration diagram for Hospital Management System

Contents:

Objects:

1. Hospital (system)

2. Doctor

3. Patient

4. Receptionist

5. Data base

P5: Collaboration diagram for Blood Bank Management System Aim: Draw a Collaboration diagram for Blood Bank Management System

Contents:

Objects:

1. Blood Bank (system)

2. Administrator

3. Donor

4. Receiver

5. Doctor

6. Database

P6: Collaboration diagram for Airline Reservation System Aim: Draw a Collaboration diagram for Airline Reservation System

Contents:

Objects:

1. Reservation

2. Flight

3. Passenger

4. Aircraft

5. Credit card

Page 40: LAB CODE - MRCET

43

P7: Collaboration diagram for Railway Reservation System

Aim: Draw a Collaboration diagram for Railway Reservation System

Contents:

Objects:

1. Passenger

2. Clerk

3. Ticket

P8: Collaboration diagram for Stock Maintenance Aim: Draw a Collaboration diagram for Stock Maintenance

Contents:

Objects:

1. Login

2. Verifier

3. Database

P9: Collaboration diagram for Tour Management system Aim: Draw a Collaboration diagram for Tour Management system

Contents:

Objects:

1. Customer

2. Customer info forum

3. RFT-controller

4. Tour info

5. Customer info

6. Tis interface

P10: Collaboration diagram for Online course registration system Aim: Draw a Collaboration diagram for Online course registration system

Contents:

Objects:

1. System

2. Student

P1: Activity diagram for Student Mark Analyzing System

Aim: Draw a Activity diagram for Student Mark Analyzing System

Contents:

Activities:

1. Student detail submission

Page 41: LAB CODE - MRCET

44

2. Filter

3. Process

4. report

P2: Activity diagram for Library Management System

Aim: Draw a Activity diagram for Library Management System

Contents:

Activities:

1. library card

2. enter the library number

3. check the number

4. return the book

5. borrow the book

6. do research

7. purchase supplies

P3: Activity diagram for Hotel Management System

Aim: Draw a Activity diagram for Hotel Management System

Contents:

Activities:

1. enter the customer name

2. verify id card

3. allot room

4. ask for requirements

5. feed back

P4: Activity diagram for Hospital Management System

Aim: Draw a Activity diagram for Hospital Management System

Contents:

Activities:

1. patient takes appointment

2. doctor is available

3. patient consult doctor

4. undergoes operation

5. patient gets operated

6. gets prescription

7. discharge

Page 42: LAB CODE - MRCET

45

P5: Activity diagram for Blood Bank Management System

Aim: Draw a Activity diagram for Blood Bank Management System

Contents:

Activities:

1. get the data

2. validate

3. get the data

4. action state

5. verify

P6: Activity diagram for Airline Reservation System System

Aim: Draw a Activity diagram for Airline Reservation System System

Contents:

Activities:

1. collect form and get the details

2. submit form

3. validate and verify

4. calculate fare amount

5. print

P7: Activity diagram for Railway Reservation System

Aim: Draw a Activity diagram for Railway Reservation System

Contents:

Activities:

1. collect form and get the details

2. submit form

3. validate and verify

4. calculate fare amount

5. print

P8: Activity diagram for Stock Maintenance System

Aim: Draw a Activity diagram for Stock Maintenance System

Contents:

Activities:

1. Enter the product id

Page 43: LAB CODE - MRCET

46

2. Enter the product details

3. Enter the Pname

4. Enter amount

5. Enter operating stock

6. Error message

P9: Activity diagram for Tour Management System

Aim: Draw a Activity diagram for Tour Management System

Contents:

Activities:

1. Customer request for registration.

2. Tour reservation system checks whether customer is old/not.

3. If customer is old then customer gets the details and reserve customer for tour.

4. If customer is new then he enters his details and the details were saved by tour

management system and generate a new ID and PASSWORD to him.

P10: Activity diagram for Online course registration system

Aim: Draw a Activity diagram for Online course registration system

Contents:

Activities:

1. No. of course

2. Course code

3. Register

4. Fees detail

5. Certificate submission

6. Credit card transaction

7. Confirmation message

8. Course registered sucessfully

P1: Statechart diagram for Student Mark Analyzing system

Aim: Draw a Statechart diagram for Student Mark Analyzing system

Contents:

Activities:

1. Number of students

2. Marks

3. Grade

4. Total

5. Average

Page 44: LAB CODE - MRCET

47

P2: Statechart diagram for Library Management System

Aim: Draw a Statechart diagram for Library Management System

Contents:

Activities:

1. Login

2. Search book

3. Book status

4. If found update

5. If not do update

6. Request librarian

7. Request for issue

8. Logout

P3: Statechart diagram for Hotel Management System

Aim: Draw a Statechart diagram for Hotel Management System

Contents:

Activities:

1. Make enquiry

2. Check in

3. Provide your identity

4. Check for room

5. Check for hospitality

6. Order eatables

7. Want to leave

8. Pay the bill

9. Check out

P4: Statechart diagram for Hospital Management System

Aim: Draw a Statechart diagram for Hospital Management System

Contents:

Activities:

1. Patient takes appointment

2. Receptionist Checks for doctor

3. If doctor available patient consult doctor

4. Patient need to be operated

5. Undergoes operation

6. Patient gets operated

Page 45: LAB CODE - MRCET

48

7. If patient ok discharge

8. Not ok consult doctor

P5: Statechart diagram for Blood Bank Management System

Aim: Draw a Statechart diagram for Blood Bank Management System

Contents:

Activities:

1. Register

2. Enter details

3. Details valid

4. Obtain member id

5. Successful registration

6. Authenticate

7. Enter member id and pwd

8. Valid

9. Enter into panel

10. Authentication successfull

11. Book search

12. Enter the search criteria

13. Display results

14. Get books

15. Status

16. Enter member id

17. Display membership status

P6: Statechart diagram for Airline Reservation System

Aim: Draw a Statechart diagram for Airline Reservation System

Contents:

Activities:

1. Login

2. Enquire about flight

3. Fill details

4. Produce your identity

5. Verify ticket fare

6. Pay the amount

Page 46: LAB CODE - MRCET

49

P7: Statechart diagram for Railway Reservation System

Aim: Draw a Statechart diagram for Railway Reservation System

Contents:

Activities:

1. Login

2. Destination

3. Select train

4. Select seat

5. If available select the ticket

6. Confirm the details

7. Pay the amount

P8: Statechart diagram for Stock Maintenance System

Aim: Draw a Statechart diagram for Stock Maintenance System

Contents:

Activities:

1. Product name

2. Product id

3. Price

4. Error message

P9: Statechart diagram for Tour Management System

Aim: Draw a Statechart diagram for Tour Management System

Contents:

Activities:

1. Request for registration

2. Is old get tour details

3. Provide tour details

4. Display tour details

5. Select tour details

6. Get personal details

7. Input personal details

8. Submit

9. Reserve customer for tour

10. Update tour information

Page 47: LAB CODE - MRCET

50

P10: Statechart diagram for Online course registration system

Aim: Draw a Statechart diagram for Online course registration system

Contents:

Activities:

1. Register

2. No of course

3. Course code

4. Course duration

5. Fees details

P1: Component diagram for Student Mark Analyzing System

Aim: Draw a Component diagram for Student Mark Analyzing System

Contents:

Components:

1. Student

2. Staff

3. Marks display

P2: Component diagram for Library Management System

Aim: Draw a Component diagram for Library Management System

Contents:

Components:

1. Register page

2. Login page

3. Request vendor

4. Search page

5. Request page

6. Make issue

7. Make payment

P3: Component diagram for Hotel Management System

Aim: Draw a Component diagram for Hotel Management System

Contents:

Components:

1. Login

2. Database

3. Customer database

4. Check in details

Page 48: LAB CODE - MRCET

51

P4: Component diagram for Hospital Management System

Aim: Draw a Component diagram for Hospital Management System

Contents:

Components:

1. Hospital management system local server

2. Hms data processing

3. Equipment database

4. User interface

5. Patient database

P5: Component diagram for Blood Bank Management System

Aim: Draw a Component diagram for Blood Bank Management System

Contents:

Components:

1. Hospital management system local server

2. Blood bank database

3. Equipment database

4. User interface

5. Patient database

P6: Component diagram for Airline Reservation System

Aim: Draw a Component diagram for Airline Reservation System

Contents:

Components:

1. Login

2. Flight details

3. Ticket

4. Payment

P7: Component diagram for Railway Reservation System

Aim: Draw a Component diagram for Railway Reservation System

Contents:

Components:

View classes

1. Check availability

2. Fill form

Page 49: LAB CODE - MRCET

52

3. Modify form

4. Book ticket

Reservation classes

1. Passenger

2. Clerk

3. Ticket

4. Refund money

5. Session

6. Payment

P8: Component diagram for Stock Maintenance System

Aim: Draw a Component diagram for Stock Maintenance System

Contents:

Components:

1. Login

2. Database

3. Stock details

P9: Component diagram for Tour Management System

Aim: Draw a Component diagram for Tour Management System

Contents:

Components:

User interface

1. Register Page

2. Login Page

3. Reserve for tour package form

4. Billing form

5. Request for Scheme form

6. Updating tour package form

7. Tour Information System

Business view

8. Registered customer

9. Session

10. Reservation

11. Administrater

12. Maintain tour scheme

13. Bill

Access Database

14. DataBase

Page 50: LAB CODE - MRCET

53

P10: Component diagram for Online course registration system

Aim: Draw a Component diagram for Online course registration system

Contents:

Components:

1. College details

2. Staff

3. Course details

P1: Deployment diagram for Student Mark Analyzing System

Aim: Draw a Deployement diagram for Student Mark Analyzing System

Contents:

Nodes:

1. Student marks database

2. Validate total

3. Display

P2: Deployment diagram for Library Management System

Aim: Draw a Deployment diagram for Library Management System

Contents:

Nodes:

1. Library LAN server

2. Console

3. Vendor server

P3: Deployment diagram for Hotel Management System

Aim: Draw a Deployment diagram for Hotel Management System

Contents:

Nodes:

1. Hotel database

2. Customer database

3. Web server

P4: Deployment diagram for Hospital Management System

Aim: Draw a Deployment diagram for Hospital Management System

Contents:

Nodes:

1. Hospital local server

Page 51: LAB CODE - MRCET

54

2. Database server

3. Desktop client

P5: Deployment diagram for Blood Bank Management System

Aim: Draw a Deployment diagram for Blood Bank Management System

Contents:

Nodes:

1. Hospitable database server

2. Blood bank server

3. Patient database

P6: Deployment diagram for Airline Reservation System

Aim: Draw a Deployment diagram for Airline Reservation System

Contents:

Nodes:

1. Web server

2. Application server

3. Database server

4. Reservation details

5. Passenger database

P7: Deployment diagram for Railway Reservation System

Aim: Draw a Deployement diagram for Railway Reservation System

Contents:

Nodes:

a. Railway reservation web server

b. Application server

c. Database server

d. Passenger

P8: Deployement diagram for Stock Maintenance System

Aim: Draw a Deployement diagram for Stock Maintenance System

Contents:

Nodes:

1. Product report

2. Purchase

3. Sales report

4. Stock report

Page 52: LAB CODE - MRCET

55

P9: Deployement diagram for Tour Management System

Aim: Draw a Deployement diagram for Tour Management System

Contents:

Nodes:

1. Database

2. Application server

3. Web server

4. Client

P10: Deployement diagram for Online course registration system

Aim: Draw a Deployement diagram for Online course registration system

Contents:

Nodes:

1. Course database

2. College database

3. Web server

4. Student database

5. Application server

SOFTWARE TESTING

EXPERIMENT: 1

NAME OF THE EXPERIMENT: Write program in ‗C‘ language to demonstrate the working of the following constructs

i.)do..while:

Syntax:

Iteration-statement:

do statement while ( expression ) ;

Example:

#include<stdio.h>

#include<conio.h>

#include <stdio.h>

main()

{

Page 53: LAB CODE - MRCET

56

int i = 10;

do{

printf("Hello %d\n", i );

i = i -1;

if( i == 6 )

{

break;

}

}while ( i > 0 );

}

ii.) while..do

while(condition)

{

Loop body

Increment or decrement;

}

Example:

#include<stdio.h>

int main()

{

int counter, howmuch;

scanf("%d", &howmuch);

counter = 0;

while ( counter < howmuch)

{

counter++;

printf("%d\n", counter);

}

return 0;

}

iii) if…else

syntax:

if( condition 1 )

statement1;

else if( condition 2 )

statement2;

else if( condition 3 )

statement3;

else

statement4;

Page 54: LAB CODE - MRCET

57

example:

#include<stdio.h>

int main(){

int x,y;

printf("Enter value for x :");

scanf("%d",&x);

printf("Enter value for y :");

scanf("%d",&y);

if ( x > y ){

printf("X is large number - %d\n",x);

}

else{

printf("Y is large number - %d\n",y);

}

return 0;

}

iv)switch

syntax:

swithch(int/char const)

{

Case const 1:stm1;

Break;

Case const 2:stmt2;

Break;

}

}

Default: stmt n;

Break;

}

Example:

#include <stdio.h>

int main() {

int color = 1;

printf("Please choose a color(1: red,2: green,3: blue):\n");

scanf("%d", &color);

switch (color) {

Page 55: LAB CODE - MRCET

58

case 1:

printf("you chose red color\n");

break;

case 2:

printf("you chose green color\n");

break;

case 3:

printf("you chose blue color\n");

break;

default:

printf("you did not choose any color\n");

}

return 0;

}

v) for Syntax:

for (initialization; condition; increment/decrement)

{

//body of the loop

}

Example:

#include <stdio.h>

int main()

{

int x;

/* The loop goes while x < 10, and x increases by one every loop*/

for ( x = 0; x < 10; x++ )

{

/* Keep in mind that the loop condition checks

the conditional statement before it loops again.

consequently, when x equals 10 the loop breaks.

x is updated before the condition is checked. */

printf( "%d\n", x );

}

getchar();

}

Viva questions:

1. How to find entered number is EVEN or ODD without using conditional statement (not using if.. else, while, do... while...., for....)

2. Write a function to swap any two numbers?

Page 56: LAB CODE - MRCET

59

3 .if "condition" printf("Hello"); else printf("World") What should be the condition, so the output will be HelloWorld.

4.How can we find out prime numbers from 1 to 50?

EXPERIMENT: 2

NAME OF THE EXPERIMENT:

Write a C program that uses functions to perform the following:

ii) Multiplication of Two Matrices*/

#include<stdio.h>

#include<conio.h>

Void main()

{

int a[10][10], b[10][10], m[10][10], i, j, p, q, r, s, k;

clrscr ();

printf(―enter the size of A Matrix‖);

scanf(―%d %d‖, &p, &q);

printf(―Enter the size of B Matrix ‖);

scanf(―%d %d ―, &r, &s);

if(q=r)

{

printf(―Enter the elements of matrix A:\n‖);

for(i=0; i<p; i++)

Page 57: LAB CODE - MRCET

60

{

for(j=0; j<q; j++)

{

scanf(―%d‖, &a[i][j]);

}

}

printf(―Enter the elements of matrix b:\n‖);

for(i=0; i<r; i++)

{

for(j=0; j<s; j++)

{

scanf(―%d‖, &b[i][j]);

}

}

for (i=0; i<p; i++)

{

for(j=0; j<s; j++)

{

m[i][j]=0;

for(k=0; k<q; k++)

{

m[i][j] =m[i][j] +a[i][j] * b[k][j];

}

}

}

Printf(―matrix multiplication is:\n‖);

for(i=0; i<p; i++)

{

for(j=0; j<s; j++)

{

Printf(―%d\t‖, m[i][j]);

}

` Printf(―\n‖);

}

}

else

printf(―matrix multiplication is not possible‖);

getch();

}

FAILURE CASES:

output:

1. Enter the size of a: 2 3

Enter the size of b: 2 3

Matrix multiplication is not possible.

Reason to fail: to do multiplication of matrices the number of columns in

matrix ―a‖ should be equal to number of rows in matrix ―b‖.

2. Enter the size of a: p q

Page 58: LAB CODE - MRCET

61

Enter the size of b: q s

Matrix multiplication is not possible.

Reason to fail: to do multiplication of matrices the number of columns in

matrix ―a‖ should be equal to number of rows in matrix ―b‖, and rows &

columns should be integer values.

3. Enter the size of a: 1.5 2

Enter the size of b: 2 3

Matrix multiplication is not possible.

Reason to fail: to do multiplication of matrices the number of columns in

matrix ―a‖ should be equal to number of rows in matrix ―b‖, and rows &

columns should be integer values.

4. Enter the size of a: 350 480

Enter the size of b: 480 620

Matrix multiplication is not possible.

Reason to fail: size of buffer will be not be sufficient to handle this

multiplication.

5. Enter the size of a: -1 -2

Enter the size of b: -2 3

Matrix multiplication is not possible.

Reason to fail: to do multiplication of matrices the number of columns in

matrix ―a‖ should be equal to number of rows in matrix ―b‖, and rows &

columns should be positive integer values.

viva questions:

2. syntax for multiplication

3. syntax for matrix multiplication

4. what the logic for matrix multiplication?

EXPERIMENT: 3

NAME OF THE EXPERIMENT: ATM system specifications and report the various bugs

Purpose:

This document describes the software requirements and specification (SRS) for an automated teller machine (ATM) network. The document is intended for the customer and the developer (designers, testers, maintainers). The reader is assumed to have basic knowledge of banking accounts and account services. Knowledge and understanding of Unified Modeling Language (UML) diagrams is also required. Scope:

The software supports a computerized banking network called ‗Bank24‘. The network enables customers to complete simple bank account services via automated teller machines (ATMs) that may be located off premise and that need not be owned and operated by the customer‘s bank. The ATM identifies a customer by a cash card and password. It collects information about a simple account transaction (e.g., deposit, withdrawal, transfer, bill payment), communicates the transaction information to the customer‘s bank, and dispenses cash to the customer. The banks provide their own software for their own computers. The ‗Bank24‘ software requires appropriate record keeping and security provisions. The software must handle concurrent accesses to the same account correctly.

Page 59: LAB CODE - MRCET

62

Intended Audience:

The intended audience of this SRS consists of:

Software designers

Systems engineers

Software developers

Software testers

Customers

The actors of the system are:

1. User 2. ATM Machine 3. Bank

Product Perspective:

An automated teller machine (ATM) is a computerized telecommunications device that provides the customers of a financial institution with access to financial

transactions in a public space without the need for a human clerk or bank teller. On most modern ATMs, the customer is identified by inserting a plastic ATM card with a magnetic stripe or a plastic smartcard with a chip, that contains a unique card number and some security information, such as an expiration date or CVC (CVV). Security is provided by the customer entering a personal identification number (PIN).

Product functions:

Using an ATM, customers can access their bank accounts in order to make cash withdrawals (or credit card cash advances) and check their account balances. The functions of the system are: 1. Login 2. Get Balance Information 3. Withdraw Cash 4. Transfer Funds Operating Environments: The hardware,software and technology used should have following specifications:

Ability to read the ATM card.

Ability to count the currency notes.

Touch screen for convenience.

Keypad(in case touchpad fails)

Continuous power supply.

Ability to connect to bank‘s network.

Ability to validate user.

Design/implementation constraints:

Login:

Validate Bank Card

Validate for Card Expiration Date

Validate that the card's expiration date is later than today's date

If card is expired, prompt error message "Card is expired"

Validate for Stolen or Lost Card

Validate that the card is not reported lost or stolen

Page 60: LAB CODE - MRCET

63

If card is lost, prompt error message, "Card has been reported lost"

If card is stolen, prompt error message, "Card has been reported stolen"

Validate for Disabled Card

Validate that the card is not disabled

If card is disabled, prompt error message, "Card has been disabled as of <expiration date>"

Validate for Locked Account

Validate that the account is not locked

If account is locked, prompt error message "Account is locked"

Validate PIN

Validate that the password is not blank

If PIN is blank, prompt error message "Please provide PIN"

Validate that the password entered matches the password on file

If password does not match, prompt error message "Password is Incorrect"

Lock Account

If number of consecutive unsuccessful logins exceeds three attempts, lock account

Maintain Consecutive Unsuccessful Login Counter

Increment Login Counter

For every consecutive Login attempt, increment logic counter by 1.

Reset login counter to 0 after login is successful.

Get Balance Information

Withdraw Cash

Transfer Funds

Assumptions and Dependencies:

Hardware never fails

ATM casing is impenetrable

Limited number of transactions per day (sufficient paper for receipts)

Limited amount of money withdrawn per day (sufficient money)

External Interface Requirements

User interfaces

The customer user interface should be intuitive, such that 99.9% of all new ATM users are able to complete their banking transactions without any assistance.

Hardware interfaces

The hardware should have following specifications:

Ability to read the ATM card

Ability to count the currency notes

Touch screen for convenience

Page 61: LAB CODE - MRCET

64

Keypad (in case touchpad fails)

Continuous power supply

Ability to connect to bank‘s network

Ability to take input from user

Ability to validate user

Software interfaces

The software interfaces are specific to the target banking software systems. At present, two known

banking systems will participate in the ATM network.

State Bank

Indian Overseas Bank

Safety requirements:

Must be safe kept in physical aspects, say in a cabin

Must be bolted to floor to prevent any kind of theft

Must have an emergency phone outside the cabin

There must be an emergency phone just outside the cabin

The cabin door must have an ATM card swipe slot

The cabin door will always be locked, which will open only when user swipes his/her ATM card in the slot & is validated as genuine

Security requirements:

Users accessibility is censured in all the ways

Users are advised to change their PIN on first use

Users are advised not to tell their PIN to anyone

The maximum number of attempts to enter PIN will be three

Some of the possible Bugs on ATM machine?

1. 1.Successful insertion of ATM card

2. Unsuccessful operation due to insert card in wrong angle

3. Unsuccessful operation due to invalid account Ex: other bank card or time expired card

4. successful entry of PIN number

5. un successful operation due to enter wrong PIN number 3times

6. successful selection of language

7. successful selection of account type

8. unsuccessful operation due to invalid account type

9. successful selection of withdraw operation

10. successful selection of amount to be withdrawl

11. successful withdraw operation

12. unsuccessful withdraw operation due to wrong denominations

13. unsuccessful withdraw operation due to amount is greater than day limit

14. unsuccessful withdraw operation due to lack of money in ATM

Page 62: LAB CODE - MRCET

65

15. unsuccessful withdraw operation due to amount is greater than possible balance

16. unsuccessful withdraw operation due to transactions is greater than day limit

17. unsuccessful withdraw operation due to click cancel after insert card

18. unsuccessful withdraw operation due to click cancel after insert card & pin number

19. unsuccessful withdraw operation due to click cancel after insert card , pin number & language

20. unsuccessful withdraw operation due to click cancel after insert card , pin number , language &account type

21. unsuccessful withdrawal operation due to click cancel after insert card , pin number , language ,account type & withdrawal operation

22. unsuccessful withdrawal operation due to click cancel after insert card , pin number , language ,account type ,withdrawal operation &amount to be withdraw.

Page 63: LAB CODE - MRCET

66

EXPERIMENT: 4

NAME OF THE EXPERIMENT: Test cases for Banking applications

Banking applications are considered to be one of the most complex applications in today‘s software development and testing industry. What makes Banking application so complex? What approach should be followed in order to test the complex workflows involved? In this article we will be highlighting different stages and techniques involved in testing Banking applications. The characteristics of a Banking application are as follows:

Multi tier functionality to support thousands of concurrent user sessions

Large scale Integration , typically a banking application integrates with numerous other applications such as Bill Pay utility and Trading accounts

Complex Business workflows

Real Time and Batch processing

High rate of Transactions per seconds

Secure Transactions

Robust Reporting section to keep track of day to day transactions

Strong Auditing to troubleshoot customer issues

Massive storage system

Disaster Management.

The above listed ten points are the most important characteristics of a Banking application.

Banking applications have multiple tiers involved in performing an operation. For Example, a banking application may have:

1. Web Server to interact with end users via Browser

2. Middle Tier to validate the input and output for web server

3. Data Base to store data and procedures

4. Transaction Processor which could be a large capacity Mainframe or any other Legacy system to carry out Trillions of transactions per second.

If we talk about testing banking applications it requires an end to end testing methodology involving multiple software testing techniques to ensure:

Total coverage of all banking workflows and Business Requirements

Functional aspect of the application

Security aspect of the application

Data Integrity

Concurrency

User Experience

Typical stages involved in testing Banking Applications are shown in below workflow which we will be discussing individually.

Page 64: LAB CODE - MRCET

67

1) Requirement Gathering:

Requirement gathering phase involves documentation of requirements either as Functional Specifications or Use Cases. Requirements are gathered as per customer needs and documented by Banking Experts or Business Analyst. To write requirements on more than one subject experts are involved as banking itself has multiple sub domains and one full fledge banking application will be the integration of all. For Example: A banking application may have separate modules for Transfers, Credit Cards, Reports, Loan Accounts, Bill Payments, Trading Etc.

2) Requirement Review:

The deliverable of Requirement Gathering is reviewed by all the stakeholders such as QA Engineers, Development leads and Peer Business Analysts. They cross check that neither existing business workflows nor new workflows are violated.

3) Business Scenario Preparations:

In this stage QA Engineers derive Business Scenarios from the requirement documents (Functions Specs or Use Cases); Business Scenarios are derived in such a way that all Business Requirements are covered. Business Scenarios are high level scenarios without any detailed steps, further these Business Scenarios are reviewed by Business Analyst to ensure all of Business Requirements are met and its easier for BAs to review high level scenarios than reviewing low level detailed Test Cases.

Page 65: LAB CODE - MRCET

68

4) Functional Testing:

In this stage functional testing is performed and the usual software testing activities are performed such as:

Test Case Preparation: In this stage Test Cases are derived from Business Scenarios, one Business Scenario leads to several positive test cases and negative test cases. Generally tools used during this stage are Microsoft Excel, Test Director or Quality Center. Test Case Review: Reviews by peer QA Engineers Test Case Execution: Test Case Execution could be either manual or automatic involving tools like QC, QTP or any other.

5) Database Testing:

Banking Application involves complex transaction which are performed both at UI level and Database level, Therefore Database testing is as important as functional

testing. Database in itself is an entirely separate layer hence it is carried out by database specialists and it uses techniques like

Data loading

Database Migration

Testing DB Schema and Data types

Rules Testing

Testing Stored Procedures and Functions

Testing Triggers

Data Integrity

6) Security Testing:

Security Testing is usually the last stage in the testing cycle as completing functional and non functional are entry criteria to commence Security testing. Security testing is one of the major stages in the entire Application testing cycle as this stage ensures that application complies with Federal and Industry standards. Security testing cycle makes sure the application does not have any web vulnerability which may expose sensitive data to an intruder or an attacker and complies with standards like OWASP.

In this stage the major task involves in the whole application scan which is carried out using tools like IBM Appscan or HP WebInspect (2 Most popular tools).

Once the Scan is complete the Scan Report is published out of which False Positives are filtered out and rest of the vulnerability are reported to Development team for fixing depending on the Severity.

Other Manual tools for Security Testing used are: Paros Proxy, Http Watch, Burp Suite, Fortify tools Etc.

Apart from the above stages there might be different stages involved like Integration Testing and Performance Testing.

In today‘s scenario majority of Banking Projects are using: Agile/Scrum, RUP and Continuous Integration methodologies, and Tools packages like Microsoft‘s VSTS and Rational Tools.

As we mentioned RUP above, RUP stands for Rational Unified Process, which is an iterative software development methodology introduced by IBM which comprises of four phases in which development and testing activities are carried out.

Page 66: LAB CODE - MRCET

69

Four phases are: i) Inception ii) Collaboration iii) Construction and iv) Transition RUP widely involves IBM Rational tools.

In this article we discussed how complex a Banking application could be and what are the typical phases involved in testing the application. Apart from that we also discussed current trends followed by IT industries including software development methodologies and tools.

Test cases for opening bank account

1. Input parameters checking

-Name

-Date of Birth

-Photo

-Address Proof

-Identity proof

-Introducers (if applicable)

-PAN card

-Initial deposit

-Whether checkbook / ATM card / Online banking facilities are needed or not

-Customer signature

Type of account

-Savings account

-Salary account

-Joint account

-Current account

-Secondary account

-RD account

-Account for a company

Test cases

-Checking mandatory input parameters

-Checking optional input parameters

-Check whether able to create account entity.

-Check whether you are able to deposit an amount in the newly created account (and thus updating the balance)

-Check whether you are able to withdraw an amount in the newly created account (after deposit) (and thus updating the balance)

-Check whether company name and its pan number and other details are provided in case of salary account

-Check whether primary account number is provided in case of secondary account

Page 67: LAB CODE - MRCET

70

-Check whether company details are provided in cases of company's current account

-Check whether proofs for joint account is provided in case of joint account

-Check whether you are able deposit an account in the name of either of the person in an joint account.

-Check whether you are able withdraw an account in the name of either of the person in an joint account.

-Check whether you are able to maintain zero balance in salary account

-Check whether you are not able to maintain zero balance (or mini balance) in non-salary account.

viva questions

1. Can you explain boundary value analysis?

2. Can you explain equivalence partitioning?

3. Can you explain random/monkey testing?

4. What are semi-random test cases?

5. What is negative and positive testing?

6. How did you define severity ratings in your project?

Page 68: LAB CODE - MRCET

71

EXPERIMENT: 5

NAME OF THE EXPERIMENT: Test plan document for library application

The Library Management System is an online application for assisting a librarian in managing a book library in a University. The system would provide basic set of features to add/update clients, add/update books, search for books, and manage check-in / checkout processes. Our test group tested the system based on the requirement specification.

INTRODUCTION

This test report is the result for testing in the LMS. It mainly focuses on two problems: what we will test and how we will test.

Result

GUI test

Pass criteria: librarians could use this GUI to interface with the backend library database without any difficulties

Result: pass

Database test

Pass criteria: Results of all basic and advanced operations are normal (refer to section 4)

Result: pass

Basic function test

Add a student

Pass criteria:

Each customer/student should have following attributes: Student ID/SSN

(unique), Name, Address and Phone number.

Result: pass

The retrieved customer information by viewing customer detail should contain

the four attributes.

Result: pass

Update/delete student

Pass criteria:

The record would be selected using the student ID

Result: pass

Updates can be made on full. Items only: Name, Address, Phone number

Result: pass

The record can be deleted if there are no books issued by user.

Result: Partially pass. When no books issued by user, he can be deleted. But

when there are books Issued by this user, he was also deleted. It is wrong.

The updated values would be reflected if the same customer's ID/SSN is called

for.

Result: pass

If customer were deleted, it would not appear in further search queries.

Result: pass

Add a book

Pass criteria:

Page 69: LAB CODE - MRCET

72

Each book shall have following attributes: Call Number, ISBN, Title, Author

name.

Result: pass

The retrieved book information should contain the four attributes.

Result: pass

Update/delete book

Pass criteria:

The book item can be retrieved using the call number

Result: did not pass. Can not retrive using the call number

The data items which can be updated are: ISBN, Title, Author name

Result: pass

The book can be deleted only if no user has issued it.

Result: partially pass. When no user has issued it, pass. When there are user

having issued it,

did not pass

The updated values would be reflected if the same call number is called for

Result: pass

If book were deleted, it would not appear in further search queries.

Result: pass

Search for book

Pass criteria:

The product shall let Librarian query books‘ detail information by their ISBN

number or Author or Title.

Result: pass

The search results would produce a list of books, which match the search

parameters with following Details: Call number, ISBN number, Title, Author

Result: pass

The display would also provide the number of copies which is available for issue

Result: pass

The display shall provide a means to select one or more rows to a user-list

Result: pass

A detailed view of each book should provide information about check-in/check

out status, with the borrower‘s information.

Result: pass

The search display will be restricted to 20 results per page and there would be

means to navigate from sets of search results.

Result: pass

The user can perform multiple searches before finally selecting a set of books for

check in or checkout. These should be stored across searches.

Result: pass

A book may have more than one copy. But every copy with the same ISBN

number should have same detail information.

Result: pass

The borrower‘s list should agree with the data in students‘ account

Result: pass

Check-in book

Pass criteria:

Librarians can check in a book using its call number

Page 70: LAB CODE - MRCET

73

Result: pass

The check-in can be initiated from a previous search operation where user has

selected a set of books.

Result: pass

The return date would automatically reflect the current system date.

Result: did not pass.

Any late fees would be computed as difference between due date and return

date at rate of 10 cents a day.

Result: did not pass

A book, which has been checked in once, should not be checked in again

Result: pass

Check-out book

Pass criteria:

Librarians can check out a book using its call number

Result: pass

The checkout can be initiated from a previous search operation where user has

selected a set of books.

Result: pass

The student ID who is issuing the book would be entered

Result: pass

The issue date would automatically reflect the current system date.

Result: did not pass

The due date would automatically be stamped as 5 days from current date.

Result: did not pass

A book, which has been checked out once, should not be checked out again

Result: pass

A student who has books due should not be allowed to check out any books

Result: did not pass

The max. No of books that can be issued to a customer would be 10. The system

should not allow checkout of books beyond this limit.

Result: pass

View book detail

Pass criteria:

This view would display details about a selected book from search operation

Result: pass

The details to be displayed are: Call number, IBN, Title, Author, Issue status (In

library or checked out), If book is checked out it would display, User ID & Name,

Checkout date, Due date

Result: for checkout date and due date, did not pass

Books checked in should not display user summary

Result: pass

Books checked out should display correct user details.

Result: pass

View student detail

Pass criteria:

Librarians can select a user record for detailed view

Result: pass

The detail view should show:

Page 71: LAB CODE - MRCET

74

a.User name, ID, Address & Phone number

Result: pass

b. The books issued by user with issue date, due date, call number, title

Result: did not pass

c. Late fees & Fines summary and total

Result: did not pass

The display should match existing user profile

Result: pass

The books checked out should have their statuses marked

Result: pass

The book search query should show the user id correctly.

Result: pass

Network test

Pass criteria: Results of operations (ping, ftp and ODBC connectivity check) are

normal

Result: did not test this item, because no enough machines and no available

envirenment.

viva questions

1. How to create a test plan document for Library Management System?

2. what is object repository

3. How many test cases can u write 1) File - open dialog box in notepad please

write 5 if software failed in customer environment what we called a)error b)fault

c)defect d)failure

4.What test plan should contains?

5. What is test strategy?

6. Define test Plan?What is the difference between Master Test Plan and Test Plan?

Page 72: LAB CODE - MRCET

75

EXPERIMENT: 6

NAME OF THE EXPERIMENT: Study of Any Testing Tool( WinRunner)

WinRunner is a program that is responsible for the automated testing of software. WinRunner is a Mercury Interactive‘s enterprise functional testing tool for Microsoft windows applications.

Importance of Automated Testing:

1. Reduced testing time

2. Consistent test procedures – ensure process repeatability and resource independence. Eliminates errors of manual testing

3. Reduces QA cost – Upfront cost of automated testing is easily recovered over the lifetime of the product

4. Improved testing productivity – test suites can be run earlier and more often

5. Proof of adequate testing

6. For doing Tedious work – test team members can focus on quality areas.

WinRunner Uses:

1. With WinRunner sophisticated automated tests can be created and run on an application.

2. A series of wizards will be provided to the user, and these wizards can create tests in an automated manner.

3. Another impressive aspect of WinRunner is the ability to record various interactions, and transform them into scripts. WinRunner is designed for testing graphical user interfaces.

4. When the user make an interaction with the GUI, this interaction can be recorded. Recording the interactions allows to determine various bugs that need to be fixed.

5. When the test is completed, WinRunner will provide with detailed information regarding the results. It will show the errors that were found, and it will also give important information about them. The good news about these tests is that they can be reused many times.

6. WinRunner will test the computer program in a way that is very similar to normal user interactions. This is important, because it ensures a high level of accuracy and realism. Even if an engineer is not physically present, the Recover manager will troubleshoot any problems that may occur, and this will allow the tests to be completed without errors.

7. The Recover Manager is a powerful tool that can assist users with various

scenarios. This is important, especially when important data needs to be recovered.

The goal of WinRunner is to make sure business processes are properly carried out. WinRunner uses TSL, or Test Script Language.

WinRunner Testing Modes

Context Sensitive

Context Sensitive mode records your actions on the application being tested in terms of the GUI objects you select (such as windows, lists, and buttons), while ignoring the physical location of the object on the screen. Every time you perform an operation on the application being tested, a TSL statement describing the object

Page 73: LAB CODE - MRCET

76

selected and the action performed is generated in the test script. As you record, WinRunner writes a unique description of each selected object to a GUI map.

The GUI map consists of files maintained separately from your test scripts. If the user interfaces of your application changes, you have to update only the GUI map, instead of hundreds of tests. This allows you to easily reuse your Context Sensitive test scripts on future versions of your application.

To run a test, you simply play back the test script. WinRunner emulates a user by moving the mouse pointer over your application, selecting objects, and entering keyboard input. WinRunner reads the object descriptions in the GUI map and then searches in the application being tested for objects matching these descriptions. It can locate objects in a window even if their placement has changed.

Analog

Analog mode records mouse clicks, keyboard input, and the exact x- and y-coordinates traveled by the mouse. When the test is run, WinRunner retraces the mouse tracks. Use Analog mode when exact mouse coordinates are important to

your test, such as when testing a drawing application.

The WinRunner Testing Process

Testing with WinRunner involves six main stages:

1. Create the GUI Map

The first stage is to create the GUI map so WinRunner can recognize the GUI objects in the application being tested. Use the RapidTest Script wizard to review the user interface of your application and systematically add descriptions of every GUI object to the GUI map. Alternatively, you can add descriptions of individual objects to the GUI map by clicking objects while recording a test.

2. Create Tests

Next is creation of test scripts by recording, programming, or a combination of both. While recording tests, insert checkpoints where we want to check the response of the application being tested. We can insert checkpoints that check GUI objects, bitmaps, and databases. During this process, WinRunner captures data and saves it as expected results—the expected response of the application being tested.

3. Debug Tests

Run tests in Debug mode to make sure they run smoothly. One can set breakpoints, monitor variables, and control how tests are run to identify and isolate defects. Test results are saved in the debug folder, which can be discarded once debugging is finished.

When WinRunner runs a test, it checks each script line for basic syntax errors, like incorrect syntax or missing elements in If, While, Switch, and For statements. We

can use the Syntax Check options (Tools >Syntax Check) to check for these types of syntax errors before running your test.

4. Run Tests

Tests can be run in Verify mode to test the application. Each time WinRunner encounters a checkpoint in the test script, it compares the current data of the application being tested to the expected data captured earlier. If any mismatches are found, WinRunner captures them as actual results.

5. View Results

Page 74: LAB CODE - MRCET

77

Following each test run, WinRunner displays the results in a report. The report details all the major events that occurred during the run, such as checkpoints, error messages, system messages, or user messages.

If mismatches are detected at checkpoints during the test run, we can view the expected results and the actual results from the Test Results window. In cases of bitmap mismatches, one can also view a bitmap that displays only the difference between the expected and actual results.

We can view results in the standard WinRunner report view or in the Unified report view. The WinRunner report view displays the test results in a Windows-style viewer. The Unified report view displays the results in an HTML-style viewer (identical to the style used for QuickTest Professional test results).

6. Report Defects

If a test run fails due to a defect in the application being tested, one can report information about the defect directly from the Test Results window.

This information is sent via e-mail to the quality assurance manager, who tracks

the defect until it is fixed.

Using Winrunner Window

Before you begin creating tests, you should familiarize yourself with the WinRunner main window.

1.4.1. To start WinRunner:

Choose Programs > WinRunner > WinRunner on the Start menu.

The first time you start WinRunner, the Welcome to WinRunner window and the ―What‘s New in WinRunner‖ help open. From the Welcome window you can create a new test, open an existing test, or view an overview of WinRunner in your default browser.

If you do not want this window to appear the next time you start WinRunner, clear the Show on Startup check box. To show the Welcome to WinRunner window upon startup from within WinRunner, choose Settings > General Options, click the Environment tab, and select the Show Welcome screen check box.

1.4.2. The Main WinRunner Window

The main WinRunner window contains the following key elements:

WinRunner title bar

Menu bar, with drop-down menus of WinRunner commands

Standard toolbar, with buttons of commands commonly used when running a test

User toolbar, with commands commonly used while creating a test

Status bar, with information on the current command, the line number of the insertion point and the name of the current results folder

The Standard toolbar provides easy access to frequently performed tasks, such as opening, executing, and saving tests, and viewing test results.

Standard Toolbar

The User toolbar displays the tools you frequently use to create test scripts. By default, the User toolbar is hidden. To display the User toolbar, choose Window > User Toolbar. When you create tests, you can minimize the WinRunner window and work exclusively from the toolbar.

Page 75: LAB CODE - MRCET

78

The User toolbar is customizable. You choose to add or remove buttons using the Settings > Customize User Toolbar menu option. When you re-open WinRunner, the User toolbar appears as it was when you last closed it.

The commands on the Standard toolbar and the User toolbar are described in detail in subsequent lessons.

Note that you can also execute many commands using softkeys. Softkeys are keyboard shortcuts for carrying out menu commands. You can configure the softkey combinations for your keyboard using the Softkey Configuration utility in your WinRunner program group. For more information, see the ―WinRunner at a Glance‖ chapter in your WinRunner User’s Guide.

Now that you are familiar with the main WinRunner window, take a few minutes to explore these window components before proceeding to the next lesson.

The Test Window

You create and run WinRunner tests in the test window. It contains the following

key elements:

Test window title bar, with the name of the open test

Test script, with statements generated by recording and/or programming in TSL, Mercury Interactive‘s Test Script Language

Execution arrow, which indicates the line of the test script being executed during a test run, or the line that will next run if you select the Run from arrow option

Insertion point, which indicates where you can insert or edit text

Viva questions

1. What is the purpose of set window command?

2. Why don‘t we normally load the GUI maps through start up scripts?

3. How do you unload the GUI map?

4. How do you configure GUI map?

5. What is the purpose of GUI spy?

6. What are the virtual objects and how do you learn them?

7. What is the use of Virtual Object Wizard and how it is used?

Page 76: LAB CODE - MRCET

79

EXPERIMENT: 7

NAME OF THE EXPERIMENT: Study of any web testing tool (e.g. Selenium)

7.1 What is Selenium?

JavaScript framework that runs in your web browser Works anywhere JavaScript is supported Hooks for many other languages Java, Ruby, Python Can simulate a user navigating through pages and then assert for specific marks on the pages All you need to really know is HTML to start using it right away

Where to get it?

You can use Selenium-Core and customize everything But it is easier to just get a Firefox plug-in ―Selenium-IDE‖ that helps you ―record‖ test cases You can record how an app is being used and then play back those recordings followed by asserts Get everything at: www.openqa.org/selenium/

7.2 Selenium IDE

The root of web application you want to test. The list of actions in the actual test case to execute. The log of the events that were executed, including any errors or warning that may have occurred.

Execution Commands Try the test in the Web based TestRunner Reference of the currently selected command Record test actions Specify commands, including asserts

Test Creation Demo

• Create test case to log into the gallery

• Create test case to log out of the gallery

Page 77: LAB CODE - MRCET

80

Start pixory

Connect to the server

Page 78: LAB CODE - MRCET

81

Go to the Login Screen

Hit the Record Button

Page 79: LAB CODE - MRCET

82

Type in Username and Password

IDE should update

Page 80: LAB CODE - MRCET

83

Hit submit

Hit record again to stop

Page 81: LAB CODE - MRCET

84

Add assert Text Present and type the text to search for

Page 82: LAB CODE - MRCET

85

Hit play to make sure your test is successful

7.3 Creating a Test Suite:

<html>

<head>

<meta content="text/html; charset=ISO-8859-1"

http-equiv="content-type">

<title>Demo Test Suite</title>

</head>

<body>

<table id="suiteTable">

<tbody>

<tr><td>

<b>Demo Test Suite</b>

</td></tr>

<tr><td>

<a href="./testLogin.html">TestLogin</a>

</td></tr>

<tr><td>

<a href="./testLogout.html">TestLogout</a>

Page 83: LAB CODE - MRCET

86

</td></tr>

</tbody>

</table>

</body>

</html>

A Test Suite in Selenium is just an HTML file that contains a table of links to tests

Executing the Test Suite

• Selenium Core is a collection of Javascript and HTML with iFrames

• Due to security concerns Core must be deployed within the same server as the application being hosted

• The simplest way to run Pixory is to just run the Java application and let it use its own server

• Problems using Core with Pixory

• Selenium IDE is a plug-in for Firefox and thus can go around these restrictions

Running the Test Suite

• We basically want to execute the test suite using the Selenium IDE plug-in TestRunner.html

chrome://selenium-ide/content/selenium/TestRunner.html? baseURL=<BASE>&test=file:///<TEST SUITE FILE>&auto=true

chrome://selenium-ide/content/selenium/TestRunner.html?

baseURL=http://localhost:8081&test=file:///Users/ms333/

projects/classes/running/v_and_v/hw3/selenium/test/

TestSuite.html&auto=true

Test Suite

Page 84: LAB CODE - MRCET

87

Test Runner Control :

Test Runner Demo:

• Execute Tests created inside the Firefox Test Runner

viva questions

1. What is Selenium?

2. What are the main components of Selenium testing tools?

3. What is Selenium IDE?

4. What is the use of context menu in Selenium IDE?

5. Can tests recorded using Selenium IDE be run in other browsers?

6. What are the advantage and features of Selenium IDE?

7. What are the disadvantages of Selenium IDE tool?

8. What is Selenium Grid?

9. How Selenium Grid works?

Page 85: LAB CODE - MRCET

88

EXPERIMENT: 8

NAME OF THE EXPERIMENT: Study of Any Bug Tracking Tool (Bugzilla)

8.1 Introduction

Bugzilla is a popular bug-tracking system that allows teammates and developers to track outstanding bug, Assign, track, and resolve error fixes and conflict resolutions using the Bugzilla database Communicate with teammates, Submit and review patches and Manage quality assurance (QA).

Bugzilla is one example of a class of programs called "Defect Tracking Systems", or, more commonly, "Bug-Tracking Systems". Defect Tracking Systems allow individual or groups of developers to keep track of outstanding bugs in their product effectively. Bugzilla was originally written by Terry Weissman in a programming language called "TCL", to replace a crappy bug-tracking database used internally for Netscape Communications. Terry later ported Bugzilla to Perl from TCL, and in Perl it remains to this day. Most commercial defect-tracking

software vendors at the time charged enormous licensing fees, and Bugzilla quickly became a favorite of the open-source crowd. It is now the de-facto standard defect-tracking system against which all others are measured.

8.2Features

Bugzilla has matured immensely, and now boasts many advanced features. These include:

integrated, product-based granular security schema

inter-bug dependencies and dependency graphing

advanced reporting capabilities

a robust, stable RDBMS back-end

extensive configurability

a very well-understood and well-thought-out natural bug resolution protocol

email, XML, console, and HTTP APIs

available integration with automated software configuration management systems, including Perforce and CVS

too many more features to list

8.3 Anatomy of a Bug

The core of Bugzilla is the screen which displays a particular bug. It‘s a good place to explain some Bugzilla concepts.

1. Product and Component: Bugs are divided up by Product and Component, with a Product having one or more Components in it. For example, bugzilla.mozilla.org‘s "Bugzilla" Product is composed of several Components:

Administration: Administration of a Bugzilla installation.

Bugzilla-General: Anything that doesn‘t fit in the other components, or spans multiple components.

Creating/Changing Bugs: Creating, changing, and viewing bugs.

Documentation: The Bugzilla documentation, including The Bugzilla Guide.

Email: Anything to do with email sent by Bugzilla.

Page 86: LAB CODE - MRCET

89

Installation: The installation process of Bugzilla.

Query/Bug list: Anything to do with searching for bugs and viewing the bug lists.

Reporting/Charting: Getting reports from Bugzilla.

User Accounts: Anything about managing a user account from the user‘s perspective. Saved queries, creating accounts, changing

User Interface: General issues having to do with the user interface cosmetics (not functionality) including cosmetic issues, HTML

2. Status and Resolution: These define exactly what state the bug is in - from not even being confirmed as a bug, through to being fixed and the fix confirmed by Quality Assurance. The different possible values for Status and Resolution on your installation should be documented in the context-sensitive help for those items.

3. Assigned To: The person responsible for fixing the bug.

4. *QA Contact: The person responsible for quality assurance on this bug.

5. *URL: A URL associated with the bug, if any.

6. Summary: A one-sentence summary of the problem.

7. *Status Whiteboard: A free-form text area for adding short notes and tags to a bug.

8. *Keywords: The administrator can define keywords which you can use to tag and categories bugs - e.g. The Mozilla Project has keywords like crash and regression.

9. Platform and OS: These indicate the computing environment where the bug was found.

10. Version: The "Version" field is usually used for versions of a product which have been released, and is set to indicate which versions of a Component have the particular problem the bug report is about.

11. Priority: The bug assignee uses this field to prioritize his or her bugs. It‘s a good idea not to change this on other people‘s bugs.

12. Severity: This indicates how severe the problem is - from blocker ("application unusable") to trivial ("minor cosmetic issue"). You can also use this field to indicate whether a bug is an enhancement request.

13. *Target: A future version by which the bug is to be fixed. e.g. The Bugzilla Project‘s milestones for future Bugzilla versions are 2.18, 2.20, 3.0, etc. Milestones are not restricted to numbers, thought - you can use any text strings, such as dates.

14. Reporter: The person who filed the bug.

15. CC list: A list of people who get mail when the bug changes.

16. *Time Tracking: This form can be used for time tracking. To use this feature, you have to be blessed group membership specified by the ―time tracking group‖ parameter.

Orig. Est.: This field shows the original estimated time.

Current Est.: This field shows the current estimated time. This number is calculated from ―Hours Worked‖ and ―Hours Left‖.

Hours Worked: This field shows the number of hours worked.

Page 87: LAB CODE - MRCET

90

Hours Left: This field shows the ―Current Est.‖ - ―Hours Worked‖. This value + ―Hours Worked‖ will become the new Current Est.

%Complete: This field shows what percentage of the task is complete.

Gain: This field shows the number of hours that the bug is ahead of the ―Orig. Est.‖.

Deadline: This field shows the deadline for this bug.

17. Attachments: You can attach files (e.g. test cases or patches) to bugs. If there are any attachments, they are listed in this section. Attachments are normally stored in the Bugzilla database, unless they are marked as Big Files, which are stored directly on disk.

18. *Dependencies: If this bug cannot be fixed unless other bugs are fixed (depends on), or this bug stops other bugs being fixed (blocks), their numbers are recorded here.

19. *Votes: Whether this bug has any votes.

20. Additional Comments: You can add your two cents to the bug discussion here, if you have something worthwhile to say.

8.4 Life Cycle of a Bug

The life cycle of a bug, also known as workflow, is customizable to match the needs of organization. Below Figure-1 contains a graphical representation of the default workflow using the default bug statuses.

Page 88: LAB CODE - MRCET

91

Figure-1. Lifecycle of a Bugzilla Bug

8.5 Searching for Bugs

The Bugzilla Search page is the interface where we can find any bug report, comment, or patch currently in the Bugzilla system. The Search page has controls for selecting different possible values for all of the fields in a bug. For some fields, multiple values can be selected. In those cases, Bugzilla returns bugs where the content of the field matches any one of the selected values. If none is selected, then

the field can take any value. After a search is run, we can save it as a Saved Search, which will appear in the page footer. If we are in the group defined by the "query share group" parameter, we may share your queries with other users; see Saved Searches for more details.

8.5.1. Boolean Charts

Highly advanced querying is done using Boolean Charts. The Boolean charts further restrict the set of results returned by a query. There are three fields in each row of a boolean search.

Field: the items being searched

Operator: the comparison operator

Page 89: LAB CODE - MRCET

92

Value: the value to which the field is being compared

1. Pronoun Substitution

2. Negation

3. Multiple Charts

8.5.2. Quick search

Quick search is a single-text-box query tool which uses meta characters to indicate what is to be searched. For example, typing "foot bar" into Quick search would search for "foo" or "bar" in the summary and status whiteboard of a bug; adding ": Baz Product" would search only in that product. we can use it to find a bug by its number or its alias, too.

8.5.3. Case Sensitivity in Searches

Bugzilla queries are case-insensitive and accent-insensitive, when used with either MySQL or Oracle databases. When using Bugzilla with PostgreSQL, however, some queries are case-sensitive. This is due to the way PostgreSQL handles case and accent sensitivity.

8.5.4. Bug Lists

If we run a search, a list of matching bugs will be returned. The format of the list is configurable. For example, it can be sorted by clicking the column headings. Other useful features can be accessed using the links at the bottom of the list:

Long Format: this gives a large page with a non-editable summary of the fields of each bug.

XML: get the bug list in the XML format.

CSV: get the bug list as comma-separated values, for import into e.g. a spreadsheet.

Feed: get the bug list as an Atom feed. Copy this link into our favorite feed reader. If we are using Firefox, you can also save the list

iCalendar: Get the bug list as an iCalendar file. Each bug is represented as a to-do item in the imported calendar.

Change Columns: change the bug attributes which appear in the list.

Change several bugs at once: If our account is sufficiently empowered, and more than one bug appear in the bug list, this link is displayed

Send mail to bug assignees: If more than one bug appear in the bug list and there are at least two distinct bug assignees, this links is displayed

Edit Search: If we didn‘t get exactly the results you were looking for, we can return to the Query page through this link and make small Remember

Search As: we can give a search a name and remember it; a link will appear in our page footer giving you quick access to

8.5.5. Adding/removing tags to/from bugs

We can add and remove tags from individual bugs, which let you find and manage them more easily. Creating a new tag automatically generates a saved search - whose name is the name of the tag - which lists bugs with this tag. This saved search will be displayed in the footer of pages by default, as all other saved searches.

8.6. Filing Bugs

8.6.1. Reporting a New Bug

Page 90: LAB CODE - MRCET

93

The procedure for filing a bug is as follows:

1. Click the ―New‖ link available in the footer of pages, or the ―Enter a new bug report‖ link displayed on the home page of the Bugzilla installation.

2. We first have to select the product in which we found a bug.

3. We now see a form where you can specify the component. the version of the program we were using, the Operating System and platform our program is running on and the severity of the bug.

4. We now have to give a short but descriptive summary of the bug you found.

5. As we file the bug, we can also attach a document (test case, patch, or screenshot of the problem).

6. Depending on the Bugzilla installation we are using and the product in which we are filing the bug, we can also request developers to consider our bug in different ways.

7. Now is a good time to read our bug report again. Remove all misspellings, otherwise our bug may not be found by developers running queries for some specific words, and so our bug would not get any attention. Also make sure we didn‘t forget any important information developers should know in order to reproduce the problem, and make sure our description of the problem is explicit and clear enough.

8.6.2. Clone an Existing Bug

Starting with version 2.20, Bugzilla has a feature that allows us to clone an existing bug. The newly created bug will inherit most settings from the old bug. This allows us to track more easily similar concerns in a new bug. To use this, go to the bug that we want to clone, and then click the ―Clone This Bug‖ link on the bug page. This will take us to the ―Enter Bug‖ page that is filled with the values that the old bug has we can change those values and/or texts if needed.

8.7 Disadvantages

Despite its current robustness and popularity, Bugzilla faces some near-term challenges, such as

reliance on a single database,

a lack of abstraction of the user interface and program logic,

verbose email bug notifications,

a powerful but daunting query interface,

little reporting configurability,

problems with extremely large queries,

some unsupportable bug resolution options,

little internationalization (although non-US character sets are accepted for comments), and

Dependence on some nonstandard libraries.

Despite these small problems, Bugzilla is very hard to beat. It is under very active development to address the current issues, and continually gains new features.

Page 91: LAB CODE - MRCET

94

Figure-2: Bugzilla main screen

Figure-3: Bugzilla sample test report

viva questions

1. What is Bugzilla?

2. What are Bugzilla‘s features?

3. What are Bugzilla Components?

4. How do I change my user name in Bugzilla?

5. What is about the Bug List page?

6. How to Write a Useful Bug Report with Bugzilla

Page 92: LAB CODE - MRCET

95

EXPERIMENT: 9

NAME OF THE EXPERIMENT:

Study of Any Test Management Tool ( Test Director)

Test Director is a global test management solution which provides communication, organization, documentation and structure to the testing project.

Test Director is used for

Mapping Requirements to User acceptance test cases

Test Planning by placing all the test cases and scripts in it.

Manual testing by defining test steps and procedures

Test Execution status

Defect Management

Test Director Testing Process :

TestDirector offers an organized framework for testing applications before they are deployed. Since test plans evolve with new or modified application requirements, you need a central data repository for organizing and managing the testing process. TestDirector guides through the requirements specification, test planning, test execution, and defect tracking phases of the testing process.

The TestDirector testing process includes four phases:

Specifying Requirements

Requirements are linked to tests and defects to provide complete traceability and aid the decision-making process.

See what percent of requirements are covered by tests

Each requirement in the tree is described in detail, and can include any relevant attachments. The QA tester assigns the requirement a priority level which is taken into consideration when the test team creates the test plan

Import from Microsoft Word or third party RM tool

Planning Tests

The Test Plan Manager enables to divide application according to functionality. Application can be divided into units, or subjects, by creating a test plan tree.

Define subjects according to:

o Application functionality-such as editing, file operations, and reporting

o Type of testing-such as functional, user interface, performance, and load

As the tests are also linked to defects, this helps ensure compliance with testing requirements throughout the testing process

Running Tests

As the application constantly changes, using test lab, run manual and automated tests in the project in order to locate defects and assess quality.

By creating test sets and choosing which tests to include in each set, test suite can be created. A test set is a group of tests in a Test Director project database designed to achieve specific testing goals.

Page 93: LAB CODE - MRCET

96

Tests can be run manually or scheduled to run automatically based on application dependencies.

Tracking Defects:

Locating and repairing application defects efficiently is essential to the testing process. Defects can be detected and added during all stages of the testing process. In this phase you perform the following tasks:

This tool features a sophisticated mechanism for tracking software defects, enabling Testing Team and the project Team to monitor defects closely from initial detection until resolution

By linking TestDirector to e-mail system, defect tracking information can be shared by all Development and Management Teams, Testing and Wipro Software Quality Assurance personnel

System Requirements for TestDirector:

Server System configuration : 128 MB of RAM , 500 MB of free disk space, Win NT server, Win 2K server, IIS 5.0, MSAccess/Oracle 7.x,8.x,9/MS SQL Server

Client System configuration : 64 MB of RAM , 10 MB of free disk space, Win 95/98/NT/2K/XP, IE 5 , Netscape 4.7

viva questions

1. Orchestrate Vs Data stage Parallel Extender?

2. What is an Exception? What are types of Exception?

3. What are Routines and where/how are they written and have you written any routines before?

4. Types of vies in Data stage Director?

5. What are the command line functions that import and export the DS jobs?

6. How many types of database triggers can be specified on a table? What are they? 7. What is NLS in data stage? How we use NLS in Data stage? What advantages in that? At the time of ins. ..

8. What are types of Hashed File?

9. What are the data types an available in PL/SQL?

Page 94: LAB CODE - MRCET

97

EXPERIMENT: 10

NAME OF THE EXPERIMENT: Study of any open source testing tool (TestLink)

Testlink is an open source test management tool. It enables creation and organization of test cases and helps manage into test plan. Allows execution of test cases from test link itself. One can easily track test results dynamically, generate reports, generate test metrics,prioritize test cases and assign unfinished tasks.

Its a web based tool with GUI, which provides an ease to develop test cases, organize test cases into test plans, execute these test cases and generate reports.

Test link exposes API, written in PHP, can help generate quality assurance dashboards. The functions like AddTestCase ToTestPlan, Assign Requirements,Create TestCase etc. helps create and organize test cases per test plan. Functions like GetTestCasesForTestPlan, GetLastExecutionResult allows one to create quality assurance dashboard.

TestLink enables easily to create and manage Test cases as well as organize them into Test plans. These Test plans allow team members to execute Test cases and track test results dynamically, generate reports, trace software requirements, prioritize and assign tasks. Read more about implemented features and try demo pages.

Overall structure

There are three cornerstones: Product, Test Plan and User. All other data are relations or attributes for this base. First, definition of a couple of terms that are used throughout the documentation.

Products and Test Plans

Product: A Product is something that will exist forever in TestLink. Products will undergo many different versions throughout their life times. Product includes Test Specification with Test Cases and should be sorted via Keywords.

Test Plan: Test Plans are created when you‘d like to execute test cases. Test plans can be

made up of the test cases of one or many Products. Test Plan includes Builds, Test Case Suite and Test Results.

User: An User has a Role, that defines available TestLink features.

Test Case Categorization

TestLink breaks down the test case structure into three levels Components, Categories, and test cases. These levels are persisted throughout the application.

Component: Components are the parents of Categories. Each Component can have many

Categories.

Category: Categories are the parents of test cases. Each Category can have many test cases.

Test Case: Test cases are the fundamental piece of TestLink.

Test Specification: All Components, Categories and test cases within Product.

Test Case Suite: All Components, Categories and test cases within Test Plan.

Test Specification

Page 95: LAB CODE - MRCET

98

Creating Test Cases

Tester must follow this structure: Component, Category and test case. At first you create Component(s) for your Product. Component includes Categories. Category has the similar meaning but is second level of Test Specification and includes just Test Cases.

User can also copy or move Test Cases.

Test Cases have following parts:

• Title: could include either short description or abbreviation (e.g. TL-USER-LOGIN)

• Summary: should be really short; just for overview.

• Steps: describe test scenario (input actions); can also include precondition and

cleanup information here.

• Expected results: describe checkpoints and expected behaviour a tested Product

or system.

Deleting Test Cases

Test cases, Categories, and Components may be deleted from a test plan by users with lead permissions from the ―delete test cases‖ screen. Deleting data may be useful when first creating a test plan since there are no results. However, Deleting test cases will cause the loss of all results associated with them. Therefore, extreme caution is recommended when using this functionality.

Requirements relation

Test cases could be related with software/system requirements as n to n. The functionality must be enabled for a Product. User can assign Test Cases and Requirements via link Assign Requirements in the main screen.

Test Plans

Test plan contains name, description, collection a chosen test cases, builds, test results, milestones, tester assignment and priority definition.

Creating a new Test Plan

Test Plans may be deleted from the ―Create test plan‖ page (link ―Create Test Plan‖) by users with lead privileges. Test plans are the basis for test case execution. Test plans are made up of test cases imported from Products at a specific point of time. Test plans can only be created by users with lead privileges. Test plans may be created from other test plans. This allows users to create test plans from test cases that at a desired point in time. This may be necessary when creating a test plan for a patch. In order for a user to see a test plan they must have the propper rights. Rights may be assigned (by leads) in the define User/Project Rights section. This is an important thing to remember when users tell you they can‘t see the project they are working on.

Test Execution

Test execution is available when:

1. A Test Specification is written.

2. A Test Plan is created.

3. Test Case Suite (for the Test Plan) is defined.

4. A Build is created.

5. The Test plan is assigned to testers (otherwise they cannot navigate to this Test

Plan).

Select a required Test Plan in main page and navigate to the ‗Execute tests‘ link. Left pane serves for navigation in Test Case Suite via tree menu, filtering and define a tested build.

Page 96: LAB CODE - MRCET

99

Test Status

Execution is the process of assigning a result (pass, fail, blocked) to a test case for a specific build. ‗Blocked‘ test case is not possible to test for some reason (e.g. a problem in configuration disallows to run a tested functionality).

Insert Test results

Test Results screen is shown via click on an appropriate Component, Category or test case in navigation pane. The title shows the current build and owner. The colored bar indicate status of the test case. Yellow box includes test scenario of the test case.

Updated Test Cases: If users have the proper rights they can go to the ―Update modified test case‖ page through the link on main page. It is not necessary for users to update test cases if there has been a change (newer version or deleted).

Advantages: 1. Easy in tracking test cases (search with keyword, test case id, version etc) 2. We can add our custom fields to test cases.

3. Allocating the work either test case creation/execution any kind of documents is easy 4. When a test case is updated the previous version also can be tracked 5. We can generate results build wise 6. Test plans are created for builds and work allocations can be done. 7. Report is one of the awesome functionality present in the Test link, it generates reports in desired format like HTML/ CSV /Excel and we can create graphs too. 8. And the above all is done on the privileges based which is an art of the test link

Example of TestLink workflow:

1. Administrator creates a Product ―Fast Food‖ and a user Adam with rights ―leader‖ and Bela with rights ―Senior tester‖. 2. Adam imports Software Requirements and for part of these requirements generates empty Test cases. 3. Bela describe test sneario of these Test cases that are organized according to Components and Categories. 4. Adam creates Keyword: ―Regression‖ and assignes this keyword to ten of these test cases. 5. Adam creates a Test Plan ―Fish & Chips‖, Build ―Fish 0.1‖ and add Test Cases with keywords ―Regression‖. 6. Adam and Bela execute and record the testing with result: 5 passed, 1 failed and 4 are blocked. 7. Developers make a new build ―Fish 0.2‖ and Bela tests the failed and blocked test cases only. Exceptionaly all these five Test cases passed.

8. Manager would like to see results. Administrator explain him that he can create account himself on the login page. Manager do it. He has ―Guest‖ rights and could

see results and Test cases. He can see that everything passed in overal report and problems in build ―Fish 0.1‖ in a report for particular Build. But he can change nothing. Viva questions

1. What is difference between Performance Testing, Load Testing and Stress Testing? 2. What are the advantages? 3. What are the test plans? 4. Examples for test plan?

Page 97: LAB CODE - MRCET

MOBILE APPLICATION DEVELOPMENT LAB

INDEX

SNO NAME OF THE EXPERIMENTS Page Nos

1 week -1 Installation Of Java Wireless Tool Kit(J2me) 1-2

2 week -2 Working With J2me Features 2-13

3 week -3 Threads & High Level Ui 13-32

4 week -4 Working On Drawing And Images 32-42

5 week -5 Developing Networked Applications

Using The Wireless Toolkit 42-47

6 week -6 Authentication With A Web Server 47-51

7 week – 7& 8 Web Application Using J2me 51-59

Page 98: LAB CODE - MRCET

Objective:

In this lab, a student is expected to design, implement, document and present a mobile

client/server system using standard Java and Java 2 Micro Edition (J2ME) platform.

Specifically it is required to design and implement a system that consists mainly of a mobile

client (MC) and a Proxy Server (PS). MC will be written in J2ME, MIDP 2.0, while PS will

be written in standard Java. It is necessary to use a mobile phone emulator to develop and

demonstrate the experiments.

It may be necessary to use other components or existing resources (servers) as needed. For

instance a database local to PS or a web service available on the Internet that can be invoked

by the PS.

Week - 1: Installation of Java Wireless Toolkit (J2ME)

1) If the Java Development Kit (JDK) is not theory only having the Java Runtime

Environment (JRE) installed, install the latest JDK from

http://java.sun.com/javase/downloads/index.jsp. Current stable release of Java is JDK 6

Update 7 but check the web page in case there are newer non-beta releases available.

2) Next, download the Java Wireless Toolkit (formerly called J2ME Wireless Toolkit) from:

http://java.sun.com/products/sjwtoolkit/download.html.

3) Run the installer (for example, for Windows it is: sun_java_wireless_toolkit- 2_5_2-

windows.exe). The installer checks whether a compatible Java environment has been pre-

installed. If not, it is necessary to uninstall old versions of Java and perform Step 1 again.

Once after successful installation of Java and the tool kit compile this program and run the

following program in the toolkit.

Steps to run this program in toolkit:

Start -> All Programs -> Sun Java Tool Kit -> Wireless Tool Kit

Click New Project – Enter Project Name -> Enter Class Name -> Click on Create Project.

Choose appropriate API Selection and Configurations.

Place Java Source file in WTK2.1 / WTK2.2\apps\projectname\src

Build the Project.

Run the Project.

import javax.microedition.lcdui.*;

import javax.microedition.midlet.*;

public class HelloWorld extends MIDlet{

private Form form;

private Display display;

public HelloWorld(){

super();

}

public void startApp(){

form = new Form("Hello World");

String msg = "Hello World!!!!!!!";

form.append(msg);

display = Display.getDisplay(this);

display.setCurrent(form);

Page 99: LAB CODE - MRCET

}

public void pauseApp(){}

public void destroyApp(boolean unconditional){

notifyDestroyed();

}

}

Week - 2 Working with J2ME Features:

Working with J2ME Features: Say, creating a Hello World program Experiment with

the most basic features and mobile application interaction concepts (lists, text boxes,

buttons, radio boxes, soft buttons, graphics, etc)

2.1 Create a program which creates to following kind of menu.

* cut

* copy

* past

* delete

* select all

* unselect all

Program:

Source code:

import javax.microedition.midlet.*;

import javax.microedition.lcdui.*;

public class MenuCreation extends MIDlet implements CommandListener {

public ChoiceGroup ch;

public Form form;

public Display display;

public Command command;

public StringItem st;

public MenuCreation()

{

display=Display.getDisplay(this);

Page 100: LAB CODE - MRCET

ch=new ChoiceGroup("Edit",Choice.EXCLUSIVE);

ch.append("cut",null);

ch.append("copy",null);

ch.append("paste",null);

ch.append("delete",null);

ch.append("select all",null);

ch.append("unselect all",null);

ch.setSelectedIndex(1, true);

command=new Command("Select list item",Command.OK,1);

form=new Form("");

form.append(ch);

form.addCommand(command);

form.setCommandListener(this);

st=new StringItem("","");

}

public void startApp() {

display.setCurrent(form);

}

public void pauseApp() {

}

public void destroyApp(boolean unconditional) {

}

public void commandAction(Command command,Displayable displayable)

{

if(command==command)

{

st.setText("");

st.setText("your selected option is "+ch.getString(ch.getSelectedIndex()));

form.append(st);

}

}

}

Output:

Page 101: LAB CODE - MRCET

2.2 Event Handling.

Create a menu which has the following options:

* cut - can be on/off

* copy - can be on/off

* paste - can be on/off

* delete - can be on/off

* select all - put all 4 options on

* unselect all - put all 4 options off

Program:

import javax.microedition.midlet.*;

import javax.microedition.lcdui.*;

public class MenuEvents extends MIDlet implements CommandListener,ItemStateListener {

public ChoiceGroup ch;

public ChoiceGroup ch1;

public Form form;

public Form form1;

public Display display;

public Command View;

public Command Exit;

public Command Back;

public StringItem options;

public Item item;

public MenuEvents()

{

display=Display.getDisplay(this);

form=new Form("");

form1=new Form("Selcted Options are");

ch=new ChoiceGroup("Preferences",Choice.MULTIPLE);

ch.append("cut",null);

ch.append("copy",null);

ch.append("paste",null);

ch.append("delete",null);

ch.setSelectedIndex(1, true);

form.append(ch);

ch1=new ChoiceGroup("",Choice.EXCLUSIVE);

Page 102: LAB CODE - MRCET

ch1.append("select all",null);

ch1.append("unselect all",null);

ch1.setSelectedIndex(1, true);

form.append(ch1);

View=new Command("View",Command.OK,1);

Exit =new Command("Exit",Command.EXIT,1);

Back=new Command("Back",Command.BACK,1);

form.addCommand(View);

form.addCommand(Exit);

form1.addCommand(Back);

form.setCommandListener(this);

form1.setCommandListener(this);

form.setItemStateListener(this);

}

public void startApp()

{

display.setCurrent(form);

}

public void pauseApp() {

}

public void destroyApp(boolean unconditional) {

}

public void commandAction(Command command,Displayable displayable)

{

if(displayable==form)

{

if(command==View)

{

boolean opt[]=new boolean[ch.size()];

options=new StringItem("","");

String values="";

ch.getSelectedFlags(opt);

options.setText("");

for(int i=0;i<opt.length;i++)< p=""> </opt.length;i++)<>

{

if(opt[i])

{

values+=ch.getString(i)+"\n";

}

}

options.setText(values);

form1.append(options);

display.setCurrent(form1);

}

else if(command==Exit)

{

destroyApp(true);

notifyDestroyed();

}

}

Page 103: LAB CODE - MRCET

else if(displayable==form1)

{

if(command==Back)

{

display.setCurrent(form);

options.setText("");

}

}

}

public void itemStateChanged(Item item)

{

if(item==ch1)

{

int i=0;

int size=ch.size();

while(i<size)< p=""> </size)<>

{

if(ch1.getSelectedIndex()==0)

ch.setSelectedIndex(i, true);

else

ch.setSelectedIndex(i, false);

i++;

}

}

}

}

Output:

Page 104: LAB CODE - MRCET
Page 105: LAB CODE - MRCET
Page 106: LAB CODE - MRCET
Page 107: LAB CODE - MRCET

2.3. Input checking

Create an MIDP application which examine, that a phone number, which a user has

entered is in the given format.

* Area code should be one of the following: 040, 041, 050, 0400, 044

* There should 6-8 numbers in telephone number (+ area code)

Program:

import javax.microedition.midlet.*;

import javax.microedition.lcdui.*;

Page 108: LAB CODE - MRCET

public class InputChecking extends MIDlet implements CommandListener {

public Form form1;

public TextField textfield1;

public Command exitCommand;

public Command okCommand;

public StringItem st;

public Display display;

public InputChecking()

{

display=Display.getDisplay(this);

form1=new Form("Insert the Phone number");

exitCommand=new Command("Exit",Command.EXIT,1);

okCommand=new Command("Ok",Command.OK,1);

st=new StringItem("Phone Number is ","");

textfield1=new TextField("Phone;","",30,TextField.ANY);

form1.append(textfield1);

form1.addCommand(okCommand);

form1.addCommand(exitCommand);

form1.setCommandListener(this);

}

public void startApp() {

display.setCurrent(form1);

}

public void pauseApp() {

}

public void destroyApp(boolean unconditional) {

}

public void commandAction(Command cmd,Displayable displayable)

{

if(cmd==exitCommand)

notifyDestroyed();

else if(cmd==okCommand)

{

String s=textfield1.getString();

s=s.replace(' ', '.');

int len=s.length();

int i=0;

int c=0;

String s1="";

Page 109: LAB CODE - MRCET

while(i<len) {

if(s.charAt(i)=='.')

{

if(c==0)

{

if(s1.equals("040") || s1.equals("041") || s1.equals("050") || s1.equals("0400") ||

s1.equals("044"))

{

c++;

s1="";

}

}

if(c==1)

{

if(s1.length()-1==3)

{

c++;

s1="";

}

}

}

s1=s1+s.charAt(i);

i++;

}

if(s1.length()-1==3 || s1.length()-1==4 || s1.length()-1==5)

c++;

if(c==3)

st.setText("OK");

else

{

st.setText("wrong\n Phone Number Format is xxx xxx xxxx\nArea code must be

040|050|041|0400|044");

}

form1.append(st);

} }

}

Output:

Page 110: LAB CODE - MRCET

-

Week - 3 Threads & High Level UI:

3.1. Create a slide show which has three slides, which includes only text. Program

should change to the new slide after 5 seconds. After the third slide program returns to

the first slide.

import javax.microedition.midlet.*;

import javax.microedition.lcdui.*;

public class SlideShow extends MIDlet implements CommandListener {

public Form slide1;

Page 111: LAB CODE - MRCET

public Form slide2;

public Form slide3;

public Command Exit;

public Display display;

public SlideShow()

{

display=Display.getDisplay(this);

Exit=new Command("Exit",Command.EXIT,1);

slide1=new Form("Slide1");

slide1.append("This is Slide number 1");

slide1.addCommand(Exit);

slide2=new Form("Slide2");

slide2.append("This is Slide number 2");

slide2.addCommand(Exit);

slide3=new Form("Slide3");

slide3.append("This is Slide number 3");

slide3.addCommand(Exit);

slide1.setCommandListener(this);

slide2.setCommandListener(this);

slide3.setCommandListener(this);

}

public void startApp() {

Thread runner = new Thread(new ThreadRunner(display,slide1,slide2,slide3));

runner.start();

}

public void pauseApp() {

}

public void destroyApp(boolean unconditional) {

}

public void commandAction(Command command,Displayable displayable)

{

if(displayable==slide1)

{

if(command==Exit)

notifyDestroyed();

}

else if(displayable==slide2)

{

if(command==Exit)

notifyDestroyed();

}

else if(displayable==slide3)

{

if(command==Exit)

notifyDestroyed();

Page 112: LAB CODE - MRCET

}

}

}

class ThreadRunner implements Runnable {

Display display;

public int c=0;

public Form slide1;

public Form slide2;

public Form slide3;

public ThreadRunner(Display display,Form slide1,Form slide2,Form slide3) {

this.display = display;

this.slide1=slide1;

this.slide2=slide2;

this.slide3=slide3;

}

public void run() {

while(true)

{

c++;

if(c==1)

display.setCurrent(slide1);

else if(c==2)

display.setCurrent(slide2);

else if(c==3)

display.setCurrent(slide3);

else if(c==4)

c=0;

try

{

Thread.sleep(1500);

}

catch(Exception ex)

{ }

} }}

Output:-

Page 113: LAB CODE - MRCET

3.2 High-level UI

Create a MIDP application, which show to the user 5-10 quiz questions. All questions

have 4 possible options and one right option exactly. Application counts and shows to

the user how many right answers were right and shows them to user.

import javax.microedition.midlet.*;

import javax.microedition.lcdui.*;

import javax.microedition.rms.*;

import java.io.*;

public class Quiz extends MIDlet implements CommandListener {

public Form form1;

public Form form2;

public Form form3;

public Form form4;

public Form form5;

public Form form6;

public Form form7;

public ChoiceGroup ch1;

public ChoiceGroup ch2;

public ChoiceGroup ch3;;

public ChoiceGroup ch4;;

public ChoiceGroup ch5;;

public Command nextCommand;

Page 114: LAB CODE - MRCET

public Command backCommand;

public Command MenuCommand;

public Command OkCommand;

public Command ExitCommand;

public Command sCommand;

public Display display;

public StringItem st;

public TextField textfield;

public int count;

public RecordStore recordstore=null;

public RecordEnumeration re=null;

public Alert alert;

public StringItem st1;

public Quiz()

{

count=0;

display=Display.getDisplay(this);

nextCommand=new Command("Next",Command.OK,1);

backCommand=new Command("Back",Command.BACK,1);

st1=new StringItem("","");

textfield=new TextField("EnterName","",20,TextField.ANY);

form1=new Form("J2ME Stands for");

form2=new Form("a+b=");

form3=new Form("5*5");

form4=new Form("Who is AP CM");

form5=new Form("How many Districts in AP");

form6=new Form("Score");

ch1=new ChoiceGroup("",Choice.EXCLUSIVE);

ch1.append("Java 2 Mobile Edition", null);

ch1.append("Java 2 Macro Edition", null);

ch1.append("Java 2 Micro Edition", null);

ch1.append("Java 2 Music Edition", null);

form1.append(ch1);

form1.addCommand(nextCommand);

form1.setCommandListener(this);

ch2=new ChoiceGroup("",Choice.EXCLUSIVE);

ch2.append("b+a", null);

ch2.append("b*a", null);

ch2.append("b/a", null);

ch2.append("b-a", null);

form2.append(ch2);

form2.addCommand(nextCommand);

form2.addCommand(backCommand);

form2.setCommandListener(this);

ch3=new ChoiceGroup("",Choice.EXCLUSIVE);

ch3.append("20", null);

ch3.append("30", null);

ch3.append("10", null);

ch3.append("25", null);

form3.append(ch3);

Page 115: LAB CODE - MRCET

form3.addCommand(nextCommand);

form3.addCommand(backCommand);

form3.setCommandListener(this);

ch4=new ChoiceGroup("",Choice.EXCLUSIVE);

ch4.append("Rosiah", null);

ch4.append("Jagan", null);

ch4.append("ChandaBabu", null);

ch4.append("Kiran", null);

form4.append(ch4);

form4.addCommand(nextCommand);

form4.addCommand(backCommand);

form4.setCommandListener(this);

ch5=new ChoiceGroup("",Choice.EXCLUSIVE);

ch5.append("8", null);

ch5.append("4", null);

ch5.append("11", null);

ch5.append("23", null);

form5.append(ch5);

form5.addCommand(backCommand);

form5.addCommand(nextCommand);

form5.setCommandListener(this);

form6.addCommand(ExitCommand);

}

public void startApp() {

display.setCurrent(form1);

}

public void pauseApp() {

}

public void destroyApp(boolean unconditional) {

}

public void commandAction(Command cmd,Displayable displayable)

{

if(displayable==form1)

{

if(cmd==nextCommand)

display.setCurrent(form2);

}

else if(displayable==form2)

{

if(cmd==nextCommand)

display.setCurrent(form3);

else if(cmd==backCommand)

display.setCurrent(form1);

}

else if(displayable==form3)

{

if(cmd==nextCommand)

display.setCurrent(form4);

else if(cmd==backCommand)

display.setCurrent(form2);

Page 116: LAB CODE - MRCET

}

else if(displayable==form4)

{

if(cmd==nextCommand)

display.setCurrent(form5);

else if(cmd==backCommand)

display.setCurrent(form3);

}

else if(displayable==form5)

{

if(cmd==nextCommand)

{

if(ch1.getSelectedIndex()==2)

count++;

if(ch2.getSelectedIndex()==0)

count++;

if(ch3.getSelectedIndex()==3)

count++;

if(ch4.getSelectedIndex()==3)

count++;

if(ch5.getSelectedIndex()==3)

count++;

st.setText(String.valueOf(count));

form6.append(st);

form6.append(textfield);

display.setCurrent(form6);

}

}

}

}

Output:

Page 117: LAB CODE - MRCET
Page 118: LAB CODE - MRCET
Page 119: LAB CODE - MRCET
Page 120: LAB CODE - MRCET
Page 121: LAB CODE - MRCET
Page 122: LAB CODE - MRCET

3.3 Create a MIDP application, where the user can enter player name and points. The

program saves the information to the record using RMS at MIDP device. Program

should also print out the top 10 player list to the end user. You can use this class in your

game if you made own class for saving and reading record sets.

import javax.microedition.midlet.*;

import javax.microedition.lcdui.*;

import javax.microedition.rms.*;

import java.io.*;

public class QuizMidlet extends MIDlet implements CommandListener {

public Form form1;

public Form form2;

public Form form3;

public Form form4;

public Form form5;

public Form form6;

public Form form7;

public ChoiceGroup ch1;

public ChoiceGroup ch2;

public ChoiceGroup ch3;;

public ChoiceGroup ch4;;

public ChoiceGroup ch5;;

public Command nextCommand;

public Command backCommand;

public Command MenuCommand;

public Command OkCommand;

public Command ExitCommand;

public Command sCommand;

public Display display;

public StringItem st;

public TextField textfield;

Page 123: LAB CODE - MRCET

public int count;

public RecordStore recordstore=null;

public RecordEnumeration re=null;

public Alert alert;

public Compare comp;

public StringItem st1;

public QuizMidlet()

{

count=0;

display=Display.getDisplay(this);

nextCommand=new Command("Next",Command.OK,1);

backCommand=new Command("Back",Command.BACK,1);

OkCommand=new Command("Save",Command.SCREEN,1);

ExitCommand=new Command("Exit",Command.SCREEN,1);

sCommand=new Command("TopScores",Command.SCREEN,1);

st=new StringItem("TotalPoints","0");

st1=new StringItem("","");

textfield=new TextField("EnterName","",20,TextField.ANY);

form1=new Form("J2ME Stands for");

form2=new Form("a+b=");

form3=new Form("5*5");

form4=new Form("Who is AP CM");

form5=new Form("How many Districts in AP");

form6=new Form("Score");

form7=new Form("Top Scoreers");

ch1=new ChoiceGroup("",Choice.EXCLUSIVE);

ch1.append("Java 2 Mobile Edition", null);

ch1.append("Java 2 Macro Edition", null);

ch1.append("Java 2 Micro Edition", null);

ch1.append("Java 2 Music Edition", null);

form1.append(ch1);

form1.addCommand(nextCommand);

form1.setCommandListener(this);

ch2=new ChoiceGroup("",Choice.EXCLUSIVE);

ch2.append("b+a", null);

ch2.append("b*a", null);

ch2.append("b/a", null);

ch2.append("b-a", null);

form2.append(ch2);

form2.addCommand(nextCommand);

form2.addCommand(backCommand);

form2.setCommandListener(this);

ch3=new ChoiceGroup("",Choice.EXCLUSIVE);

ch3.append("20", null);

ch3.append("30", null);

ch3.append("10", null);

ch3.append("25", null);

Page 124: LAB CODE - MRCET

form3.append(ch3);

form3.addCommand(nextCommand);

form3.addCommand(backCommand);

form3.setCommandListener(this);

ch4=new ChoiceGroup("",Choice.EXCLUSIVE);

ch4.append("Rosiah", null);

ch4.append("Jagan", null);

ch4.append("ChandaBabu", null);

ch4.append("Kiran", null);

form4.append(ch4);

form4.addCommand(nextCommand);

form4.addCommand(backCommand);

form4.setCommandListener(this);

ch5=new ChoiceGroup("",Choice.EXCLUSIVE);

ch5.append("8", null);

ch5.append("4", null);

ch5.append("11", null);

ch5.append("23", null);

form5.append(ch5);

form5.addCommand(backCommand);

form5.addCommand(nextCommand);

form5.setCommandListener(this);

form6.addCommand(OkCommand);

form6.addCommand(ExitCommand);

form6.addCommand(sCommand);

form6.setCommandListener(this);

form7.addCommand(backCommand);

form7.setCommandListener(this);

try

{

recordstore=RecordStore.openRecordStore("Quiz", true);

}

catch(Exception ex)

{

}

}

public void startApp() {

display.setCurrent(form1);

}

public void pauseApp() {

}

public void destroyApp(boolean unconditional) {

}

public void commandAction(Command cmd,Displayable displayable)

{

if(displayable==form1)

{

Page 125: LAB CODE - MRCET

if(cmd==nextCommand)

display.setCurrent(form2);

}

else if(displayable==form2)

{

if(cmd==nextCommand)

display.setCurrent(form3);

else if(cmd==backCommand)

display.setCurrent(form1);

}

else if(displayable==form3)

{

if(cmd==nextCommand)

display.setCurrent(form4);

else if(cmd==backCommand)

display.setCurrent(form2);

}

else if(displayable==form4)

{

if(cmd==nextCommand)

display.setCurrent(form5);

else if(cmd==backCommand)

display.setCurrent(form3);

}

else if(displayable==form5)

{

if(cmd==nextCommand)

{

if(ch1.getSelectedIndex()==2)

count++;

if(ch2.getSelectedIndex()==0)

count++;

if(ch3.getSelectedIndex()==3)

count++;

if(ch4.getSelectedIndex()==3)

count++;

if(ch5.getSelectedIndex()==3)

count++;

st.setText(String.valueOf(count));

form6.append(st);

form6.append(textfield);

display.setCurrent(form6);

}

else if(cmd==backCommand)

display.setCurrent(form4);

Page 126: LAB CODE - MRCET

}

else if(displayable==form6)

{

if(cmd==OkCommand)

{

try

{

String Pname=textfield.getString();

int Points=Integer.parseInt(st.getText());

byte[] bytes;

ByteArrayOutputStream ostream=new ByteArrayOutputStream();

DataOutputStream dstream =new DataOutputStream(ostream);

dstream.writeUTF(Pname);

dstream.writeInt(Points);

dstream.flush();

bytes=ostream.toByteArray();

recordstore.addRecord(bytes, 0,bytes.length );

ostream.reset();

ostream.close();

dstream.close();

alert =new Alert("Message","Saved",null,AlertType.INFO);

alert.setTimeout(Alert.FOREVER);

display.setCurrent(alert);

}

catch(Exception ex)

{

alert =new Alert("Message",ex.toString(),null,AlertType.INFO);

alert.setTimeout(Alert.FOREVER);

display.setCurrent(alert);

}

}

else if(cmd==ExitCommand)

{

try

{

recordstore.closeRecordStore();

notifyDestroyed();

}

catch(Exception ex)

{

}

}

else if(cmd==sCommand)

{

try

{

byte[] bytes=new byte[300];

ByteArrayInputStream bstream=new ByteArrayInputStream(bytes);

Page 127: LAB CODE - MRCET

DataInputStream dstream=new DataInputStream(bstream);

StringBuffer sb=new StringBuffer();

comp=new Compare();

re=recordstore.enumerateRecords(null, comp,false);

st1.setText("");

while(re.hasNextElement())

{

recordstore.getRecord(re.nextRecordId(), bytes, 0);

sb.append(dstream.readUTF()+"|"+dstream.readInt());

sb.append("\n");

dstream.reset();

}

bstream.close();

dstream.close();

st1.setText(sb.toString());

form7.append(st1);

}

catch(Exception ex)

{

alert =new Alert("Msg",ex.toString(),null,AlertType.INFO);

alert.setTimeout(Alert.FOREVER);

display.setCurrent(alert);

}

display.setCurrent(form7);

}

}

else if(displayable==form7)

{

if(cmd==backCommand)

display.setCurrent(form6);

} }}

class Compare implements RecordComparator

{

public byte[] bytedata=new byte[300];

public ByteArrayInputStream bstream=null;

public DataInputStream dstream=null;

public int compare(byte[] r1,byte[] r2)

{

int r1int,r2int;

int or=0;

try

{

int maxlen=Math.max(r1.length, r2.length);

Page 128: LAB CODE - MRCET

if(maxlen>bytedata.length)

{

bytedata=new byte[maxlen];

}

bstream=new ByteArrayInputStream(r1);

dstream=new DataInputStream(bstream);

dstream.readUTF();

r1int=dstream.readInt();

bstream=new ByteArrayInputStream(r2);

dstream=new DataInputStream(bstream);

dstream.readUTF();

r2int=dstream.readInt();

if(r1int==r2int)

{

or= RecordComparator.EQUIVALENT;

}

else if(r1int>r2int)

{

or= RecordComparator.PRECEDES;

}

else if(r1int<r2int)

{

or= RecordComparator.FOLLOWS;

}

return or;

}

catch(Exception ex)

{

return RecordComparator.EQUIVALENT;

}

}

public void compareClose()

{

try

{

if(bstream!=null)

{

bstream.close();

}

if(dstream!=null)

{

dstream.close();

}

}

catch(Exception ex)

{

} }

Page 129: LAB CODE - MRCET

}

Output:-

Week - 4 Working on Drawing and Images

4.1 Create a slide show which has three slides, which includes pictures at PNG format.

Program should change to the new slide other 5 seconds.

Page 130: LAB CODE - MRCET

import javax.microedition.midlet.*;

import javax.microedition.lcdui.*;

public class imageSlideShow extends MIDlet implements CommandListener {

public Form slide1;

public Form slide2;

public Form slide3;

public Display display;

public Image image1;

public Image image2;

public Image image3;

public ImageItem imageitem1;

public ImageItem imageitem2;

public ImageItem imageitem3;

public imageSlideShow()

{

display=Display.getDisplay(this);

try

{

image1=Image.createImage("/1.png");

image2=Image.createImage("/2.png");

image3=Image.createImage("/3.png");

imageitem1=new ImageItem(null,image1,ImageItem.LAYOUT_CENTER,"image1");

imageitem2=new ImageItem(null,image2,ImageItem.LAYOUT_CENTER,"image2");

imageitem3=new ImageItem(null,image3,ImageItem.LAYOUT_CENTER,"image3");

}

catch(Exception ex)

{

}

Exit=new Command("Exit",Command.EXIT,1);

slide1=new Form("Slide1");

slide1.append(imageitem1);

slide1.addCommand(Exit);

slide2=new Form("Slide2");

slide2.append(imageitem2);

slide2.addCommand(Exit);

slide3=new Form("Slide3");

slide3.append(imageitem3);

slide3.addCommand(Exit);

slide1.setCommandListener(this);

slide2.setCommandListener(this);

slide3.setCommandListener(this);

}

public void startApp() {

Thread runner = new Thread(new ThreadRunner(display,slide1,slide2,slide3));

runner.start();

}

public void pauseApp() {

}

public void destroyApp(boolean unconditional) {

}

Page 131: LAB CODE - MRCET

public void commandAction(Command command,Displayable displayable)

{

if(displayable==slide1)

{

if(command==Exit)

notifyDestroyed();

}

else if(displayable==slide2)

{

if(command==Exit)

notifyDestroyed();

}

else if(displayable==slide3)

{

if(command==Exit)

notifyDestroyed();

}

}

}

class ThreadRunner implements Runnable {

Display display;

public int c=0;

public Form slide1;

public Form slide2;

public Form slide3;

public ThreadRunner(Display display,Form slide1,Form slide2,Form slide3) {

this.display = display;

this.slide1=slide1;

this.slide2=slide2;

this.slide3=slide3;

}

public void run() {

while(true)

{

c++;

if(c==1)

display.setCurrent(slide1);

else if(c==2)

display.setCurrent(slide2);

else if(c==3)

display.setCurrent(slide3);

else if(c==4)

c=0;

try

{

Thread.sleep(1500);

}

catch(Exception ex)

{

}

Page 132: LAB CODE - MRCET

}

}

}

Output:-

4.2 Create a MIDP application, which draws a bar graph to the display. Data values can

be given at int[] array.

Source Code:

import javax.microedition.midlet.*;

import javax.microedition.lcdui.*;

public class BarGraph extends MIDlet implements CommandListener{

public Form form;

public Command exitCommand;

public Command OkCommand;

public Command backCommand;

public Displayable d;

Page 133: LAB CODE - MRCET

public Display display;

public TextField textfield1;

public TextField textfield2;

public TextField textfield3;

public TextField textfield4;

public TextField textfield5;

public BarGraph ()

{

display=Display.getDisplay(this);

form=new Form("BarGraph");

textfield1=new TextField("Value1:-","",30,TextField.ANY);

textfield2=new TextField("Value2:-","",30,TextField.ANY);

textfield3=new TextField("Value3:-","",30,TextField.ANY);

textfield4=new TextField("Value4:-","",30,TextField.ANY);

textfield5=new TextField("Value5:-","",30,TextField.ANY);

form.append(textfield1);

form.append(textfield2);

form.append(textfield3);

form.append(textfield4);

form.append(textfield5);

OkCommand=new Command("Ok",Command.OK,1);

exitCommand=new Command("Exit",Command.EXIT,1);

backCommand=new Command("Back",Command.BACK,1);

form.addCommand(OkCommand);

form.addCommand(exitCommand);

form.setCommandListener(this);

}

public void startApp() {

display.setCurrent(form);

}

public void pauseApp() {

}

public void destroyApp(boolean unconditional) {

}

public void commandAction(Command command,Displayable displayable)

{

if(displayable==form)

{

if(command==OkCommand)

{

int[] data=new int[5];

data[0]=Integer.parseInt(textfield1.getString());

data[1]=Integer.parseInt(textfield2.getString());

data[2]=Integer.parseInt(textfield3.getString());

data[3]=Integer.parseInt(textfield4.getString());

data[4]=Integer.parseInt(textfield5.getString());

d=new BarCanvas(data);

d.addCommand(backCommand);

d.setCommandListener(this);

display.setCurrent(d);

Page 134: LAB CODE - MRCET

}

else if(command==exitCommand)

notifyDestroyed();

}

else if(displayable==d)

{

if(command==backCommand)

display.setCurrent(form);

}

}

}

class BarCanvas extends Canvas{

int[] data;

public int x;

public int y;

public int y1;

public int h;

public BarCanvas(int[] data)

{

this.data=data;

x=10;

}

public void paint(Graphics g)

{

g.setColor(255, 255, 255);

g.fillRect(0, 0, this.getWidth(), this.getHeight());

g.setColor(255, 125, 100);

int i=0;

y1=data[0];

h=200;

while(i<data.length)</data.length)

{

y=data[i];

h=200+y1-y;

g.fillRect(x, y,25 , h);

x+=30;

i++;

}

}

}

Output:

Page 135: LAB CODE - MRCET
Page 136: LAB CODE - MRCET

4.3 Create a MIDP application, which draws a bar graph to the display. Data values can

be given at int[] array. You can enter four data (integer) values to the input text field.

Program:

import javax.microedition.midlet.MIDlet;

import javax.microedition.lcdui.*;

public class PieChart extends MIDlet implements CommandListener {

public Form form;

public Command exitCommand;

public Command OkCommand;

public Display display;

public TextField textfield1;

public TextField textfield2;

public TextField textfield3;

public TextField textfield4;

public TextField textfield5;

public Displayable d;

public void startApp() {

display = Display.getDisplay(this);

form=new Form("Draw Pie");

textfield1=new TextField("Value1:-","",30,TextField.ANY);

textfield2=new TextField("Value2:-","",30,TextField.ANY);

textfield3=new TextField("Value3:-","",30,TextField.ANY);

textfield4=new TextField("Value4:-","",30,TextField.ANY);

textfield5=new TextField("Value5:-","",30,TextField.ANY);

Page 137: LAB CODE - MRCET

form.append(textfield1);

form.append(textfield2);

form.append(textfield3);

form.append(textfield4);

form.append(textfield5);

exitCommand = new Command("exit", Command.EXIT, 1);

OkCommand=new Command("Ok",Command.OK,1);

form.addCommand(OkCommand);

form.addCommand(exitCommand);

form.setCommandListener(this);

display.setCurrent(form);

}

public void pauseApp() {

}

public void destroyApp(boolean unconditional) {

}

public void commandAction(Command c, Displayable s) {

if(s==form)

{

if(c==exitCommand)

notifyDestroyed();

else if(c==OkCommand)

{

int[] data = new int[5];

data[0]=Integer.parseInt(textfield1.getString());

data[1]=Integer.parseInt(textfield2.getString());

data[2]=Integer.parseInt(textfield3.getString());

data[3]=Integer.parseInt(textfield4.getString());

data[4]=Integer.parseInt(textfield5.getString());

d = new PieChartCanvas(data);

d.addCommand(exitCommand);

d.setCommandListener(this);

display.setCurrent(d);

}

}

else if(s==d)

{

if(c==exitCommand)

display.setCurrent(form);

}

}

}

class PieChartCanvas extends Canvas {

int[] data;

int colors[] = { 0xFF0000, 0xA9E969, 0x00FFFF, 0xC675EC, 0x008800, 0x00C400 };

public PieChartCanvas(int[] data) {

this.data = data;

}

public void paint(Graphics g) {

int width = this.getWidth();

Page 138: LAB CODE - MRCET

int height = this.getHeight();

g.setColor(255, 255, 255);

g.fillRect(0, 0, width, height);

int sum = 0;

for (int i = 0; i < data.length; i++) {

sum += data[i];

}

int deltaAngle = 360 * 100 / sum / 100;

int x = 4;

int y = 4;

int diameter;

if (width > height)

diameter = height - y * 2;

else

diameter = width - x * 2;

int startAngle = 0;

for (int i = 0; i < data.length; i++) {

g.setColor(colors[i]);

g.fillArc(x, y, diameter, diameter, startAngle, deltaAngle * data[i]);

startAngle += deltaAngle * data[i];

}

}

}

Output:

Page 139: LAB CODE - MRCET

Week - 5 Developing Networked Applications using the Wireless Toolkit

Creating a Simple Client-Server Application

Create, compile and run a basic UDP-based client-server application.

Creating the Datagram Server project

1) Click on Wireless Toolkit 2.5.2 under the group: All Programs→Sun Java

(TM) Wireless Toolkit 2.5.2.

2) Click on 'New Project...' button.

3) Enter project name as 'DatagramServer'. Enter MIDlet name as 'DatagramServer'. Note

that the Midlet name is the same as the name of the class in the source code, which extends

the MIDlet class, otherwise the application won’t run.

4) Another window pops up where it is required to select a target platform. Select 'MIDP 1.0'

from the drop down list.

5) After clicking OK, the project is created; and the Wireless Toolkit tells that the name of

the folder where source code files are created. The path of the source code folder is displayed

in the debug output window.

Creating and Compiling the DatagramServer source files

The Wireless Toolkit does not come with an IDE by default so Use any IDE or a text editor

like Notepad.

1) Create a new text file called DatagramServer.java in the source folder of the project. The

exact path of this folder is displayed in the Wireless Toolkit window.

2) Paste contents DatagramServer.java from into the source file.

Running your Server application on the Phone simulator

1) After compiling the project successfully, click on the Run button in the Wireless Toolkit

window.

2) A graphical window depicting a phone handset will appear with the name of your

application highlighted on its screen as shown below.

3) To start the application, click on the right soft-key (marked with a dot) below the ‘Launch’

command.

Page 140: LAB CODE - MRCET

4) The phone simulator might ask if it is OK to run the network application. Select ‘Yes’ by

clicking on the appropriate soft-key. The server is now up and running.

5) Keep the server running during the creation, compilation and running of the Datagram

Client application.

Creating the DatagramClient project

1) Use the same instance of the Wireless Toolkit that is used for creating and compiling the

Datagram Server project.

2) Click on 'New Project...' button.

3) A new window pops up. Enter project name as 'DatagramClient'. Enter MIDlet name as

'DatagramClient'. Note that the Midlet name is the same as the name of the class in the source

code, which extends the MIDlet class.

4) Another window pops up where one has to select a target platform. Select 'MIDP 1.0' from

the drop down list.

5) After clicking OK, the project is created and the Wireless Toolkit tells where to place the

source code files. The path of the source code folder is displayed in the debug output window

as explained before.

Creating and Compiling the DatagramClient source files

1) Create a new text file called DatagramClient.java in the source folder of the project.

2) Paste contents DatagramClient.java into the source file.

3) Then click on the Build button in the Wireless Toolkit window. If the compilation is OK, it

will say Build Complete in the window's debug output window, otherwise it will show the

errors. Note: In the source code, use the System.out.println() statement to output debug

information to this window.

Running your Client application on the Phone simulator

1) After compiling the project successfully, click on the Run button in the Wireless Toolkit

window.

2) A graphical window depicting a phone handset will appear with the name of the

application highlighted on its screen.

3) To start the application, click on the right soft-key (marked with a dot) below the ‘Launch’

command.

4) The phone simulator might ask if it is OK to run the network application. Select ‘Yes’ by

clicking on the appropriate soft-key. The client is now up and running.

5) When the client executes on the phone simulator, one should see a text box with the

caption 'Message'. Enter any message and press the right soft-key (corresponding to Send). If

the client-server application is working properly, the screen of the server phone will display

the message sent by the client and the client screen will now display a message sent by the

server in response. The response message from the server is the original client message in

reverse.

6) Try various features of the phone simulator including the different look-and feel options.

import javax.microedition.midlet.*;

import javax.microedition.lcdui.*;

import javax.microedition.io.*;

Page 141: LAB CODE - MRCET

public class DatagramClient extends MIDlet implements CommandListener{

public Form form1;

public Display display;

public TextField textfield;

public Command sendCommand;

public DatagramClient()

{

display=Display.getDisplay(this);

form1=new Form("Datagram Client");

sendCommand=new Command("send",Command.OK,1);

textfield=new TextField("Enter Text",null,30,TextField.ANY);

form1.append(textfield);

form1.addCommand(sendCommand);

form1.setCommandListener(this);

}

public void startApp() {

display.setCurrent(form1);

}

public void pauseApp() {

}

public void destroyApp(boolean unconditional) {

}

public void commandAction(Command cmd,Displayable d)

{

if(cmd==sendCommand)

{

try {

DatagramConnection dgc = (DatagramConnection)

Connector.open("datagram://localhost:9001");

try {

while(true)

{

byte[] payload = textfield.getString().getBytes();

Datagram datagram = dgc.newDatagram(payload, payload.length);

dgc.send(datagram);

}

} finally {

dgc.close();

}

} catch (Exception x) {

x.printStackTrace();

}

}

}

}

Page 142: LAB CODE - MRCET

Output:

/*

Creating the datagram Server project

*/

import javax.microedition.midlet.*;

import javax.microedition.lcdui.*;

import javax.microedition.io.*;

public class DatagramServer extends MIDlet implements CommandListener{

public Form form1;

public Form form2;

public Command startCommand;

public Command refreshCommand;

public Command exitCommand;

public Display display;

public StringItem st;

public DatagramServer()

{

display=Display.getDisplay(this);

startCommand=new Command("Start",Command.OK,1);

refreshCommand=new Command("Refresh",Command.OK,1);

exitCommand=new Command("Exit",Command.EXIT,1);

st=new StringItem(" "," ");

form1 =new Form("DataGramserver");

form2=new Form("Ready to receive Messages");

form1.addCommand(startCommand);

form1.setCommandListener(this);

form2.addCommand(refreshCommand);

Page 143: LAB CODE - MRCET

form2.addCommand(exitCommand);

form2.setCommandListener(this);

}

public void startApp() {

display.setCurrent(form1);

}

public void pauseApp() {

}

public void destroyApp(boolean unconditional) {

}

public void commandAction(Command cmd,Displayable displayable)

{

if(displayable==form1)

{

if(cmd==startCommand)

{

try {

DatagramConnection dgc = (DatagramConnection)

Connector.open("datagram://:9001");

try {

int size = 100;

Datagram datagram = dgc.newDatagram(size);

dgc.receive(datagram);

form2.append(datagram.getData().toString());

} finally {

dgc.close();

}

} catch (Exception x){

x.printStackTrace();

}

display.setCurrent(form2);

}

}

else if(displayable==form2)

{

if(cmd==exitCommand)

{

notifyDestroyed();

}

else if(cmd==refreshCommand)

{

st.setText(" ");

}

Page 144: LAB CODE - MRCET

}

}

}

Output:

Week - 6 Authentication with a Web Server

6.1 Write a sample program to show how to make a SOCKET Connection from j2me

phone.

This J2ME sample program shows how to how to make a SOCKET Connection from a

J2ME Phone. Many a times there is a need to connect backend HTTP server from the

J2ME application. shows how to make a SOCKET connection from the phone to port

80.

import javax.microedition.midlet.*;

import javax.microedition.io.*;

import javax.microedition.lcdui.*;

import java.io.*;

public class socket extends MIDlet {

// StreamConnection allows bidirectional communication

private StreamConnection streamConnection = null;

// use OutputStream to send requests

private OutputStream outputStream = null;

private DataOutputStream dataOutputStream = null;

// use InputStream to receive responses from Web server

private InputStream inputStream = null;

private DataInputStream dataInputStream = null;

// specify the connect string

Page 145: LAB CODE - MRCET

private String connectString = "socket://www.java-samples.com:80";

// use a StrignBuffer to store the retrieved page contents

private StringBuffer results;

// define GUI components

private Display myDisplay = null;

private Form resultScreen;

private StringItem resultField;

public socket() {

// initializing GUI display

results = new StringBuffer();

myDisplay = Display.getDisplay(this);

resultScreen = new Form("Page Content:");

}

public void startApp() {

try {

// establish a socket connection with remote server

streamConnection =

(StreamConnection) Connector.open(connectString);

// create DataOuputStream on top of the socket connection

outputStream = streamConnection.openOutputStream();

dataOutputStream = new DataOutputStream(outputStream);

// send the HTTP request

dataOutputStream.writeChars("GET /index.htm HTTP/1.0 \n");

dataOutputStream.flush();

// create DataInputStream on top of the socket connection

inputStream = streamConnection.openInputStream();

dataInputStream = new DataInputStream(inputStream);

// retrieve the contents of the requested page from Web server

int inputChar;

while ( (inputChar = dataInputStream.read()) != -1) {

results.append((char) inputChar);

}

// display the page contents on the phone screen

resultField = new StringItem(null, results.toString());

resultScreen.append(resultField);

myDisplay.setCurrent(resultScreen);

} catch (IOException e) {

System.err.println("Exception caught:" + e);

} finally {

// free up I/O streams and close the socket connection

Page 146: LAB CODE - MRCET

try {

if (dataInputStream != null)

dataInputStream.close();

} catch (Exception ignored) {}

try {

if (dataOutputStream != null)

dataOutputStream.close();

} catch (Exception ignored) {}

try {

if (outputStream != null)

outputStream.close();

} catch (Exception ignored) {}

try {

if (inputStream != null)

inputStream.close();

} catch (Exception ignored) {}

try {

if (streamConnection != null)

streamConnection.close();

} catch (Exception ignored) {}

}

}

public void pauseApp() {

}

public void destroyApp(boolean unconditional) {

}

}

Output:

6.2 Login to HTTP Server from a J2ME Program

This J2ME sample program shows how to display a simple LOGIN SCREEN on the

J2ME phone and how to authenticate to a HTTP server.

Many J2ME applications for security reasons require the authentication of the user.

This free J2ME sample program, shows how a J2ME application can do authentication

to the backend server.

Note: Use Apache Tomcat Server as Web Server and Mysql as Database Server.

import javax.microedition.midlet.*;

import javax.microedition.lcdui.*;

import javax.microedition.io.*;

import java.io.*;

public class login extends MIDlet implements CommandListener {

public Form form1;

public Command okCommand;

public Display display;

public HttpConnection ht=null;

Page 147: LAB CODE - MRCET

public InputStream ist=null;

public StringItem st;

public TextField t1;

public TextField t2;

public Alert alert;

public Form form2;

public login()

{

display=Display.getDisplay(this);

st=new StringItem(" "," Welcome");

alert =new Alert(" ","Wrong UserName or Password",null,AlertType.INFO);

t1=new TextField("UserName"," ",30,TextField.ANY);

t2=new TextField("Password"," ",30,TextField.PASSWORD);

form1=new Form("Login Here");

form2=new Form("Welcome");

okCommand=new Command("Login",Command.OK,1);

form1.addCommand(okCommand);

form1.setCommandListener(this);

form1.append(t1);

form1.append(t2);

form2.append(st);

}

public void startApp() {

display.setCurrent(form1);

}

public void pauseApp() {

}

public void destroyApp(boolean unconditional) {

notifyDestroyed();

}

public void commandAction(Command cmd,Displayable d)

{

if(cmd==okCommand)

{

try

{

// String

url="http://192.168.5.19:8080/WebApplication7/index.jsp?t1=101&t2=aaa";

String

url="http://192.168.5.19:8080/WebApplication7/index.jsp?t1="+t1.getString().trim()+"&t2="

+t2.getString().trim();

//ht=(HttpConnection)Connector.open("http://192.168.5.19:8080/WebApplication7/index.jsp

");

Page 148: LAB CODE - MRCET

ht=(HttpConnection)Connector.open(url);

ist=ht.openInputStream();

byte[] b=new byte[900];

ist.read(b);

String s=new String(b);

s=s.trim();

if(s.equals("ok"))

display.setCurrent(form2);

else

{

alert.setTimeout(Alert.FOREVER);

display.setCurrent(alert);

}

}

catch(Exception ex)

{

form1.append(ex.toString());

}

}

}

}

Output:

Week - 7 & 8 Web Application using J2ME

The following should be carried out with respect to the given set of application domains:

(Assume that the Server is connected to the well-maintained database of the given

domain. Mobile Client is to be connected to the Server and fetch the required data

value/information)

Students Marks Enquiry

Town/City Movie Enquiry

Railway/Road/Air (For example PNR) Enquiry/Status

Sports (say, Cricket) Update

Town/City Weather Update

Public Exams (say Intermediate or SSC)/ Entrance (Say EAMCET) Results Enquiry

Divide Student into Batches and suggest them to design database according to their domains

and render information according the requests.

Develop a simple Java ME project to retrieve student marks when regd.no is given

Note: Use Apache Tomcat Server as Web Server and Mysql as Database Server.

Page 149: LAB CODE - MRCET

Procedure:

Step1: Create a database table with the following commands. (Assume that 'mysql' database

is installed in 'c:\mysql' folder)

c:\>cd mysql

c:\mysql>cd bin

c:\mysql\bin>mysql

mysql> create database stud;

Query OK, 1 row affected (0.04 sec)

mysql> use stud;

Database changed

mysql> create table student(sno varchar(10),name varchar(20),moad

integer(2),ws integer(2),spm integer(2),st integer(2),ds integer(2),mefa integer(2));

Query OK, 0 rows affected (0.01 sec)

mysql> insert into student values('10731a1227','venkat',66,77,88,66,77,88);

Query OK, 1 row affected (0.00 sec)

Step 2: Create a 'jsp' file with the following code

<%@ page import ="java.sql.*" %>

<%@ page import ="javax.sql.*" %>

<%@ page import ="java.io.*" %>

<%

DataInputStream in = new DataInputStream((InputStream)request.getInputStream());

String rollno=in.readUTF();

Class.forName("com.mysql.jdbc.Driver");

java.sql.Connection con =

DriverManager.getConnection("jdbc:mysql://localhost:3306/stud","dayakar","");

Statement st= con.createStatement();

ResultSet rs=st.executeQuery("select * from student where sno='"+rollno+"'");

if(rs.next())

{

String message;

if(rs.getString(1).equals(rollno))

{

message = "Student Name:"+rs.getString(2)+"\nMarks in MoAD:"+rs.getInt(3)+"\nMarks in

WS:"+rs.getInt(4)+"\nMarks in SPM:"+rs.getInt(5)+"\nMarks in ST:"+rs.getInt(6)+"\nMarks

in DS:"+ rs.getInt(7)+"\nMarks in MEFA:"+rs.getInt(8);

}

else

Page 150: LAB CODE - MRCET

{

message = "Login Failure";

}

out.println(message);

}

%>

Install Tomcat Server 6.0 and deploy this 'jsp' program in the following directory structure

webapps

|

|

----test4

|

|

-----WEB-INF

|

|--lib--mysql-connector-java-3.0.8-stable-bin.jar

|

----login.jsp

Note: You can download 'mysql-connnector-java-3.0.8-stable-bin.jar' from the link

'http://mirrors.ibiblio.org/maven2/mysql/mysql-connector-java/3.0.8/' Adding this jar file is

mandatory to make sure that this program is running

Step 3: Create a Java ME program with the following code and deploy in either wireless

toolkit or netbeans IDE

import javax.microedition.lcdui.*;

import javax.microedition.midlet.*;

import javax.microedition.io.*;

import java.io.*;

public class StudentMidlet extends MIDlet implements CommandListener {

Display display;

Form form;

TextField tf;

String str;

String url= "http://localhost:7000/test4/login.jsp";

Command back= new Command("Back", Command.BACK, 0);

Command submit= new Command("Submit", Command.OK, 2);

Command exit= new Command("Exit", Command.STOP, 3);

private StudentMidlet.Test test;

public StudentMidlet() {}

Page 151: LAB CODE - MRCET

public void startApp() throws MIDletStateChangeException {

display = Display.getDisplay(this);

form = new Form("Student Information Retrieval");

tf = new TextField("Enter Student No:","",30,TextField.ANY );

form.append(tf);

form.addCommand(submit);

form.addCommand(exit);

form.setCommandListener(this);

display.setCurrent(form);

}

public void pauseApp() {}

public void destroyApp(boolean unconditional) {}

public void commandAction(Command c, Displayable d) {

if (c == exit) {

destroyApp(true);

notifyDestroyed();

}

else if (c == back) {

display.setCurrent(form);

}

else if (c == submit) {

str = tf.getString();

test = new StudentMidlet.Test(this);

test.start();

test.setString(str);

}

}

class Test implements Runnable {

StudentMidlet midlet;

private Display display;

String text;

public Test(StudentMidlet midlet) {

this.midlet = midlet;

display = Display.getDisplay(midlet);

}

public void start() {

Thread t = new Thread(this);

t.start();

}

public void run() {

StringBuffer sb = new StringBuffer();

try {

Page 152: LAB CODE - MRCET

HttpConnection c = (HttpConnection) Connector.open(url);

c.setRequestProperty(

"User-Agent","Profile/MIDP-1.0, Configuration/CLDC-1.0");

c.setRequestProperty("Content-Language","en-US");

c.setRequestMethod(HttpConnection.POST);

DataOutputStream os =

(DataOutputStream)c.openDataOutputStream();

os.writeUTF(text.trim());

os.flush();

os.close();

// Get the response from the servlet page.

DataInputStream is =(DataInputStream)c.openDataInputStream();

//is = c.openInputStream();

int ch;

sb = new StringBuffer();

while ((ch = is.read()) != -1) {

sb.append((char)ch);

}

showAlert(sb.toString());

is.close();

c.close();

} catch (Exception e) {

showAlert(e.getMessage());

}

}

/* This method takes input from user like text and pass to jsp */

public void setString(String text) {

this.text = text;

}

/* Display Output or Error On screen*/

private void showAlert(String str) {

Alert a = new Alert("");

a.setString(str);

a.setTimeout(Alert.FOREVER);

display.setCurrent(a);

}

};

}

Step 4: The output is displayed on the mobile emulator as shown below

Page 153: LAB CODE - MRCET

on

Student Information will be displayed as shown in the following mobile emulator

Town/City Movie Enquiry

movie.java

import javax.microedition.midlet.*;

import javax.microedition.lcdui.*;

Page 154: LAB CODE - MRCET

import javax.microedition.io.*;

import java.io.*;

public class movie extends MIDlet implements CommandListener

{

public Form form1;

public Command okCommand;

public Display display;

public HttpConnection ht=null;

public InputStream ist=null;

public StringItem st;

public TextField t1;

public Alert alert;

public Form form2;

public movie()

{

display=Display.getDisplay(this);

st=new StringItem(""," eg:-Mahesh");

alert=new Alert("","Enter correct moviename/movie not available in

City",null,AlertType.INFO);

t1=new TextField("ENTER Movie Name:-","",12,TextField.ANY);

form1=new Form("WELCOME TO RESULTS");

form2=new Form("Theatre DEtails");

okCommand=new Command("GET",Command.OK,1);

Command back=new Command("BACK",Command.OK,0);

form1.addCommand(okCommand);

form2.addCommand(back);

form1.setCommandListener(this);

form2.setCommandListener(this);

form1.append(t1);

form1.append(st);

}

public void startApp()

{

display.setCurrent(form1);

}

public void pauseApp()

{}

public void destroyApp(boolean unconditional)

{

notifyDestroyed();

}

public void commandAction(Command cmd,Displayable d)

{

if(cmd==okCommand)

{

Thread t=new Thread()

{

public void run()

Page 155: LAB CODE - MRCET

{

connect();

}

};

t.start();

}

}

private void connect()

{

try

{

String url="http://localhost:8081/week9/index.jsp?t1="+t1.getString().trim();

ht=(HttpConnection)Connector.open(url);

ist=ht.openInputStream();

byte[] b=new byte[900];

ist.read(b);

String s=new String(b);

s=s.trim();

if(s.equals("no"))

{

alert.setTimeout(Alert.FOREVER);

display.setCurrent(alert);

}

else

{

form2.append(s);

display.setCurrent(form2);

}

}

catch(Exception ex)

{

form1.append(ex.toString());

}

}

}

index.jsp

<%@page import="java.sql.*,java.io.*"%>

<%

String id=request.getParameter("t1");

String sql="select * from movie";

String DP="",MC="",DS="",CNS="",s="";

int count=0;

try{

Class.forName("oracle.jdbc.driver.OracleDriver");

System.out.println("Driver Registered");

Page 156: LAB CODE - MRCET

Connection

con=DriverManager.getConnection("jdbc:oracle:thin:@localhost:1521:XE","system","tiger")

;

System.out.println("connection established");

Statement st=con.createStatement();

ResultSet rs=st.executeQuery(sql);

while(rs.next())

{

s=rs.getString(1);

if(id.equals(s))

{

DP=rs.getString(2);

CNS=rs.getString(3);

DS=rs.getString(4);

count++;

}

}

if(count==1)

{

out.println("Movie Name::"+id);

out.println("\nTheatre:- "+DP);

out.println("\nNumber:- "+CNS);

out.println("Show timing:- "+DS);

}

else

{

out.println("no");

}

}

catch(Exception ex)

{

out.println(ex.toString());

out.close();

}

%>