Ooad Lab Final Manual1

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

CASE TOOLS LAB

IT1333

LAB MANUAL

PREPARED BY

S.RAVIASSISTANT PROFESSOR S.S

DEPARTMENT CSE

UNDER THE GUIDANCE OF

DR. M ROBERTS MASILLAMANIDEAN (CS)

SCHOOL OF COMPUTING SCIENCES

IT1333 CASE TOOLS LABL T P C TCH

0 0 3 1 3

Suggested list of applications

1.Student marks analyzing system

2.Quiz system

3.Online ticket reservation system

4.payroll system

5.Course registration system

6.Expert systems

7.ATM systems

8.Stock maintenance

9.Real-Time scheduler

10.Remote procedure call Implementation

Ex.No:1

Study Of UMLDate:

AIM

General study of UML

DESCRIPTION

The heart of object-oriented problem solving is the construction of a model. The

model abstracts the essential details of the underlying problem from its usually

complicated real world. Several modeling tools are wrapped under the heading of the

UML, which stands for Unified Modeling Language. The purpose of this course is to

present important highlights of the UML.

At the center of the UML are its nine kinds of modeling diagrams, which we describe

here.

Use case diagrams

Class diagrams

Object diagrams

Sequence diagrams

Collaboration diagrams

State chart diagrams

Activity diagrams

Component diagrams

Deployment diagrams

The UML is applicable to object-oriented problem solving. Anyone interested in

learning UML must be familiar with the underlying tenet of object-oriented problem

solving -- it all begins with the construction of a model. A model is an abstraction of the

http://bdn.borland.com/article/0,1410,31863,00.html#component-and-deployment-diagrans%23component-and-deployment-diagrans

http://bdn.borland.com/article/0,1410,31863,00.html#component-and-deployment-diagrans%23component-and-deployment-diagrans

http://bdn.borland.com/article/0,1410,31863,00.html#activity-diagrams%23activity-diagrams

http://bdn.borland.com/article/0,1410,31863,00.html#statechart-diagrams%23statechart-diagrams

http://bdn.borland.com/article/0,1410,31863,00.html#collaboration-diagrams%23collaboration-diagrams

http://bdn.borland.com/article/0,1410,31863,00.html#sequence-diagrams%23sequence-diagrams

http://bdn.borland.com/article/0,1410,31863,00.html#object-diagrams%23object-diagrams

http://bdn.borland.com/article/0,1410,31863,00.html#classdiagrams%23classdiagrams

http://bdn.borland.com/article/0,1410,31863,00.html#use-case-diagram%23use-case-diagram

underlying problem. The domain is the actual world from which the problem comes.

Models consist of objects that interact by sending each other messages. Think of an

object as "alive." Objects have things they know (attributes) and things they can do

(behaviors or operations). The values of an object's attributes determine its state.

Classes are the "blueprints" for objects. A class wraps attributes (data) and

behaviors (methods or functions) into a single distinct entity. Objects are instances of

classes.

AN INTRODUCTION TO UML DIAGRAM

The Unified Modeling Language is a language for specifying, constructing, visualizing, and

documenting the artifacts of a software-intensive system. Analogous to the use of architectural blueprints in

the construction industry, UML provides a common language for describing software models, and it can be

used in conjunction with a wide range of software lifecycles and development processes.

1. USE CASE DIAGRAM

Use Case diagrams identify the functionality provided by the system (use cases), the users who interact with the system (actors), and the association between the users and the functionality. Use Cases are used in the Analysis phase of software development to articulate the high-level requirements of the system. The primary goals of Use Case diagrams include:

Providing a high-level view of what the system does

Identifying the users ("actors") of the system

Determining areas needing human-computer interfaces.

GRAPHICAL NOTATION

The basic components of Use Case diagrams are the Actor, the Use Case, and the

Association.

ActorAn Actor, as mentioned, is a user of the system, and is depicted using a stick

figure. The role of the user is written beneath the icon. Actors are not limited to humans.

If a system communicates with another application, and expects input or delivers output,

then that application can also be considered an actor.

Use CaseA Use Case is functionality provided by the system, typically described as verb +

object (e.g. Register Car, Delete User). Use Cases are depicted with an ellipse. The

name of the use case is written within the ellipse.

AssociationAssociations are used to link Actors with Use Cases, and indicate that an Actor

participates in the Use Case in some form. Associations are depicted by a line connecting

the Actor and the Use Case.

The following image shows how these three basic elements work together to form

a use case diagram.

Use case diagrams describe what a system does from the standpoint of an

external observer. The emphasis is on what a system does rather than how.

Use case diagrams are helpful in three areas.

Determining features (requirements). New use cases often generate new

requirements as the system is analyzed and the design takes shape.

Communicating with clients. Their notational simplicity makes use case

diagrams a good way for developers to communicate with clients.

Generating test cases. The collection of scenarios for a use case may suggest a

suite of test cases for those scenarios.

2. SEQUENCE DIAGRAM

Sequence diagrams document the interactions between classes to achieve a result,

such as a use case. Because UML is designed for object-oriented programming, these

communications between classes are known as messages. The Sequence diagram lists

objects horizontally, and time vertically, and models these messages over time.

NOTATION

In a Sequence diagram, classes and actors are listed as columns, with vertical

lifelines indicating the lifetime of the object over time.

Object

Objects are instances of classes, and are arranged horizontally. The pictorial

representation for an Object is a class (a rectangle) with the name prefixed by the object

name (optional) and a semi-colon.

Actor

Actors can also communicate with objects, so they too can be listed as a column.

An Actor is modeled using the ubiquitous symbol, the stick figure.

LifelineThe Lifeline identifies the existence of the object over time. The notation for a

Lifeline is a vertical dotted line extending from an object.

ActivationActivations, modeled as rectangular boxes on the lifeline, indicate when the

object is performing an action.

MESSAGE Messages, modeled as horizontal arrows between Activations, indicate the

communications between objects.

Below is a sequence diagram for making a hotel reservation. The object initiating

the sequence of messages is a Reservation window.

The Reservation window sends a makeReservation() message to a

HotelChain. The HotelChain then sends a makeReservation() message to a Hotel. If

the Hotel has available rooms, then it makes a Reservation and a Confirmation.

Each vertical dotted line is a lifeline, representing the time that an object exists.

Each arrow is a message call. An arrow goes from the sender to the top of the activation

bar of the message on the receiver's lifeline. The activation bar represents the duration of

execution of the message.

3. ACTIVITY DIAGRAM

Activity diagrams are used to document workflows in a system, from the business

level down to the operational level. When looking at an Activity diagram, you'll notice

elements from State diagrams. In fact, the Activity diagram is a variation of the state

diagram where the "states" represent operations, and the transitions represent the

activities that happen when the operation is complete. The general purpose of Activity

diagrams is to focus on flows driven by internal processing vs. external events.

ACTIVITY STATES

Activity states mark an action by an object. The notations for these states are

rounded rectangles, the same notation as found in State chart diagrams.

TRANSITION

When an Activity State is completed, processing moves to another Activity State.

Transitions are used to mark this movement. Transitions are modeled using arrows.

SWIM LANE

Swim lanes divide activities according to objects by arranging objects in column

format and placing activities by that object within that column. Objects are listed at the

top of the column, and vertical bars separate the columns to form the swim lanes.

INITIAL STATE

The Initial State marks the entry point and the initial Activity State. The notation

for the Initial State is the same as in State chart diagrams, a solid circle. There can only

be one Initial State on a diagram.

FINAL STATE

Final States mark the end of the modeled workflow. There can be multiple Final

States on a diagram, and these states are modeled using a solid circle surrounded by

another circle.

SYNCHRONIZATION BAR

Activities often can be done in parallel. To split processing ("fork"), or to resume

processing when multiple activities have been completed ("join"), Synchronization Bars

are used. These are modeled as solid rectangles, with multiple transitions going in and/or

out.

4. COMPONENT DIAGRAM

Component diagrams fall under the category of an implementation diagram, a

kind of diagram that models the implementation and deployment of the system. A

Component Diagram, in particular, is used to describe the dependencies between various

software components such as the dependency between executable files and source files.

This information is similar to that within make files, which describe source code

dependencies and can be used to properly compile an application.

COMPONENT

A component represents a software entity in a system. Examples include source

code files, programs, documents, and resource files. A component is represented using a

rectangular box, with two rectangles protruding from the left side, as seen in the image to

the right.

DEPENDENCY

A Dependency is used to model the relationship between two components. The

notation for a dependency relationship is a dotted arrow, pointing from a component to

the component it depends on.

5. CLASS DIAGRAM

A Class diagram gives an overview of a system by showing its classes and the

relationships among them. Class diagrams are static -- they display what interacts but not

what happens when they do interact.

The class diagram below models a customer order from a retail catalog. The

central class is the Order. Associated with it are the Customer making the purchase and

the Payment. A Payment is one of three kinds: Cash, Check, or Credit. The order

contains OrderDetails (line items), each with its associated Item.

UML class notation is a rectangle divided into three parts: class name, attributes, and

operations. Names of abstract classes, such as Payment, are in italics. Relationships

between classes are the connecting links.

Our class diagram has three kinds of relationships.

association -- a relationship between instances of the two classes. There is an

association between two classes if an instance of one class must know about the

other in order to perform its work. In a diagram, an association is a link

connecting two classes.

aggregation -- an association in which one class belongs to a collection. An

aggregation has a diamond end pointing to the part containing the whole. In our

diagram, Order has a collection of OrderDetails.

generalization -- an inheritance link indicating one class is a superclass of the

other. A generalization has a triangle pointing to the superclass. Payment is a

superclass of Cash, Check, and Credit.

An association has two ends. An end may have a role name to clarify the nature of

the association. For example, an OrderDetail is a line item of each Order.

A navigability arrow on an association shows which direction the association can be

traversed or queried. An OrderDetail can be queried about its Item, but not the other

way around. The arrow also lets you know who "owns" the association's implementation;

in this case, OrderDetail has an Item. Associations with no navigability arrows are bi-

directional.

The multiplicity of an association end is the number of possible instances of the class

associated with a single instance of the other end. Multiplicities are single numbers or

ranges of numbers. In our example, there can be only one Customer for each Order, but

a Customer can have any number of Orders.

This table gives the most common multiplicities.

Multiplicities Meaning

0..1 zero or one instance. The notation n . . m indicates n to m instances.

0..* or * no limit on the number of instances (including none).

1 exactly one instance

1..* at least one instance

Every class diagram has classes, associations, and multiplicities. Navigability and roles

are optional items placed in a diagram to provide clarity.

6. PACKAGES AND OBJECT DIAGRAMS

To simplify complex class diagrams, you can group classes into packages. A

package is a collection of logically related UML elements. The diagram below is a

business model in which the classes are grouped into packages.

Packages appear as rectangles with small tabs at the top. The package name is on

the tab or inside the rectangle. The dotted arrows are dependencies. One package

depends on another if changes in the other could possibly force changes in the first.

Object diagrams show instances instead of classes. They are useful for

explaining small pieces with complicated relationships, especially recursive relationships.

This small class diagram shows that a university Department can contain lots of other

Departments.

The object diagram below instantiates the class diagram, replacing it by a concrete

example.

Each rectangle in the object diagram corresponds to a single instance.

Instance names are underlined in UML diagrams. Class or instance names may

be omitted from object diagrams as long as the diagram meaning is still clear.

7. COLLABORATION DIAGRAMS

Collaboration diagrams are also interaction diagrams. They convey the same

information as sequence diagrams, but they focus on object roles instead of the times that

messages are sent. In a sequence diagram, object roles are the vertices and messages are

the connecting links.

The object-role rectangles are labeled with either class or object names (or both).

Class names are preceded by colons ( : ).

Each message in a collaboration diagram has a sequence number. The top-level

message is numbered 1. Messages at the same level (sent during the same call) have the

same decimal prefix but suffixes of 1, 2, etc. according to when they occur.

8. STATE CHART DIAGRAMS

Objects have behaviors and state. The state of an object depends on its current

activity or condition. A statechart diagram shows the possible states of the object and

the transitions that cause a change in state.

Our example diagram models the login part of an online banking system. Logging

in consists of entering a valid social security number and personal id number, then

submitting the information for validation.

Logging in can be factored into four non-overlapping states: Getting SSN,

Getting PIN, Validating, and Rejecting. From each state comes a complete set of

transitions that determine the subsequent state.

States are rounded rectangles. Transitions are arrows from one state to another.

Events or conditions that trigger transitions are written beside the arrows. Our diagram

has two self-transition, one on Getting SSN and another on Getting PIN.

The initial state (black circle) is a dummy to start the action. Final states are also

dummy states that terminate the action.

9. COMPONENT AND DEPLOYMENT DIAGRAMS

A component is a code module. Component diagrams are physical analogs of

class diagram. Deployment diagrams show the physical configurations of software and

hardware.

The following deployment diagram shows the relationships among software and

hardware components involved in real estate transactions.

The physical hardware is made up of nodes. Each component belongs on a node.

Components are shown as rectangles with two tabs at the upper left.

Logical Architecture and UML Package Diagrams

• The software architecture is a fairly large topic: we will only introduce one possible solution (the most common) here.

• As we have finished the requirement analysis part of the first iteration and are ready to move on to design we can look at a larger scale.

• The design of a typical OO system is based on several architectural layers, such as a UI layer, an application logic (or "domain") layer, and so forth.

Logical architecture using a UML package diagram.

• A UML package diagram provides a way to group elements. A UML package can group anything: classes, other packages, use cases, and so on. Nesting packages is very common.

• It is common to want to show dependency (a coupling) between packages so that developers can see the large-scale coupling in the system.

• A UML package represents a namespace so that, for example, a Date class may be defined in two packages. If you need to provide fully-qualified names, the UML notation is, for example, java::util::Date in the case that there was an outer package named "java" with a nested package named "util" with a Date class.

Designing with Layers

• Guidelines– The responsibilities of the objects in a layer should be strongly related to

each other and should not be mixed with responsibilities of other layers. For example, objects in the UI layer should focus on UI work, such as creating windows and widgets, capturing mouse and keyboard events, and so forth. Objects in the application logic or "domain" layer should focus on application logic, such as calculating a sales total or taxes, or moving a piece on a game board.

– UI objects should not do application logic. For example, a Java Swing JFrame (window) object should not contain logic to calculate taxes or move a game piece. And on the other hand, application logic classes should not trap UI mouse or keyboard events. That would violate a clear separation of concerns and maintaining high cohesion : basic architectural principles.

The Model-View Separation Principle• The Model-View Separation principle states that model (domain) objects should

not have direct knowledge of view (UI) objects. So, for example, a Register or Sale object should not directly send a message to a GUI window object ProcessSaleFrame, asking it to display something, change color, close, and so forth.

Ex.No:2STUDENT MARK ANALYZING SYSTEM

Date:

1. Problem analysis and project planning

1.1 Introduction

Student mark analyzing system has been designed to carry out the mark analysis process in an educational institution. The results of respective departments can be efficiently computed without much of manual involvement.

1.2 Objectives

The purpose of this document is to define the requirements of mark analysis system. This system reduces manual work to great extent. The mark analysis is carried out by the system in an efficient manner.

1.3 Scope

This system is very essential for every educational institution as it reduces man power. This system can be used for all kinds of educational institutions to evaluate and analyze the marks and generate reports of specified criteria.

1.4 Problem Statement

For analyzing the marks obtained by students in an educational institution. We are tasked to build up student mark analyzing system.

This is done to replace the manual entering and processing of marks which are error prone and tedious. This system also maintains information about student.

The system will have a Windows based desktop interface to allow the faculty to enter marks obtained by the students, update them and generate various reports.

For security reasons, the administrator and faculty only can update the marks and other information. First the user needs to login to the system for accessing it. The system will retain information on all the students and the institution. The system analyses the marks and generate the result reports. The marks and information about the students are stored in a database and the system works with the database.

The faculty can enter the marks and student information through a visual environment. The updated details are stored in the database. The system generates the overall result by analyzing the marks. Mark analyzer monitors this process. The application in run by the mark analyzer. The trial for illegal updation would render the system to be locked.

One of the most important features of the system is creating reports based on the given criteria. The user can create the following reports:

Overall Class, Department result, Individual student result, Toppers list, Arrears list and Improvement rate for the academic year report has to be generated by entering the register number of the student. These reports can also be viewed by the management and placement officers. The administrator is responsible for adding, deleting student details form the system and updating the marks to the system with the external queries. So, the system design will generate reports automatically and there will be no need for manual intervention.

2. Problem statement(Use case)analysis

2.1 Identified use cases

i Login:

This use case describes how a user logs in to the mark analyzing system.

ii Marks entry:

This use case allows faculty to enter the marks into the student table.

iii Mark analysis:

This use case describes how the system generates the overall result by analyzing the marks.

iv Maintain student information:

This use case allows the administrator to maintain the student information and it also includes adding, changing and deletion of information about the students from the system.

v Create result report:

This use case allows the system to generate various reports based on the criteria specified by the user.

2.2 Identified Actors

i Faculty:

The person responsible for entering and updating the marks obtained by the students.

ii Administrator:

The person responsible for maintaining student information in the system.

iii Database:

The database that contains all the information about the student and their marks.

iv Mark analyzer:

The person responsible for monitoring the mark analyzing process.

v Student:

Details about the students are entered into the system so that the student can view the results and reports.

vi Placement Officer:

The placement officers can also view the reports based on the criteria specified.

2.3 Use Case Diagram

faculty

administrator

database

mark analyser

student

Placement officer

login

mark entry

mark analysis

maintain student information

result report

view reports

3. Design of Students Mark analyzing System

3.1 Design Documentation

1. Login

1.1 Brief description:

This use case describes how the user logs into the Marks Analyzing System(MAS).

1.2 Flow of events:

1.2.1 Basic flow:

This use case starts with the actor wishes to log in to the MAS.

1. The system requests the actor to enter their name and password.

2. The actor enters their name and password.3. The system validates the entire name and password

and logs the actor into the system.

1.2.2 Alternative flow:

1. Invalid name and password.2. If in Basic flow the actor enters and invalid name and

password, the system displays an error message. The actor can choose to either return to the beginning of basic flow or cancel the login at which point the use case ends.

1.3 Pre conditions:

None.

1.4 Post conditions:

If the use case was successful, the actor is now logged into the system, if not, the system status unchanged.

2. Marks Entry


This use case allows the faculty to enter the marks into the student table.

2.2 Flow of events:

2.2.1 Basic flow:

This use case starts when the faculty wishes to enter the marks obtained by the student in different subjects.

1. The system retrieves and displays the student table. If a student table does not exist, it creates a new one. The names of the student and reg. no can’t be changed by the faculty.

2. Once the faculty has entered marks, the system saves the table and adds it to the database.


i. Invalid Marks:

In Basic flow, if invalid marks are entered, the system displays an error message and prompts for a valid mark. The faculty must enter a valid mark or cancel the operation in which case, the use case ends.

ii. Marks already entered:

If in basic flow, the student mark has already been entered, the system displays the read only copy of marks and informs the faculty that the mark has already been entered. So, no changes can be made to it. The faculty acknowledges the message and the use case ends.

iii. Fields left empty:

If in basic flow, the field is left empty, the system prompts the faculty to correct the error. The faculty can enter the mark or mark the student as absent.

2.3 Pre Condition:

The faculty must be logged on to the system before the use case begins.

2.4 Post Condition:

If the use case was successful, the student mark is saved to system otherwise the system status is unchanged.

3. Mark Analysis


This use case describes how the system generates overall results by analyzing the marks, Marks Analyzer monitors this process.

3.2 Flow of events:

3.2.1 Basic flow:

This use case begins when the mark analyzer wishes to calculate the total percentage of marks obtained by the students.

1. The system retrieves and displays the current student marks information from the database.

2. The system calculates the total marks and percentage obtained by all the students.

3. The results are stored in the database.4. The use case ends when all the student’s marks have been

processed.


i. Marks unavailable:

If in basic flow, the information about student marks could not be located, the system displays error message and use case ends.

ii. Results already calculated:

If in basic flow, the result has already been calculated, the system displays the copy of the information and informs mark analyzer that marks have already been processed. The mark analyzer acknowledges the message and the use case ends.

3.3 Pre Condition:

The mark analyzer must be logged on to the system before this use case begins.

3.4 Post Condition:

If the use case was successful, the processed mark information is saved to the system otherwise the system status is unchanged.

4. Maintain Student Information


This use case allows the administrator to maintain the student information. This includes adding, changing and deleting information from the system.

4.2 Flow of events:

4.2.1 Basic flow:

This use case starts when the administrator wishes to change, add or delete student information from the system.

1. The system requests the administrator to specify the function that the administrator would like to perform.

2. Once the administrator provides the requested information, one of the sub flows is executed. If administrator selects add a student, then the ‘add a student’ sub flow is executed. If administrator selects update student information, then the ‘update student information’ sub flow is executed. If the administrator selects delete a student, then the ‘delete a student’ sub flow is executed.

Add a Student:

1. The System requests the administrator to enter the student information. This includes name, department, year, semester, age and sex.

2. Once the administrator provides the requested information, the system generates and assigns a unique register number to the student. Now the student is added to the system database.

3. The system provides the administrator to write the new register number.

Update Student Information(USI):

1. The System requests the administrator to enter the register number.

2. Administrator enters the register number and then the system retrieves and displays the student mark information.

3. Administrator can make changes to the marks.

4. The System updates the student information to the database.

Delete a Student:

1. The System requests the administrator to enter the register number.

2. Administrator enters the register number and then the system retrieves and displays the information.

3. The System prompts administrator to confirm deletion of the student.

4. Administrator verifies the deletion.5. The System deletes the student from the database.


i. Student not found:

If the Update Student Information(USI) or delete a student sub flow student with specific with specific register number does not exist, then the System displays a error message.

The System administrator can re enter or cancel at which point the us case ends.

ii. Irrelevant data:

If in the add a student sub flow invalid information is entered, the system display an error message so that the administrator can re enter or cancel.

iii. Delete Cancelled:If in the delete a student sub flow, the administrator decides not

to delete the student, the delete is cancelled and the Basic flow is restarted.

iv. Pre Condition:

The administrator must be logged on to the system before this use case begins.

v. Post Condition:

If the use case was successful, the student information is added, updated or deleted.

5. Create result/report


This use case allows the user to create an overall class or department result. The individual student result, toppers list, arrears list and improvement rate for the academic year report is discussed.

5.2 Flow of events:

5.2.1 Basic flow:

This use case starts with the actor user wishes to create a report.1. The system requests the user to specify the following report

criteria: Report type (either “Overall class/Department result”,

”Individual Student Result”, ”Toppers List”, ”Arrears List” and

“Improvement Rate for the academic year”). Criteria for the respective report.

2. If the user selects the “Overall class/department result” report,the system retrieves and displays the entire Student’s mark

3. information form the database. The system then requests the user

4. to enter information he/she requires(criteria).

5. If the user selects “Individual Student Result” report, the system

6. requests the student to enter the register number. The system 7. validates the register number and if it is valid, the displays

the report.

8. Similarly, for the “Toppers list”, “Arrears list”, “Improvement Rate” reports, the criteria are specified.

9. Once the user provides the requested information the System provides the report satisfying the report criteria.

10.The user may require saving the report.


Requested Information Un available :

If in the basic flow, the requested information is unavailable, the system will display an error message. The user can choose return to begin to basic flow or cancel it at which the use case ends.

Invalid format or Insufficient Information:

If in the basic flow, the user has not specified sufficient information to create the report, the system will prompt the user for missing information. The user can re-enter or cancel, at which point the use case ends.

Invalid register number:

If the user enters invalid register number, the system will display an error message. The user can re-enter or cancel the operation.

5.3 Pre condition:

The user must be logged on to the system before the use case begins.

5.4 Post condition:

The System state is unchanged by the use case.

SEQUENCE DIAGRAM

1. Login

: Student Main Form Local Form Login control

Welcome Form

Error Message

: Database

1: User enter mainform()

2: Select to login()

3: System request username and password()

4: User enters username and password()

5: Validate username and password()

6: Refer from database()

7: Valid username and password()

8: Welcome message generate()

9: Invalid username and password()

10: Error message-relogin or cancel()

2. Marks Entry

Faculty Main Form Marks Entry Form

Entry Controller

Error Message

: Database

1: Request to specify operation()

2: Enter operation(mark entry)

3: Enter mark entry form()

4: Refer from Database()

5: Request to enter marks()

6: Faculty enter marks()

7: Valid marks()

8: valid(store in database)

9: Invalid marks()

10: Request to restart/cancel()

3.Mark Analysis


: Mark analyser

Main Form Student Informati...

Processing controller

Error message

: Database

1: Request to enter the operation()

2: Processing marks()

3: Enters into the form()

4: Refer student information from database()

5: Calculation of total,Average()

6: Valid modified table into the database()

7: Invalid incorrect marks entry form

8: Restart the operation()

4.1 Add a student

: AdministratorSelection

FormSession Controller

sequence diagram...

sequence diagram...

sequence diagram-...

1: Request to select an option()

2: Allows the administrator to select an option()

3: Add option()

4: Update option()

5: Delete option()

4.2 Update Student Information

: Administrator

Add form Addition controller

Error message

: Database

1: Request to enter name,dept,addr()

2: Enter details()

3: Validate Details()

4: Valid generates a new reg no and add it to the database()

5: Invalid or details missing()

6: Displays Error message,request to re-enter or cancel()

4.3 Delete a student

: AdministratorUpdate form update

controllerErrormessage

: Database

1: Request to enter reg no()

2: Administrator enter reg no()

3: Validate reg no

4: Validate system returns corresponding record()

5: Request to update form()

6: Update marks()

7: Invalid updation()

8: Request to re-enter or cancel()

5.Create Result/Report

: Administrator

Delete form Deletion

controller

Error

message : Database


2: Enter reg no()

3: Validate reg no()


5: Valid reg no student deleted()

6: Invalid reg no

7: Re-enter reg no or cancel()

: Administratormain form report form report

controllererror

message : Database

1: Request to enter report type

2: Enter report type

3: Validate type

4: Refer from database

5: Request to enter the criteria

6: Enter the criteria

7: Validate the criteria

8: Valid display report

9: Store to database

10: Invalid criteria

11: Invalid type

12: Restart or cancel

COLLOBORATION DIAGRAM

1.Login

2.Marks Entry

: Student

Main

Form

Local Form

Login control

Welcome Form

Error Message

: Database

1: User enter mainform() 2: Select to login()

3: System request username and password()

4: User enters username and password()

5: Validate username and password()

7: Valid username and password()

8: Welcome message generate()

9: Invalid username and password()

10: Error message-relogin or cancel()


3.Mark Analysis

Main Form

Marks Entry Form

Entry Controller

Error Message

: Database

1: Request to specify opreration()

2: Enter operation(mark entry)3: Enter mark entry form()

5: Request to enter marks()

6: Faculty enter marks()

7: Valid marks()

8: valid(store in database)

9: Invalid marks()

10: Request to restart/cancel()

4: Refer from Database()Faculty

: Mark analyser

Main Form

Student Information

Form

Processing controller Error

message : Database

1: Request to enter the operation()

2: Processing marks()

3: Enters into the form()

5: Calculation of total,Average()

8: Restart the operation()

4: Refer student information from database()

6: Valid modified table into the database()

7: Invalid incorrect marks entry form


4.1.Add Student

4.2.Update Student

: Administrator

Selection Form

Session Controller

1: Request to select an option()

2: Allows the administrator to select an option()

3: Add option()4: Update option()

5: Delete option()

: Administrator

Add form Addition controller

Error message

: Database

1: Request to enter name,dept,addr()

2: Enter details() 3: Validate Details()

4: Valid generates a new reg no and add it to the database()

5: Invalid or details missing()6: Displays Error message,request to re-enter or cancel()

4.3.Delete Student

5.Create Result/Report

: Administrator

Update form

update controller

Error message

: Database


2: Administrator enter reg no()

3: Validate reg no

5: Request to update form()

6: Update marks()

7: Invalid updation()8: Request to re-enter or cancel()

4: Validate system returns corresponding record()

: Administrator

Delete form

Deletion controller

Error message

: Database


2: Enter reg no()3: Validate reg no()

6: Invalid reg no

7: Re-enter reg no or cancel()


5: Valid reg no student deleted()

STATECHART DIAGRAM

1.Login

: Administrator

main form

report form

report controller

error message

: Database

1: Request to enter report type

2: Enter report type 3: Validate type

5: Request to enter the criteria

6: Enter the criteria

7: Validate the criteria11: Invalid type

12: Restart or cancel

4: Refer from database8: Valid display report

9: Store to database

10: Invalid criteria

Initialization

/ Enter username and password

Open Error message

Cancel

Cancelled Cancelled

Validate Details

[ Valid Details ] / Enter into Welcome Screen [ Invalid details ] / Error message

2.Mark Analysis

ACTIVITY DIAGRAM

Displaying details

Lock

[ all records not retrieved ]

Processing marks

[ all record retrieved ] / process the marks

Updating the database

Processing marks

Cancelcancelled cancelled

1.Updating the Database

2.Adding a Student

Request to enter reg.no and details to be updated

Confirmation that details have been updated.

Process the register no.

Details from database retrieval

Updating the database

DatabaseSystemAdministrator

3. Deleting a Student

Request to enter the details of the student to

be added.

Confirmation that student have been added

Process the details

valid details

Generate register no. for the student

add the student todatabase


Request to enter reg.no

Confirmation that student have been deleted

Process the register no.

check reg.no

Delete

Update database

register no. available


CLASS DIAGRAM

1.Login

2.Marks Entry

Database

Login formnamepassword

Username and password()login()select to login()

Error message

Invalid marks()Display error message()

Login Controller

Refer from database()Validate username and password()

Student

Welcome form

Display to user()valid username and password()

Main form

enter operation()

3. Mark Analysis

4. Create Student Report

Student

Main form

enter operation()

Marks Entry form

display mark entry form()faculty enters marks()Refer from database()

Entry Controller

Validate marks()

Error message


Database

Mark analyser

Student Information flow

retrieves information from database()refers student information from database()

Processing control

Process the marks()calculation of total,average()

Database

Error message


Main form

enter operation()

5.Maintain Student Information

Student

Error message


Main form

enter operation()

Report Controller

Validate the criteria()Ask whether to save or not()selects to save()selects not to save()

Report form

Request the user to enter the criterias()validates()validate type()retrieves information from database()

Database

Error message


Administrator

Selection controller

add option()Update option()Delete option()

Add form(into database)

Enter details()

Database

Delete form(from database)

Enter register number()

Update form(from database)

Admin enters reg. no()

Selection form

Allows the administrator to select an option()

11

1

1

Controller

validate respective operation()

COMPONENT DIAGRAM

CLASS CODE:1) Login :

Option Explicit

Public NewProperty As login_form

Public Sub refer_to_database()

End Sub

Public Sub validate_user_name_and_pass_word()

End Sub

Login<<ActiveX DLL>>

Mark Analysis<<ActiveX DLL>>

Marks Entry<<ActiveX DLL>> Maintain Student

Information

<<ActiveX DLL>>

Create Result/Report

<<ActiveX DLL>>

2) Mark entry:

Option Explicit

Implements main_form

Public Sub display_mark_entry_form()

End Sub

Public Sub faculty_enters_mark()

End Sub

Public Sub refer_from_data_base()

End Sub

3) Mark analysis:

Option Explicit

Public Sub process_the_marks()

End Sub

Public Sub calculatation_of_total_average()

End Sub4) Student report:

Option Explicit

Public NewProperty As student

Public NewProperty2 As student

Public Sub enter_opreation()

End Sub

Ex.No:3ATM SYSTEM

Date:


1.3 Introduction

Banking is one of the common and day to day attribute of life. Nowadays it is totally different from that existed a few years ago banking has become completely computerized new facilities such as credit cards, debit cards & ATM has been introduced. ATM is automatic teller machine which is basically used to withdraw money from an account.

1.4 Objectives

The objective of this software is similar to ATM software installed in ATM center. It should first validate the pin in the ATM card. Then the type of transaction is enquired and the information from the customer is validated. If it is a withdrawal the amount is asked. After the money is delivered the transaction just made is updated in the database where the customer’s information is stored.

1.3 Scope

The scope of the project is to design an ATM system that will help in completely automatic banking this software is going to be designed for withdrawal and deposit of money and register the transaction in the database where the customer’s information is stored.


ATM is another type of banking where the most frequently type of transaction made is withdrawal. A user may withdraw as much as many amount as he wants until his account holds a sum greater than his withdrawal amount. ATM is completely automated and there is no necessity

of the ATM center being placed at the bank itself. It can be placed in the shopping malls, airports, railway stations etc.

This ATM system can use any kind of interface. But it should be user friendly and not confusing. Help manuals should be provided in case any customer has problem working with the software.

The system will retain information on the entire customer who has necessity rights to access the service. It will contain the balance amount in the account, rate of interest, any special allowance for that customer and most of all pin number of the customer. The ATM system should be compatible with any kind of database such as MS-ACCESS, DB2, ORACLE, SQL, SERVER etc. the emphasis here is on consistency.

Some customer could have availed some special offers on his ATM cards. So this must be taken care of and the appropriate data should be dealt with.

The ATM should provide easy access to the data for the customer. It should also have a highly secure interface so that one can take money one behalf of others. So the security is one of the main aspects in ATM.



i. Login:

Here the user enters the card and the inputs his password to enter into the main form. If the password is incorrect, the system will display an error message.

ii. Transaction:

This is the important part of the ATM system, where there are two types of transaction-withdrawal and deposit. While withdrawing the user specifies the amount and may request for the printed output also.

iii. Maintaining Customer Information:

Here the administrator plays an important role, whose work is to add customer, delete customer account, update customer account, etc.


i Administrator:

Administrator plays an important role. He is the system designer. All the updating works is done by him only like adding, deleting customer accounts.

ii Database:

All the transaction works-withdrawal and deposit are updated in the database.

iii Customer:

He is the external user the ATM system for taking money and depositing money also.


3. Design of ATM system


1. Login


This use case describes how the user logs into the System.

1.2 Flow of events:

1.2.1 Basic flow:

This use case starts with the actor wishes to log in to the ATM System.

1. The system requests the user to enter the name and PIN.2. The actor enters the name and PIN.3. The system validates the name and the PIN and logs the user into the system.


login

customer

ask login id()display error message()

atm system

transaction (withdrawal)

bank

database

maintain customer information

administrator

1. If the user enters the wrong name and the PIN then the system displays an error message.

2. The actor can either return to the basic flow or cancel login at which point use case ends.

1.3 Pre conditions:

None


User will perform corresponding transaction.

2. Transaction


This describes the transaction that the user is doing.

2.2 Flow of events:

2.2.1 Basic flow:

This use case starts after the user has logged on to the system.

1. The system requests the user to enter the type of transaction of either withdrawal or deposit and asks for customer information.2. The actor enters the type of transaction and the customer

information.3. The system displays the corresponding transaction screen.


If the customer enters any wrong information then the system displays an error message.

2.3 Pre Condition:

The user logs on to the system.

2.4 Post Condition:

Based on the transaction he gets the transaction screen.

3. Maintain Information about Customer


This describes how administrator takes care of customer information.

3.2 Flow of events:

3.2.1 Basic flow:

This use case starts after the administrator has logged into the system.1. The system asks the administrator whether he wants to add or

delete customer information.2. The administrator then enters the type of maintenance.


None

3.3 Pre Condition:

The administrator logs on to the system before this use case begin.

3.4 Post Condition:

Administrator gets the corresponding maintenance screen according to his choice.

3.2.1.1 Adding Customer

3.2.1.1.1 Basic flow:

1. This use case starts when the administrator has chosen to add customer’s information.

2. The system asks the administrator to enter customer information.3. The administrator enters the customer information.4. The system displays the updated information.

3.2.1.1.2 Alternative flow:

If the administrator enters any wrong information the system displays an error message.

3.2.1.2 Deleting Customer


1. This use case starts when the administrator has chosen to delete an existing customer from the system.

2. The system asks the administrator to enter the customer information.

3. Administrator enters the corresponding user information.4. The system then displays updated results.


If the administrator has entered any wrong information then the system displays administrator error message.

3.2.1.3 Updating an existing Customer account


1. This use case starts when the administrator has chosen to update the customer’s information.

2. The system asks the administrator to enter the customer information.

3. The administrator enters the customer information.4. The system displays the updated information.


If the administrator has entered any wrong information then the system displays administrator error message.

SEQUENCE DIAGRAM

1. Login:

2. Maintenance:

: customermain window login window login

controllerwelcome

screenerror message

1: run atm()

2: ask login id()

3: provide login id()

4: verification()

5: successful()

6: un successfull()

7: display error message()

: administratormain window maintanance

window

1: ask type of maintanence

2: provide information

3: add

4: delete

5: updete customer information

sequence diagram

sequence diagram

sequence diagram

3. Adding customer:

: administratoradd customer

informationadd customer error message

form : database

1: request customer information

2: provide customer information

3: verification

4: valid information

5: display error message

6: re-enter

4. Deleting customer:

: administratormaintenance

windowdelete

customererror message updete

database

1: ask customer details


3: valid details

4: remove form database

5: invalid details


5. Updating customer:

: administratormaintain

windowupdate database

error message


2: enter customer details

3: correct details

4: incorrect details


6. Transaction:

COLLABORATION DIAGRAM:

: customertransaction

screenupdate database

error message

1: initiate transaction


3: correct

4: incorrect


1. Login:

2. Maintenance:

: customer

main window

login window

login controller

welcome screen

error message

1: run atm()

2: ask login id()

3: provide login id() 4: verification()

5: successful()

6: un successfull()


: administrator

main window

maintanance window

1: ask type of maintanence


3: add4: delete

5: updete customer information

3. Adding customer:

4. Deleting customer:

5. Updating customer:

: administrator

add customer information

add customer

error message form

: database

1: request customer information

2: provide customer informat...6: re-enter

3: verification

4: valid information


: administrator

maintenance window

delete customer

error message

updete database


2: provide information 3: valid details

5: invalid details

4: remove form database6: display error message

6. Transaction:

: administrator

maintain window

update database error

message


2: enter customer details

3: correct details

4: incorrect details


: customer

transaction screen

update database

error message

1: initiate transaction


3: correct

4: incorrect


STATE CHART DIAGRAM

initilisation

adddelete

update

event(add record)[fullfill bank req]/rec is added to the datab...

event(delete record)[bank balance less than request]/ record is dele...

CLASS DIAGRAM

1.Login

login contooller

login window

welcome message

customer


error message.<< >>

main window

2. Transaction:

COMPONENT DIAGRAM

generate report<< >>

update database<< >>

error message.<< >>

customer


transaction screen

initiate transaction()provide information()

<< >>

+1...*

+1

+1

+1

+0...*

+1

login<< >>

transaction

<< >>

maintain customer information

<< >>

SOURCE CODE:

1. Login

Option Explicit

Public NewProperty As login_window

Public NewProperty2 As welcome_message

Public NewProperty3 As customer

Public NewProperty4 As error_message_

2. Transaction

Option Explicit

Public ____ As error_message_

Public NewProperty As customer

Public Sub initiate_transaction()

End Sub

Public Sub provide_information()

End Sub

Ex.No:4COURSE REGISTRATION SYSTEM

Date:


1.5 Introduction

This software is designed in such a way that it receives the name and other particulars from the student. Based on marks the student has scored the list of possible branches that will accommodate for the student will be displayed. Only work for the student is he has to fill the form and submit it.

1.6 Objectives

The ultimate objective of this software is to eliminate hassles that the student overcomes while registering him. This software will reduce the paper work. This also reduces the time delay.

1.3 Scope

The student is first requested to fill the form. This form will contain important particulars of the student like his name, DOB, preferred branch, his marks. Once the student fills it, a unique id number be provided. An important thing with in this is to decide made to payment to opt by the student. It may be either the demand draft or credit card information. As soon as student registered then the number of seats available displayed.


As project developers we developed a new course registration system to replace the existing manual registration since manual system are prone to errors and take more time.

The system made by user friendly and reduce the burden of users. Our system can be made available even in the website of our college.

Students can easily register the course in our system without any difficulty and can easily understand and also time taken for registration is less when compared to manual registration. Options are given to the student to select their elective and also it shows the number of papers available along with the number of student who have registered and also the number of days for particular elective per semester also displayed at the side. This makes your work easier for you than when you register manually since you need to make a copy of HOD, staff separately that even if one is missed the whole process is to be redone. Your information will be stored as soon as you registered. As you can see registration form again separate id and password to see the registration form and also number of forms updated this is to prevent from unauthorized access.

They can see the number of students registered for the particular paper. So that if the registration does not satisfy the number then particular course is a bonded.

Fees structure for the course too is provided on the particular paper so that the student may get the proper information about the fees too. Here database administrator keeps record of every database and he updates the database whenever registration takes place. Administrator provides id for students and staff to access the system. Billing information if necessary is also updated.

This is fast when compared to manual intervention since separate form should be provided to HOD, staff, administrator which takes more time for registering and even if student wants to view the record it takes more time where as the system designed does not need any manual intervention.

2. Problem statement (Use case) analysis


i Loginii Registrationiii Course details


i Student ii Staffiii Databaseiv Database Administrator


3. Design of Course Registration System


1. Login


This use case describes how the user logs into the system.

1.2 Flow of events:

1.2.1 Basic flow:

1. The system requests the actor to enter the name and the password.2. The actor enters the name and the password.3. The system validates the entered name and the password and logs the actor in to the system.


student course details

staffdatabase

administrator

database

login

registration

1. If in the basic flow the actor enters the invalid name or password the display an error message.2. The actor can choose either to return to the beginning of the basic flow or cancel the login at which point use ends.

1.3 Pre conditions:

None


The use case was successful and the actor is now logged into the system. If not the system state is unchanged.

2. Registration


The student uses this use case for registration.

2.2 Flow of events:

2.2.1 Basic flow:

1. The actor asks for the registration form.2. The registration form asks for the student’s details.3. The actor enters the details.4. The form control checks for the validation. It will check for the elective details(i.e. whenever the elective preferred by the student is available).5. If the contents are valid then the details will be stored in the database and confirmation message will be displayed.


1. If the elective preferred by the student is not available the appropriate message will be displayed.

2. If the registration form ids complete then the appropriate message is displayed.

3. The student will have now registered the form again.

2.3 Pre Condition:

The administrator must be logged on to the system.

2.4 Post Condition:

If the use case was successful the student he/she can come out of the use case of if the registration was not successful then the student can apply for the registration again.

3. Course details


This use case is starts when the user wished to see about the elective.

3.2 Flow of events:

3.2.1 Basic flow:

This use case starts when the user wishes to see about the elective details of the course.

The user will, select the course.

1. The course will validate the request.2. After validation the form control will display the request details.


If the user starts for the details of the elective that is not offered then the error message will be displayed.

3.3 Pre Condition:

The actor will need to have successfully logged in.

3.4 Post Condition:

If the actor has successfully seen the course details then he/she come out of use case else try.

SEQUENCE DIAGRAM

1. Login

: student Main window Login window login control welcome window

error message

1: Logging

2: Asking for ID

3: verification

4: valid

5: invalid

6: error message

7: relogin cancel

2. Registration:

: studentregistration

fromfrom control error message : database

1: registration()

2: request for details()

3: enters details()

4: validation()

5: verfy elective details(())

6: store details()

7: confirm message()

8: invalid elective details()

9: display()

10: invalid()

11: re-registration()

2. Course details:

: studentcourse form course form

controlerror message : database

1: select course()

2: validation()

3: Get course information()

4: display course information()

5: invalid()



1. Login:

2. Registration:

: student

Main window

Login window

login control

welcome window

error message

1: Logging

2: Asking for ID7: relogin cancel

3: verification

4: valid

5: invalid

6: error message

3. Course details:

: student

registration from

from control

error message

: database

5: verfy elective details(())

1: registration()3: enters details()

11: re-registration()

2: request for details()4: validation()

6: store details()

7: confirm message()10: invalid()

8: invalid elective details()

9: display()

: student

course form

course form controlerror

message

: database

1: select course()

2: validation()

3: Get course information()

4: display course information()

5: invalid()


STATE CHART DIAGRAM

CLASS DIAGRAM

1. Login

initialize

open

student registered=student registere...students registered>...

closestudent registered <20

cancel

2. Registration:

3. Course details:

COMPONENT DIAGRAM

login control<<Class Module>> error message

<<Class Module>>

main window<<Class Module>>

welcome window<<Class Module>>

login window<<Class Module>>

+1

+1

+1

+1

control form<<Class Module>>

error message<<Class Module>>

registration form<<Class Module>>+1 +1

+0..*

+1

course form control<<Class Module>>

error message<<Class Module>>

course form control<<Class Module>>+1 +1

+0..* +1

CLASS CODE:

1. Login

Option Explicit

Public NewProperty As welcome_window

Public NewProperty2 As welcome_window

2. Registration

Option Explicit

Public NewProperty As control_form

Public ____ As error_message

3. Course details

Option Explicit

Public NewProperty As course_form_control

validation<<ActiveX DLL>>

view courses details

<<ActiveX DLL>>

login<<ActiveX DLL>>

security<<ActiveX DLL>>

registration<<ActiveX DLL>>

Ex.No:5

EXPERT MEDICAL SYSTEMDate:


1.1 Introduction

The expert medical system is developed to an automated means for providing medical guidance to the users. This system is user friendly and the required information, the corresponding medicines just by providing the symptoms from which the patient is suffering.

1.2 Objectives

The main objective is to provide the users with an easy way to gain information about the medicines that can effectively cure the disease of the patients. The system is very befriending when the doctors are not available for the patients.

1.3 Scope

The scope of the expert medical system is to provide an efficient service to the patients especially the outpatients in a hospital. This proves to be very helpful when the doctor may not available and also for reference to know the latest medicines available to cure the disease more quickly with out any side effects. The pharmacist can also view the list of medicines in the system and order for the medicines that is not available in the stock.


The user can make use of the expert medical system by selecting the symptoms that is noticed in the patient’s body from the check box given in the form. This is the only input given to system. The system later analysis

the input and gives the medicines and the amount of dosage according to the severity of the disease and the age of the patient.

In order to access the system the user should login to the system. This is to avoid the trespassers from accessing the system data and thus enhance the security of the system. The administrator is the only authorized person to change the data in the system. The administrator maintains the details of the doctors or consultants, the disease name, the medicines to be taken for treatment for those diseases, etc. The administrator also maintains the details of the user who have created their accounts to access the system.

As the system requires huge amount of information to be stored these data are maintained by the administrator in the database. Thus the system gains the flexibility that is obvious while using a database. The administrator is the only person to access and modify the data in the database.

The user first needs to get his account created to avail themselves of the facilities of the system. Thus the user gives all the required details to the system like the name, age, the desired user name and password etc. The system then counter checks this information with the database. If it is valid then the record is created for the user in the database along with the user name and password. Then during subsequent login to the system the corresponding domain form or the main form is displayed. For example, if the user is a pharmacist then his main form is the list of medicines. If it is the administrator has logged in the main form is the list operation he needs to perform through a controller in the database.

The system is open to the users at any time. The data in the database is checked every week on Saturday and the required operations like adding, deleting or updating of the data.



i Users:

The users are the actors who can only view the medicines by selecting the symptoms.

ii Pharmacist:The pharmacist can only view the list of medicines available in the

database.

iii Doctors:The doctors are actors who can view the medicines directly without

entering the symptoms.

iv Administrator:

The administrator is the only authorized person to change the data in the database. The administrator maintains the information in the database.


i Login:

The use case is used by the doctors, users, pharmacist and administrators to enter the system.

ii View Medicines:

The view medicine use case is used to view all the medicines available by the doctors and pharmacist and only the prescribed medicines for the symptoms given by the user.

iii Maintain Information:

This use case is accessible only to the administrator that allows him to add, update and delete the required information directly form the database.

2.3 Use Case Diagram:

user

doctor

pharmist database

login

maintain information

view medicine

administrator

3. Design of Expert Medical System


1. Login


The login use case works the same name for any type of user. The common users, doctors, pharmacist and the administrator can login to the system.

1.2 Flow of events:

1.2.1 Basic flow:

1. The user or doctor or pharmacist or the administrator is requesting to enter the user name and password into login domain form.

2. The login controller validates this user name and password by comparing the information from the database.

3. If the user name and the password are valid then their corresponding domain form is displayed.


1. If the user name and password is invalid the control shifts back to login domain form.

2. The user re-enters the user name and password or exists.

1.3 Pre conditions:

None


The use case was successful and the actor is now logged into the system. If not the system state is unchanged.

2. View Medicines


The “view medicines” use case is where the main output of the system is obtained. The user, the pharmacist and the doctors can view the medicine.

2.2 Flow of events:

2.2.1 Basic flow:

1. The domain form of the user request the user to select the symptoms displayed in the domain form.

2. The user selects the symptoms from the domain form.3. The domain controller using the information from the

database validates the symptoms selected.4. If the corresponding medicine is found the system displays

the medicines along with the dosage according to the age and severity of the disease.


If the medicines are not prescribed properly then it is better to approach the consultant.

2.3 Pre Condition:

The user must have logged into the system.

2.4 Post Condition:

The user gets information of the medicines and their dosage.

3. Maintain Information


This “maintain information” use case maintains various kinds of information needed for the system in the database. The administrator performs this work only. The important operations or functions performed are add, deleted and update.

3.2 Flow of events:

3.2.1 Basic flow:

1. The administrator’s domain form or the main form is first displayed when the administrator has successfully logged into the system.

2. The domain form request the administrator to select any of the operations listed on the domain form.

3. The administrator selects the required operation from the domain form.

4. Based on the operations selected the control is shifted to that operation.

3.2.1.1 Add


1. The system request the information to be added into the database, for example, the name, age, address, etc. of the doctors.

2. The administrator also provides the requested information to the system.

3. The system validates this information with the database and forms a record in the corresponding table.


1. An error message occurs when the user information given is not matching the format as per the database.

2. The administrator gives the correct format or exists the system.

3.2.1.2 Delete


1. The system requests the id of the doctor whose record is to be deleted.

2. The administrator also provides the information.3. The system validates this information with the database and

deletes the record in the corresponding table.


1. The error message is shown to the administrator if invalid ID number is entered.

2. The administrator re-enters the information or exists the system.

3.2.1.3 Update


1. The system requires the information to be updated into the database, for example, the name, age, address, etc. of the doctors.

2. The administrator also provides the requested information.3. The system validates this information with the database and

updates the record in the corresponding table.


1. An error message occurs if an invalid field name is entered into the system.



1. An error message occurs when the information given is not sufficient.


3.3 Pre Condition:

None

3.4 Post Condition:

The administrator must have logged into the system.

SEQUENCE DIAGRAM

1.Login

: user log on login controller

welcome screen

error message : database

1: enter user name & pwd( )

2: get information from the database( )

3: checking the user name & pwd( )

4: valid user name & pwd( )

5: invalid user name & pwd( )

6: display the error message to the user( )

7: re-invoke the form again( )

2. View of medicines by the user

3.Administrator Domain Form

: usersymptoms symptom

controllererror messageMedicine List

4: validate( )

1: Request for symptoms( )

2: Enter the symptoms( )3: Get the medical information( )

5: Valid( )

6: Dispaly the medicine list( )

7: Invalid( )

8: Dispaly error emssage( )

: administrator admin domain controller

option contorller

1: request for selecting of operation( )

2: selection of operation( )

3: add an option( )

4: delete an option( )

5: update an option( )

sequence diagram

sequence diagram

sequence diagram

3.1 Adding of Information to the Database

3.2 Deleting of Information from Database

: administratoradd form add form

controllererror message

: database

1: request to give details( )

2: select the necessary details( )

3: validating the given details( )

4: getting information from the database( )

5: invalid details( )

: administratordelete form delete form

controller : database

1: request for details( )

2: enter the details( )

3: validation and confirmation( )

4: querries deleted from database( )

5: [valid]send ack. about deletion( )

6: [invalid]unsuccessful mission( )

3.3 Updating of Information from Database

: administratorupdate form update form

controller : database

1: request details for update( )

2: give the details of updation( )

3: validate( )

4: querries and update the form( )

5: send ack. of successful updation( )

6: unsuccessful mission( )

3.3 Collaboration diagram 1.Login

2.View of Medicines by the User

: user

log on login controller

welcome screen

error message

: database

1: enter user name & pwd( )

2: get information from the database( )

3: checking the user name & pwd( )4: valid user name & pwd( )

5: invalid user name & pwd( )6: display the error message to the user( )

7: re-invoke the form again( )

symptoms symptom controller

error message

4: validate( )

: user1: Request for symptoms( )

2: Enter the symptoms( )

Medicine List

3: Get the medical information( )5: Valid( )

6: Dispaly the medicine list( )

7: Invalid( )

8: Dispaly error emssage( )



: administrator

admin domain controller

option contorller

1: request for selecting of operation( )

2: selection of operation( )

3: add an option( )4: delete an option( )5: update an option( )

: administrator

add form add form controller

error message

: database

1: request to give details( )

2: select the necessary details( )

3: validating the given details( ) 5: invalid details( )

4: getting information from the database( )


3.3 Updating of information from Database

: administrator

delete form delete form controller

: database

1: request for details( )

2: enter the details( )

3: validation and confirmation( )

4: querries deleted from database( )

5: [valid]send ack. about deletion( )6: [invalid]unsuccessful mission( )

: administrator

update form

update form controller

: database

1: request details for update( )

2: give the details of updation( )

3: validate( )

4: querries and update the form( )

5: send ack. of successful updation( )6: unsuccessful mission( )

3.4 Class Diagram1.Login

2.Viewing Medicines by the User

user

welcome_screen<< >>

error_message<< >>

log_on<< >>

login_controller<< >>

main_form<< >>+1+1

+1

+1

+1

+1

+1

+1

+1+1

user

symptoms<< >>+1...*+1...*

symptom_controller<< >>

medicine_list_<< >>

+*

+1



administrator

admin_domain_controller<< >>+1+1

option_controller<< >>

+1

+1..*

administrator database

error_msg<< >>

add_form_controller<< >>

add_form<< >>

+1..*

+1

+1

+1


3.3 Updation of Information from Database


delete_from_controller<< >>

delete_form<< >>

+1

+1


update_controller<< >>

update_form<< >>

+1

+1

3.5 State Chart Diagram 1.Login

get the user input

get the information from the database

error message

welcome screen

reinvoke the login form again

check:invalid

check:valid

2.Viewing of Medicines

get the symptoms list from the user

validate the input refer to the

database

check

gives the medicines from medicine list display error

message

check:valid input check:invalid input


get theselected operations

delete operation

delete domain form

add operation

add domain form

update form

update domain form


get the input details

check for the correct input

add details to the database

show error message

check:valid chech:invalid

refer to the database


delete the details from database

chech:valid

get the input details

check for the correct input

refer to the database

show error message

check:invalid

3.6 Component Diagram

login<< >>

view medicine

<< >>

security<< >>

maintaining information for the medicine

<< >>

maintainini information for doctors

<< >>

CLASS CODE:

1.Login

Option Explicit

Public NewProperty As login_controller

2.Viewing medicine by the User

Option Explicit

Public NewProperty As symptom_controller_from_add_form_controller_


Option Explicit

Public NewProperty As admin_domain_controller

3.1 Adding of information to the database Option Explicit

Public ___ As error_msg

Public NewProperty As add_form_controller

3.2 Deleting of information from Database

Option Explicit

Public NewProperty As delete_from_controller

3.3 Updating of Information from Database

Option Explicit

Public NewProperty As update_controller

Ex.No:6REMOTE COMPUTER MONITORING SYSTEM

Date:


1.7 Introduction

Remote Computer monitoring system is designed to monitor the clients in the network with the help of databases. This system works on the basis of client-server interaction. For security reasons clients only areas pertained to them.

1.8 Objectives

To build a remote computer monitoring system. This system retains information about all the clients in the system network.

1.3 Scope

The institution needs a client server system where the server controls the data needed to do the required work.


You are tasked to build a new remote computer monitoring system. The institution needs a client-server system where the server controls the data (information, files and computer programs) needed to do the required work.

The client server system’s computing is important since it centralizes the control of data. This new system will have a windows based desktop interface where the server monitors the clients connected by network. For reasons of security, clients can only access areas pertained to them.

The server will retain information of all clients in the system network. The existing database supports the necessities of the clients. The server will access, but not update information stored in the client database.

The system administrator maintains client information. He performs the key role of adding/ removing/ updating clients as well as running the administrative reports. Students only do the work pertained to them.

Professor does his work and also checks the activities of the students over the network. The HOD monitors the clients through the network.

Finally, the management checks the activities of students, professor and HODs.



i Loginii Students work with lab exerciseiii Monitor studentsiv Maintain client information


i Studentii Professor/HODiii Administratoriv ManagementDatabase1(current working environment)v Database2(student details)vi Login Controller


Studentswork with lab exercise

Login

Database1

Professor/HOD

monitor students

add/remove clients

Administrator

Database2

monitor professor/HOD

Management

3. Design of Students Mark analyzing System


1. Login


This use case describes how a client logs into the system.

1.2 Flow of events:

1.2.1 Basic flow:

This use case starts with the actor wishes to log in to the MAS.

1. The system requests the actor to enter the user name and password.2. The actor enters their name and password.3. The system validates he entered user name and password.4. Logs the actor into the system.


1. If the actor enters a wrong username and password, the system displays an error Message.

2. The actor can choose to either reenter the details or cancel the login.

1.3 Pre conditions:

None


1. If the use case was successful, the user has now logged into the system, if not the system is unchanged.

2. Student work with lab exercise


Student starts working with lab exercise. He is restricted to work with his area.

2.2 Flow of events:

2.2.1 Basic flow:

1. Students start working with lab exercise.2. Saves his work.3. Quits.


If user opens those applications which he is not permitted to error message is displayed.

2.3 Pre Condition:

None

2.4 Post Condition:

None

3. Monitoring Students


Professor/HOD can monitor students by choosing the students by referring to database2.

3.2 Flow of events:

3.2.1 Basic flow:

1. Select the student to monitor.2. System gets details from database2.3. Compares it with already stored details in database1.4. Quits.


If the database2 does not match with database1 an error message is displayed.

3.3 Pre Condition:

Login

3.4 Post Condition:

Professor/HOD selects next operation.

4. Maintain Client Information


Database administrator can add/delete/update any client in database.

4.2 Flow of events:

4.2.1 Basic flow:

This use case starts when the administrator wants to add/delete/update the database.

1. Display a selection form.2. Request user to select any of the three operations

(add/delete/update).3. User enters his selection.

4.2.1.1 Add


This use case starts when the administrator wants to add a new client to the database.

1. Display the add form.2. Request the administrator to enter the name, phone number, address

and other details.3. Administrator enters the details.4. System generates the user id.5. Returns it to the administrator.


1. If any of the required details is not entered display an error message.

2. If the details are already present in the database display an error message.

3. User enters the remaining details.

4.2.1.2 Delete


This use case starts when the administrator wants to delete a new client to the database.

1. Display the delete form.2. Request the administrator to enter the id of the client to be deleted.3. Administrator enters the id.4. Display confirmation message.


1. If the id entered by the user is not available in the database error is displayed.

2. The administrator to either return to the beginning of the basic flow or cancel the delete option.

4.2.1.3 Updating an existing Customer account


1. Display the update form.2. Request the administrator to enter the id of the client to be updated.3. Administrator enters the id.4. Display the record.5. User can change the required details.


1. If the id entered by the user is not available in the database error is displayed.

2. The administrator to either return to the beginning of the basic flow or cancel the delete option.


None

4.3 Pre Condition:

Login

4.4 Post Condition:

Report Generation.

SEQUENCE DIAGRAM

1. Login

: Professor/HODMain form Login form Login

ControllerError message Welcome

message

login( )

Request for username and password( )

Enter username and password( )

Verification( )

Valid entry( )

Display welcome message( )

Invalid entry( )

Display an error message( )

re-entry /cancel( )

2. Students working with lab exercise

3. Monitor Students

: Students Lab exercise : Database1

Work with lab exercise( )

record the current workspace( )

4. Maintain client information

: Professor/HOD Selector form Domain controller : Database1 : Database2 Report

login( )

Request for student details( )

Get details about current working( )

Details already stored in the file( )

Compares( )

Valid(generates report)

Invalid(operation mismatch)

: AdministratorSelection

formSelection controller

Report

Request for selection( )

Select an operation(add/delete/update)

add option( )

delete option( )

Update option( )

Sequence diagram...

Sequence diagram-...

Sequence diagram...

4.1 Add

: AdministratorEntry form Error message

: Database1Entry

controller

Request admin to enter client details( )

admin enter details( )

Re-enter/cancel( )

Verification( )

Valid(sys generates new id &adds client)

invalid(details missing)

Display error message( )

4.2 Delete

: AdministratorEntry form Entry

controllerError message

: Database1

request to enter client details to be deleted( )

admin enter id( )

verification( )()

valid(id available,client deleted)

invalid(id not available)

Display error message( )

re-enter /cancel( )

4.3 Update

COLLOBORATION DIAGRAM

: AdministratorEntry form Entry

controllerError message

: Database1

Request admin to enter client details to be updated( )

admin enters id( )

Verification( )

valid(sys displays the rec for admin to update)

invalid(id not exist)

Displays an error message( )

re-enter/cancel( )

1. Login


3. Monitor Students

: Professor/HOD

Main form

Login form

Login Controller

Error message

Welcome message

1: login( )9: re-entry /cancel( )

2: Request for username and password( )

3: Enter username and password( )

4: Verification( )

5: Valid entry( )

7: Invalid entry( )

8: Display an error message( )

6: Dispalay welcome message( )

: Students

Lab exercise

: Database1

1: Work with lab exercise( ) 2: record the current workspace( )

: Professor/HOD

Selector form

Domain controller

: Database1

: Database2

Report

5: Compares( )

1: login( )

2: Request for student details( )

3: Get details about current working( )

4: Details already stored in the file( )

6: Valid(generates report)

7: Invalid(operation mismatch)

4. Maintain client Information

4.1 Add

4.2 Delete

: Administrator

Selection

form


Report

1: Request for selection( )

2: Select an operation(add/delete/update)

3: add option( )4: delete option( )5: Update option( )

: Administrator

Entry form

Error message

: Database1

Entry controller

1: Request admin to enter client details( )

2: admin enter details( )7: Re-enter/cancel( )

3: Verification( )6: Display error message( )

4: Valid(sys generates new id &adds client)

5: invalid(details missing)

4.3 Update

STATECHART DIAGRAM

: Administrator

Entry form

Entry controller

Error message

: Database1

1: request to enter client details to be deleted( )

2: admin enter id( )7: re-enter /cancel( ) 3: verification( )()

4: valid(id available,client deleted)

5: invalid(id not available)

6: Display error message( )

: Administrator

Entry form

Entry controller

Error message

: Database1

1: Request admin to enter client details to be updated( )

2: admin enters id( )7: re-enter/cancel( ) 3: Verification( )

4: valid(sys displays the rec for admin to update)

5: invalid(id not exist)

6: Displays an error message( )

CLASS DIAGRAM

1. Login

Server monitor students

Lock

Cancel

stud current ex=lab ex

stud current page<>lab...

trans_monitor( stud current ex )[ stud current ex=lab e...

stud current page=lab...


3. Monitor Students

user

namepassword

enter name and password()

Login Controller

validate()

Error message

display()

Welcome form

validate()

Login form

get()

Main form

display()

Students

Lab exercise

programs

execute programs()opname()

Database1

current working details

record current details()

4. Maintain client information

4.1 Add

selection form

login()Database2

details of studentmonitoring details

maintenance()

Database1



Professor/HOD

report

print()

Domain controller

refers()validate()

administrator

Selection form

login()

add form

delete form

update form

entry controller

validate()

error message

display()

report

print()


validate()

4.2 Delete

4.3 Update

Administrator

entry formdetails to be updated

get()

error message

display()

entry controller

validate()

Database1



Administrator

Entry formdetails to be updated

get()

Error message

display()

entry controller

validate()

Database1



Administrator

entry formdetails to be updated

get()

Error message

display()

entry controller

validate()

Database1



COMPONENT DIAGRAM

CLASS CODE:

1.Login

Option Explicit

Private name As Variant

Private password As Variant

Public Sub enter_name_and_password()

End Sub

2.Students working with lab exercise

Option Explicit

Private programs As Variant

Public Sub execute_programs()

End Sub

Public Sub opname()

Login Monitor Students

Students working with lab exercise

Maintain client information

End Sub

3.Monitor StudentsOption Explicit

Public Sub login()

End Sub

4.Maintain client informationOption Explicit

Public NewProperty As report

Public Sub validate()

End Sub

4.1AddOption Explicit

Private details_to_be_updated As Variant

Public Sub get()

End Sub

4.2DeleteOption Explicit

Public Sub validate()

End Sub

4.3UpdateOption ExplicitPublic NewProperty As Main_formPublic Sub display()End Sub

Ex.No:7QUIZ SYSTEM

Date:


1.9 Introduction

Quizzing systems are generally used to test the knowledge of an individual person. But persons in technical arena should be well stuffed in both technical and non-technical sides. So this system is basically used to test the professionals.

1.10 Objectives

The main objective of this quizzing system is to replace the existing hand written system with a fully computerized system that would easily and exactly calculate the intellectual capabilities of a person.

1.3 Scope

Earlier hand written test were conducted and it was tedious and time consuming to correct the papers. Even it had a greater probability towards errors. So the scope the system is that it will ease the trends followed in current quizzing system.


The project requires an efficient quizzing system to access the student’s of third year IT based on the skills in various subjects. It generates report of all the students who taken up the test and stores it for future use. Access rights are allocated in following order.

Administrator->Professors/H.O.D->Students

The administrator is given rights only to add or delete student profiles. But has no rights to access the quizzing information. Professors and lecturers

are given rights to access the question available and if needed, make changes to them. They can also access the report database to view the overall and individual performance of the students and then take the necessary action. All the reports and queries are at their disposal.

Students are the end users of the system. They attend the quizzing session and their marks are added to the database final reporting is done based on their performances. The student cannot access any of the databases including the questions, report or the profile database. Each student is given a username and password to ensure the security.

The quizzing system is basically objective and all the questions are related to the course subject offered for that year. The session is fixed for each student and the questions carry a time limit within which the students are supposed to answer the questions. Otherwise the question lapses and no points are awarded for that question. The student has the ability to pass the question and answer the question later within the remaining time left.

The quiz program enables us to save time on assessment. It also provides instant results to the users. The assessment provided by the system is accurate and helps the professors to decide the further course of action. It is also very efficient as there is no manual intervention.



i Login:

‘Login’ describes how the user logs into a quizzing system.

ii Enter exam:

‘Enter Exam’ describes how a student enters into questioning part of quizzing system.

iii View results:

‘View Result’ describes how a user views results after reporting.

iv Maintain questions & answers:

This use case helps the professors/H.O.D to add, delete or change questions and answers present in the database.

v Reporting:

This use case describes how the results are taken from questioning session.


i Student:

Student is the user who attends the quizzing session and answers them. Report database are generated based on his performance.

ii Professor (or) HOD:

These users access the questions database and change the questions and answers if found necessary. They can also view the report database to view the performance of the student.

iii Administrator:

The Administrator is the only user who has access to the user profile database. He also has the rights to make changes if necessary.

iv Database:

This actor stores the entire contents of the quizzing system including databases such as report, questions and user profiles.

v Printer:

This actor prints the report database.

vi Timer:

This actor maintains the time during the quizzing the quizzing session and intimates the database to change the questions when the time elapses.


Time outEnter exam

Maintain staff and student information

Administrator Printers

Student

Database

Login Maintain questions and answers

Reporting

View results

professor/HOD

3. Design of Quiz System


1. Login


This use case describes how a user logs into a quizzing system.

1.2 Flow of events:

1.2.1 Basic flow:

This use case starts when the actor wishes to login to quizzing system

1. The system request that the actor enter name and password.2. As he enters, the system validates & user logs into the system.


1. If the actor enters an invalid user name and password, the system displays an error message.

2. The actor can either re-login or cancel it.

1.3 Pre conditions:

None


The use case was successful and the actor is now logged into the system.

2. Enter Exam


The use case describes how a student enters into questioning part of quizzing system.

2.2 Flow of events:

2.2.1 Basic flow:

1. If the student does not finish the question in the stipulated time then the question lapses and no marks are awarded.

2. After answering he has to confirm to move to next.3.He can keep in pass to answer in future.


If the actor want to quit in between; he can quit and come back to login.

2.3 Pre condition:

The user login should be a valid student’s username and password.

2.4 Post condition:

The use case was successful then finally he moves to view results.

3. View Results


This use case describes how a user views results after reporting.

3.2 Flow of events:

3.2.1 Basic flow:

1. This use case starts after the student finishes questioning.2. Now the control moves to reporting after which results are viewed.


This can also viewed by administrator/professors in detail or as a whole.

3.3 Pre condition:

Reporting is done to prepare and view results.

3.4 Post condition:

Reports are printed out.

4. Maintaining Question and Answers


The professor/HOD can add, change or delete questions and answers in this use case.

4.2 Flow of events:

4.2.1 Basic flow:

4.2.1.1 Add Form

The professor adds new Q & A when he reaches addition form.

4.2.1.2 Modify Form

Professor modifies Q & A when he reaches modification form.

4.2.1.3 Delete Form

The professor deletes Q & A required when he reaches deletion form.


He can quit to login without making any changes.

4.3 Pre Condition:

The user enters the use case if he gives only a valid professor username or password.

4.4 Post Condition:

Thus he modifies or leaves them as such and moves to login back.

5. Maintaining user profiles


The admin uses this use case for the profile maintenance.

5.2 Flow of events:

5.2.1 Basic flow:

The admin can make changes to user profiles.

5.2.1.1 Add User

The admin adds new user profiles when he reaches addition form.

5.2.1.2 Modify User

The admin modifies user profiles when he reaches modification form.

5.2.1.3 Delete User

The admin deletes user profiles required when he reaches deletion form.


He can quit the system without making any changes.

5.3 Pre condition:

The user enters the use case if he gives a valid admin password.

5.4 Post condition:

After saving or without saving he can comeback to login.

6. Reporting


The use case describes how results are brought from questioning session.

6.2 Flow of events:

6.2.1 Basic flow:

1. After performing the test, the results of individual performance is calculated.

2. It also generates overall performance of the class.


None

6.3 Pre condition:

The question answered by the students.

6.4 Post condition:

Reports are being stored into the database.

SEQUENCE DIAGRAM

1. Login

: Student Main form Login form Login controller

Welcome screen

Error message

1: Login()

2: Enter id and password()

3: Verification()

4: Valid()

5: Invalid()

6: Error message()

7: Relogin()

2.Enter Exam

: Student options form

Quizzing form

Questioning form : Database : Time out

1: Enter the quiz ( )

2: to avail options( )

3: Options taken( )

4: start time( )

5: Getting questions( )

6: time maintainance( )

7: Answer the questions( )

8: Stored( )

9: time out( )

3.View Results

4.Maintain Question & Answers

: Student : professor/HOD options form

Individual performance

Overall performance : Database

1: to see his results( )

2: Options( )


4: to see a particular record( )

5: individual record( )

6: to see overall performance( )

7: Overall performance( )

4.1Add Question & Answer

: professor/HODoptions form Question &

answer form


2: add( )

3: modify( )

4: delete( )

add Q&A sequen...

modify Q&Asequen...

delete Q&A sequen...

4.2 Modify Question & Answer

: professor/HODadd question

formadd question


: Database

1: request for new Q&A( )

2: add new questions( )

3: Validate( )

4: valid[filled properly]

5: Invalid[not filled properly]

6: Error message( )

7: retype question( )

4.3 Delete Question & Answer

: professor/HODadd question

formadd question


: Database


2: add new questions( )

3: Validate( )



6: Error message( )

7: retype question( )

5.Maintain User Details

: professor/HODdeletion form deletion


: Database

1: Request question to be deleted( )

2: select Q&A ( )

3: Intimate to database( )

4: retrieving Q&A( )

5: Verification( )

6: Valid( )

7: Invalid( )

8: Error message( )

9: re-entry( )

5.1 Add User

5.2 Modify User Details

: Administratoroptions form User profile

form


2: add user( )

3: modify user( )

4: delete user( )

add user sequen...

modify user sequen...

delete user sequen...

: Administratornew user add

formadd user controller

error message : Database

1: request for new user( )

2: adding new user( )

3: Verification( )

4: not filled properly( )

5: Error message ( )

6: filled properly( )

7: Generating ID( )

5.3 Delete User

: Administratoruser selector form

modification form

modification controller

error message : Database

1: Request to select user( )

2: select user( )

3: intimate to database( )

4: retrieve database( )

5: modifying ( )

6: Verification( )

7: Improper modification( )

8: Error message( )

9: Storing to database( )

6.Reporting

COLLOBORATION DIAGRAM1.Login

: Administratoruser selection

formdeletion form

: Database

1: selecting user( )

2: retrieving datas( )

3: Deleting( )

4: Updating( )

: DatabaseReporting controller

1: intimation( )

TRIGGER DUE TO DATABASE CHANGES

2: UPDATE( )

2.Enter Exam

3.View Results

: Student

Main form

Login form

Login controller

Welcome screen

Error message

1: Login()

2: Enter id and password()7: Relogin()

3: Verification()

4: Valid() 5: Invalid()

6: Error message()

: Student

options form

Quizzing form

Questioning form

: Database

: Time out

1: Enter the quiz ( )


7: Answer the questions( )

4: start time( )

9: time out( )5: Getting questions( )

8: Stored( )

6: time maintainance( )

3: Options taken( )


4.1 Add Question & Answer

4.2 Modify Question & Answer

: Student : professor/HOD

options form

Individual performance

Overall performance

: Database

1: to see his results( )


4: to see a particular record( )6: to see overall performance( )

2: Options( )5: individual record( )

7: Overall performance( )

: professor/HOD

options form

Question & answer form


2: add( )3: modify( )4: delete( )

: professor/HOD

add question form

add question controller

error message

: Database


2: add new questions( )7: retype question( ) 3: Validate( )



6: Error message( )

4.3 Delete Question & Answer

5.Maintain User Details

5.1 Add User

: professor/HOD

Question selection form

modify question form

modify question controller

error message

: Database

5: modify( )

1: requesting question to be selected( )

2: select question( )10: reentry( )


6: Verification( )

7: Valid

8: Invalid( )

9: Error message( )

4: retrieve( )

: professor/HOD

deletion form

deletion controller

error message

: Database

1: Request question to be deleted( )

2: select Q&A ( )9: re-entry( )

3: Intimate to database( )

4: retrieving Q&A( )5: Verification( )

6: Valid( )

7: Invalid( )

8: Error message( )

options form

: Administrator

User profile form


2: add user( )3: modify user( )4: delete user( )

5.2 Modify User Details

5.3 Delete User

6.Reporting

: Administrator

new user add form

add user controller

error message

: Database

1: request for new user( )

2: adding new user( ) 3: Verification( )

4: not filled properly( )6: filled properly( )


7: Generating ID( )

: Administrator

user selector form

modification form


error message

: Database

5: modifying ( )

1: Request to select user( )

2: select user( )


6: Verification( )

7: Improper modification( )

8: Error message( )

9: Storing to database( )

4: retrieve database( )

: Administrator

user selection form

deletion form

: Database

1: selecting user( )

3: Deleting( )

4: Updating( )

2: retrieving datas( )

STATE CHART DIAGRAM

1.Delete User

2.Update User

: Database

Reporting controller

1: intimation( )

2: UPDATE( )

admin enter into delete user form

delete controller

re-enter the details

user is deleted

enter the details

deleting again

if correct

if wrong

cancel

CLASS DIAGRAM

1.Login

2.Enter Exam

main form for updation

Updating the controller

Insufficient detail

database updation

details of user

return to main form if wrong if correct

Login Controller

Verification()

<<Class Module>>

Login form

ID and password()Re-login()

<<Class Module>>

Error message

Incorrect()

<<Class Module>>

+1

+1

Welcome screen

Correct()

<<Class Module>>

+1

+1

+1+1

Main form

login()

<<Class Module>>

+1

+1

+1+1

+1

+1

3.View Results


Questioning_form

Valid student ID &pwd()providing Q&A()options taken()Getting questions()time management()Answer the questions()

<<Class Module>>Options_form

Available_options()to_avail_options()

<<Class Module>>

+1

+NewProperty

Quizzing_form

Enter the quiz()

<<Class Module>>

+1

+NewProperty

Overall_performance

Overall records()Overall performance()To see overall performance()

<<Class Module>>

Individual_performance

To see his results()Individual records()To see a particular record()

<<Class Module>>

Options_form


<<Class Module>>

+NewProperty+1

+NewProperty

+1

Add_Questions_form

Add new question()retype question()

<<Class Module>>

Deletion_form

Selecting Q&A()Retrieving Q&A()Re-enter()

<<Class Module>>

Error message

Incorrect()

<<Class Module>>

Options_form


<<Class Module>>

+NewProperty

+1

+NewProperty

+1

Controller<<Class Module>>

+1

+1

+1

+1

+1

+1

Modify_Questions_form

Retrieve()Modify()

<<Class Module>>

+NewProperty

+1

+1

+1

5.Maintain User Profile

Error message

Incorrect()

<<Class Module>>

Modification_form

Modifying()Retrieve data()Error message()

<<Class Module>>New_user_add_form

Adding new user()

<<Class Module>>

Options_form


<<Class Module>>

+NewProperty

+1

+NewProperty

+1

Controller<<Class Module>>

+1

+1

+1

+1

+1

+1

Delete_form

Deleting()

<<Class Module>>

+NewProperty

+1

+1

+1

COMPONENT DIAGRAM

SOURCE CODE:

1. Login

Option Explicit

Public NewProperty As main_form

Public NewProperty2 As login_cintroller

Public Sub id___password()

End Sub

Public Sub relogin()

Exam<<ActiveX DLL>>

Security<<ActiveX DLL>>


Question and answer

<<ActiveX DLL>>

Profiles<<ActiveX DLL>>

End Sub

2. Enter Exam

Option Explicit

Public NewProperty As overall_performance

Public NewProperty2 As individual_performance

Public NewProperty3 As deletion_form

Public NewProperty4 As add_question_form

Public NewProperty5 As modify_questions_form

Public NewProperty6 As new_user_add_form

Public NewProperty7 As delete_form

Public NewProperty8 As modification_form

Public Sub availing_options()

End Sub

3. View Results

Option Explicit

Public NewProperty As options_form

Public Sub to_see_his_result()

End Sub

Public Sub individual_records()

End Sub

Public Sub to_see_a_particular_record()

End Sub

4. Maintain Question & Answers

Option Explicit


Public NewProperty2 As options_form

Public NewProperty3 As controller

Public Sub selecting_q___a()

End Sub

Public Sub retriving_q___a()

End Sub

Public Sub reenter()

End Sub

5. Maintain User Profile

Option Explicit


Public NewProperty2 As options_form

Public NewProperty3 As controller

Public Sub modifying()

End Sub

Public Sub retriving()

End Sub

Public Sub error_message()End Sub

Ex.No:8ONLINE RESERVATION SYSTEM

Date:


1.1 Introduction

This document deals with online ticket reservation for airlines. This document is designed in such a way that reader understands it. The use case description and other documents are described in such a way that the system reaches the people easily.

1.2 Objectives

The purpose of the document is to know about the availability of seats, airlines etc. According to the requirements passenger reserves his/her tickets.

1.3 Scope

This document for online ticket reservation for airline makes the work easy for the passenger to book these tickets. This is time consuming process and easy to book the tickets.


Computers play an integral part in day today life. It makes the work easy and faster. Every job is computerized now. So is the ticket reservation, we can book our tickets online. During the reservation of tickets the passenger has to select the origin, date of journey, passport number, etc…

The reservation counter keeps track of the passenger’s information. The system will have all the details about the airlines and the facilities

provided by them. There are various airlines provided according to the convenience of the passenger. A database is maintains by the database administrator.

There are many varieties of airlines. The passenger can select according to their convenience. Each airline has its own arrival and departure time. The journey can be within the country or across the country. So, the airlines are divided into national and international. For international passengers, the tickets are booked only after checking their visa and passport.

Each airline has three types of classes according to the convenience of passengers. The types are economy, business and first class. The vacancy of each airline can be viewed online.



i View Status:

It helps to find the availability of seats, time of flight.

ii Booking tickets:

Passengers enter his/her personal details & book the tickets.

iii Payment mode:

The payment is done either by cash or credit card.

iv Login:

The clerk logs into the system.

v Cancellation:

Passenger cancels his/her tickets with the help of clerk.

vi Report:

Administrator report is generated by the clerk.

2.2Identified Actors

i Passenger:

The person who wishes to book his / her ticket for the travel.

ii Clerk:

He is the center person who books and cancels the tickets.

iii Bank system:

If the passenger selects the mode of payment as credit card, then its actor comes in.

2.3 Use Case Diagram :

View status

Passenger

Bank System

Report

Clerk

Booking Tickets

Payment mode

Login

Database

Cancellation

3. Design of Expert Medical System


1. View status


This use case will allow the passenger to enter the airline & timing to his/her desire. Accordingly all the seats available, timing of will be displayed. These details are taken from the database

1.2 Flow of events:

1.2.1 Basic flow:

1. The passenger will choose the view status option.2. Actor enters the airline and timing.3. The list of seats available in particular airline is displayed.4. Actor chooses desired option.


1. If the time of airline is not occurred(or)2. If the seat is not available in particular airline the error message is displayed.

1.3 Pre conditions:

None


If the use case is successful the actor books the tickets in the desired airline.

2. Book Ticket


After viewing the status the passenger plans to book the ticket. He enters his personal details. The airline he has chosen and the seat he required. From the database given by the passenger are checked and saved. If there is no contradiction the tickets is booked for the passenger.

2.2 Flow of events:

2.2.1 Basic flow:

1. The passenger enters his personal details, type of airline and seat allocation.

2. From the database there criteria are checked and allotted.3. The ticket is booked and the mode of payment is

requested.

2.2.2 Alternative flow:If any of criteria like airline timing or details about passenger is

incorrect the error message is given to the passenger.

2.3 Pre Condition:

Before booking the ticket the status of the airline seat availability are checked.

2.4 Post Condition:

Then the payment mode is selected and payment is made accordingly

3. Payment Mode


For the tickets booked online two ways of payment is available. It can either be cash or by credit card. If credit card is chosen then the bank is involved to debit money from the account.

3.2 Flow of events:

3.2.1 Basic flow:

1. The payment mode is selected from the option.2. If credit card is chosen the account number and bank details

are given. 3. The receipt or acknowledgment is given back to the passenger.


If the bank details are incorrect an error message is given to the passenger.

3.3 Pre Condition:

None

3.4 Post Condition:

The acknowledgement for the payment is received by the passenger

4.Login

4.1Brief description:

This use case describes hoe the clerk logs into the system. We give the required details, if the details are correct then the clerk enters the system else he has to re-enter the details.

4.2Flow of events:

4.2.1Basic flow:

1. The system request for the username and password.2. The clerk enters the details.3. The system validates the details and logs into the system.

4.2.2Alternative flow:

1. If the details entered by the actor are incorrect an error message is displayed.

2. The actor can either re-enter the details or cancel the login use case.

4.3Pre Condition:

None

4.4Post Condition:

If the use case is successful, the actor logs into the system.

5.Cancellation

5.1Brief description:

When the passenger wishes to cancel his bookings he can do so with the help of clerk. The clerk will cancel from the database and refund the money to the passenger.

5.2Flow of events:

5.2.2 Basic flow:

1. The passenger enters his details.2. The clerk cancels the booking of the passenger.3. The database is updated.4. The refund money is calculated and given to the passenger.


If the details entered by the passenger are incorrect an error message is displayed.

5.3 Pre Condition:

The ticket has to be booked for which we can do cancellation.

5.4Post Condition:

The money to refund is calculated and given to the passenger.

6.Report


The periodic report is generated by the clerk. The details about the passenger, airline, cancellation, etc are maintained in the database. The report is generated.

6.2 Flow of events:

6.2.1 Basic flow:

The clerk extracts the required information from the database. report is generated.


None

6.3 Pre Conditions:

None

6.4 Post Conditions:

A report is generated.

SEQUENCE DIAGRAM

1.View Status

2.Booking Tickets

: PassengerEnter details:data

entry formdb controller Display Enquiry

formError message

form : Database

1: request( )[date time destination]

2: Enter details( )[enter above details]

3: refer( )[availability of seat and airlines]

4: validate( )[check entered details]

5: valid( )

6: display seat and airline status info( )

7: invalid( )

8: error message( )[re-enter data]

3.Payment mode

: Passenger data entry form db controller display form error form : Database

1: request( )

2: enter details( )

3: validate( )

4: valid( )

5: confirmation( )

6: update( )

7: invalid( )

8: error message( )

4.Login

: Passengerdata entry

formdb

controllermode

selectionerror message

form : Bank System : Database

1: request( )

2: enter details( )

3: validate( )

4: validation

5: reference

6: request to enter mode( )

7: enter mode( )

8: credit card( )

9: update( )10: by cash( )

11: invalid( )

12: error message( )

5.Cancellation

: Clerk Login form Main form Login controller

Welcome form

Error message

1: Login( )

2: request to enter details( )

3: enter details( )

4: validate( )

5: valid( )

6: display( )

7: invalid( )

8: error message( )

6.Report

COLLABORATION DIAGRAM

1.View Status

: Passengerdata entry

form

db controller error message form : Database : Clerk


2: enter details( )

3: validate( )

4: valid ( )

5: update( )

6: refund ( )

7: invalid( )

8: error message ( )

: Clerk data entry form db controller error message : Database


2: enter details( )

3: validate( )

4: update( )

5: output( )

6: invalid( )

7: error message( )

2.Booking Tickets

3.Payment mode

: Passenger

Enter details:data entry form

db controller

Display Enquiry form

Error message form

: Database

1: request( )[date time destination]

2: Enter details( )[enter above details]

4: validate( )[check entered details]

5: valid( )

7: invalid( )

6: display seat and airline status info( )

8: error message( )[re-enter data]

3: refer( )[availability of seat and airlines]

: Passenger

data entry form

db controller

display form

error form

: Database

1: request( )

2: enter details( ) 3: validate( )

4: valid( )

7: invalid( )

5: confirmation( )

6: update( )

8: error message( )

4.Login

5.Cancellation

: Passenger

data entry form

db controller

mode selection

error message form

: Bank System

: Database

4: validation

1: request( )


11: invalid( )

6: request to enter mode( )10: by cash( )

7: enter mode( )

8: credit card( )

12: error message( )

9: update( )

5: reference

: Clerk

Login form

Main form

Login controller

Welcome form

Error message

1: Login( )


3: enter details( )

4: validate( )

5: valid( )7: invalid( )

6: display( )

8: error message( )

6.Report

CLASS DIAGRAM

1.View status

: Passenger

data entry form

db controller

error message

form

: Database

: Clerk



4: valid ( )7: invalid( )8: error message ( )

5: update( )

6: refund ( )

: Clerk

data entry form

db controller

error message

: Database


2: enter details( )

3: validate( )

6: invalid( )

4: update( )

7: error message( )

5: output( )

`

2.Booking Tickets

3.Payment Mode

PassengerDatabase

Db controller

refer to database()Validate()

<<Class Module>>

Display form

confirmed()

<<Class Module>>Error message form

invalid()

<<Class Module>>

data entry form

enter details()

<<Class Module>>

+1

+1

PassengerDatabase

Db controller


<<Class Module>>

display form

confirmed()

<<Class Module>>

data entry form

enter details()

<<Class Module>>

+1

+1

Error message form

invalid()

<<Class Module>>

4.Login

5.Cancellation

Passenger

Db controller


<<Class Module>>

Bank System

Error message form

invalid()

<<Class Module>>

mode selection

valid()enter mode()

<<Class Module>>

data entry form

enter details()

<<Class Module>>

+1 +1

Clerk

Login controller

Validate()

<<Class Module>>Login informationnamepasswordID

get()

<<Class Module>>

Error message form

invalid()

<<Class Module>>

Welcome form

Validate()

<<Class Module>>

Login form

enter()reenter/cancel()

<<Class Module>>

main form

login()

<<Class Module>>

6.Report

ACTIVITY DIAGRAM

Passenger Database

Db controller


<<Class Module>>

Error message form

invalid()

<<Class Module>>

Display form

confirmed()

<<Class Module>>

Clerk

Clerk

Db controller


<<Class Module>>

Database

data entry form

enter details()

<<Class Module>>

Error message form

invalid()

<<Class Module>>

COMPONENT DIAGRAM

Enter details

Airline details

look up

Select Airline

airline specification

Enter passenger list

airline selected

Check availability

check availability

status

Lockedavailability

Mode of payment

record locked

Enter bank details

select mode

paid

cash available paid

Validatecredit card

account details

valid

invalid

Deliver ticket Update

Database

SOURCE CODE:

1. View Status:

Option Explicit

Public NewProperty As error_form

Public NewProperty2 As passenger

Public Sub enter_dataild()

End Sub

2. Booking Tickets:

Option Explicit

Private validate As Variant

Payment mode<<ActiveX DLL>>

Report<<ActiveX DLL>>

Booking tickets<<ActiveX DLL>>


View status<<ActiveX DLL>>

Cancellation<<ActiveX DLL>>

Public NewProperty As Database

Public NewProperty2 As Database

Public NewProperty3 As data_enter_form

Public Sub refer()

End Sub

3. Payment Mode:

Option Explicit

Public NewProperty As passenger

Public NewProperty2 As bank system

Public Sub valid()

End Sub

Public Sub enter_mode()

End Sub

4. Login:

Option Explicit

Public NewProperty As data_enter_form

Public Sub invalid()

End Sub

5. Cancellation:

Option Explicit

Public NewProperty As db_controller

Public Sub if_confirmed()

End Sub

6. Report:

Option Explicit

Public NewProperty As error_form

Public NewProperty2 As passenger

Public Sub enter_dataild()

End Sub

Ex.No:9

Date:REMOTE PROCEDURE CALL (RPC)

AIM: To prepare necessary documents and to develop the REMOTE PROCEDURE CALL with UML diagrams using Software Engineering Methodology.ABSTRACT: Software is to be designed to establish communication

between the client and the server in a distributed application without involving you in the details of network communication

SYSTEM SPECIFICATION:

Software Requirements: Operating system: Windows xP Language : JAVA

Hardware Requirements: Processor : Intel Pentium @ 3.06GHz RAM : 512MB DDR Hard Disk : 80GB SATA Monitor : 15’’TFT Keyboard : Multimedia Keyboard Mouse : USB Optical type

PROGRAM ANALYSIS AND PROJECT PLANNING

PROBLEM STATEMENT:

This application REMOTE PROCEDURE CALL is made from the client application code the call is actually made to the client stub. The client stub converts the call information into internal RPC format and passes the call, with the necessary information to find a server, to the client RPC run-time library which transmits it to the server system across the network. The server RPC run-time library receives the call and passes it to the server stub which converts the information from RPC format to application format. Then the server stub passes the call to the server where it is executed, and the whole conversion process is reversed as the call response is returned to the client.

SOFTWARE REQUIREMENT ANALYSIS

The Modules in the Project : 1. Client2. Server

In the first Module, the client has to establish connection with server by calling connect function.

After connection Establishment, the client can able to send file to the server or request file from the server.

After receiving file request the server will send the particular file to the client.

Steps to establish Connection between Client and Server:Server Client

1. Establish a listening socket and wait for connections from clients.

2. Create a client socket and attempt to connect to server.

3. Accept the client's connection attempt.

4. Send and receive data. 4. Send and receive data.

5. Close the connection. 5. Close the connection.

USECASE DIAGRAM

Server

Send File

Receive File

Client Bank

Client

DOCUMENTATION:USECASE DIAGRAM : Use case diagram is a graph of actors, set of use cases enclosed by a system

boundary, communication (participation) association between the actors and the use cases and a generalization among the use cases.

Actor: An actor represent a set of roles that user of a use case play

when interacting with the use cases. Actor identified here is the Bank client.

Use case: A use case is a description of a set of sequence of actions that a system

performs to yield result of value to an actor.The Use Cases described in this area,

1. Client2. Server The client has to establish connection with server by calling connect function.



ACTIVITY DIAGRAM:

Start

Call the Server

Edit File on Client Part

Connection from server to client

Esatblish Connection usingConnect()

Connection Not Found

Close the System

End

Documentation:

The activity diagram describes the sequencing of activities with support for both conditional and parallel behavior.

The Activity diagram is used to describe the various activities taking place in an application. Here in our REMOTE PROCEDURE CALL, we have various activities starting from login.


Close

Server Client

1: Call the Server

4: Close the System

System Admin

2: Edit File on Client Part

3: Connection from Client to Server

Documentation:A collaboration diagram represents a collaboration, which is a set of

objects related in a particular context, and interaction, which is a set of messages exchanged among the objects within the collaboration to achieve a desired outcome.

Collaboration diagrams show exactly same information as the sequence diagram. However, collaboration diagram show this information in a different way and with different purpose.

In this collaboration diagram, the objects are represented as rectangle, the actors are stick figures. Whereas the sequence diagram illustrates the object and actor interaction overtime, the collaboration diagram shows the object and actor interaction without reference to time.

In our REMOTE PROCEDURE CALL, each object interacts with each other or collaborates with each other; it gets represented by the solid line drawn between them.

SEQUENCE DIAGRAM:

Server System Admin CloseClient

Call the Server

Edit File on Client Part

Connection from Client to Server

Close the System

Documentation:Sequence diagrams are easy and intuitive way of describing the behavior of a system by viewing the interaction between the system and its environment. A sequence diagram shows an interaction arranged in a time sequence.The objects used in this sequence diagram are,1. Client2. Server3. System Admin4. Close

The client has to establish connection with server by calling connect function.



Both the Client and server have to close the connection using Close function.

CODINGS:Server-Establishing a Listening Socket

Creating a server socket ( part of server main.cpp)

#include "ServerSocket.h"#include "SocketException.h"#include <string>int main ( int argc, int argv[] ){ try { // Create the server socket

ServerSocket server ( 30000 );

// rest of code - // accept connection, handle request, etc...

} catch ( SocketException& e ) { std::cout << "Exception was caught:" << e.description() << "\nExiting.\n"; } return 0;}

Client- Connecting to the ServerCreating a client socket ( part of client main.cpp) #include "ClientSocket.h"#include "SocketException.h"#include <iostream>#include <string>int main ( int argc, int argv[] ){ try { // Create the client socket ClientSocket client_socket ( "localhost", 30000 );

// rest of code - // send request, retrieve reply, etc...

} catch ( SocketException& e ) { std::cout << "Exception was caught:" << e.description() << "\n"; }

return 0;}

Accepting a client connection (part of servermain.cpp)

#include "ServerSocket.h"#include "SocketException.h"#include <string>

int main ( int argc, int argv[] ){ try { // Create the socket ServerSocket server ( 30000 );

while ( true ){ ServerSocket new_sock; server.accept ( new_sock );

// rest of code - // read request, send reply, etc...

} } catch ( SocketException& e ) { std::cout << "Exception was caught:" << e.description() << "\nExiting.\n"; }

return 0;}

Client and server sending and receiving Data

Implementation of a server Servermain.cpp #include "ServerSocket.h"#include "SocketException.h"#include <string>

int main ( int argc, int argv[] ){ try { // Create the socket ServerSocket server ( 30000 );

while ( true ){

ServerSocket new_sock; server.accept ( new_sock );

try { while ( true )

{ std::string data; new_sock >> data; new_sock << data;}

} catch ( SocketException& ) {}

} } catch ( SocketException& e ) { std::cout << "Exception was caught:" << e.description() << "\nExiting.\n"; }

return 0;}

Implementation of a client client.cpp#include "ClientSocket.h"#include "SocketException.h"#include <iostream>#include <string>

int main ( int argc, int argv[] ){

try {

ClientSocket client_socket ( "localhost", 30000 );

std::string reply; try

{ client_socket << "Test message."; client_socket >> reply;}

catch ( SocketException& ) {}

std::cout << "We received this response from the server:\n\"" << reply << "\"\n";;

} catch ( SocketException& e ) { std::cout << "Exception was caught:" << e.description() << "\n"; }

return 0;}

We send the string "Test Message." to the server, read the response from the server, and print out the response to std output.

Now that we've gone over the basic usage of the ClientSocket and ServerSocket classes, we can build the whole project and test it.

The following files make up our example:

MakeFile - the Makefile for this project Socket.h Socket.cpp - the Socket class, which implements the raw socket API calls. SocketException.cpp - the SocketException class

Server: Servermain.cpp- main file ServerSocket.h ,ServerSocket.cpp - the ServerSocket class

Client: Clientmain.cpp - main file ClientSocket.h ,ClientSocket.cpp - the ClientSocket class

Compile and Test

Compiling is simple. First save all of the project files into one subdirectory, then type the following at your command prompt:

prompt$ cd directory_you_just_createdprompt$ make

This will compile all of the files in the project, and create the simple_server and simple_client output files. To test these two output files, run the server in one command prompt, and then run the client in another command prompt:

OUTPUTfirst prompt:prompt$ ./simple_serverrunning....

second prompt:prompt$ ./simple_clientWe received this response from the server:"Test message."prompt$

The client will send data to the server, read the response, and print out the response to std output as shown above. You can run the client as many times as you want - the server will respond to each request.

Result: Thus the REMOTE PROCEDURE CALL is developed with all necessary documents and UML diagrams using Software Engineering methodology.

Ex.No:10

STOCK MAINTENANCE SYSTEM Date:


1.1 Introduction

The stock maintenance system is basically for the customers who access the information about the stock (here it is books in the book store) and retrieves the information.

1.2 Objectives

The purpose of the document is to define the requirements of the stock maintenance system. This supplementary specification lists the requirements that are not readily captured in the use cases of the use case model. The supplementary specification & the use case model together capture a complete set of requirement on the system.

1.3 Scope

This supplementary specification applies to the stock maintenance system. This specification defines the non-functional requirements of the system, such as reliability, usability, performance and supportability as well as functional requirements that are common across a number of use cases.


A new stock maintenance system for a book store is to replace the existing maintenance system which is in efficient. The new stock maintenance system will allow the employee to record information of the nooks available in the book store and generate report based on the total amount of sales.

The new system will has a windows based desktop interface to allow employee to enter the information of sale, purchase orders, change employee preferences and create reports. Employee can only access the information and purchase orders for security purpose.

The system retains information on all the books in the shop. The system retains the records of the cost, edition, author, publication of the books. The employee maintains the information of the sale of books. He can add the books at right time and update the database.

The customer can view the availability of the required books and the price of the books. The customer can just view them but cannot make any changes.



i Login:

It is a transaction performed by the user when he wishes to the stock maintenance system.

ii Maintain Books:

It is a transaction performed by the employee when he wishes to add, change and/or delete books information from the system.

iii Purchase orders:

It is a transaction performed by the manager when he wishes to create, change or delete purchase orders.

iv View Stock:

It is a transaction performed by the manager when he wishes to view the books available in the stock maintenance system.

v View report:

It is a transaction performed by the administrator when he wishes to view the report generated after all the stock update.


i Employee:

The employee can add, change and/or delete the information from the system.

ii Customer:

The customer can just view the books available in the system.

iii Manager:

The manager can create, change or delete purchase orders.

iv Administrator:

The administrator maintains all the database and reports. He is responsible for changing the information of database and takes care of the payment and administrative reports.

v Database

The database is the collection of data where the data is stored and form where the data can be retrieved.

2.3 Use Case Diagram:

3. Design of Stock Maintenance System


1. Login

Maintain booksEmployee

ManagerLogin

View report

Database

Purchase order

Administrator

View stockCustomer


This use case describes how a user logs into the stock maintenance system.

1.2 Flow of events:

1.2.1 Basic flow:

This use case starts when the actor wishes to login to the stock maintenance system.

1. The system requests that the actor enter the name and password.2. The actor enters their name and password.3. The system validates the entire name and password and logs the

actor into the system.


1. If in the basic flow, the actor enters an invalid name and password the system display an error message.

2. The actor can choose to either return to the beginning of the basic flow or cancel the login at which point the use case ends.

1.3 Pre Conditions:

None

1.4 Post Conditions:

If the use case successful the actor is now logged in the system, if not the system state is unchanged.

2. Maintain Books


The use case describes how employees maintains book in the system.

2.2 Flow of events:

2.2.1 Basic flow:

1. The system requests that the employee specify the function he/she would like to perform (add, update or delete). Once the employee provides requested information, one of the sub-flow is executed.

2. If the employee selected ‘add book’ then add book sub-flow is executed.

3. If the employee selected ‘update book’ then update book sub-flow is executed.

4. If the employee selected ‘delete book’ then delete book sub-flow is executed.

2.2.1.1 Add Books

1. The system requests the employee to enter the books information. This include its edition, author name, publication.

2. Once the information is provided the system generates and assigns a unique book-id number.

2.2.1.2 Update Books

1. The system requires entering id.2. The employee enters the id, the system retrieves and displays

book information.3. The employee makes desired changes to the book information.4. Once the employee updates information the system updates the

book information.

2.2.1.3 Delete Books

1. The system specifies to enter id of the book.

2. The employee enters the id, the system retrieves and displays book information.

3. The system provides employee to confirm deletion of the books.

4. The employee verifies deletion.5. The system deletes the books specified.


i. Book not found:

1. If in update books or delete books sub flow the books with specified id number does not exist, the system displays an error message.

2. The employee can then enter different id number or cancel the operation at which point the use case ends.

ii Delete Cancelled:

If information the delete books sub-flow the employee decides not to delete the book, the delete is cancelled and the basic flow is restarted at the beginning.

2.3 Pre Condition:

The employee logs in to the system.

2.4 Post Condition:

If the use case is successful, the employee maintains books successfully else the system is unchanged.

3. Purchase Orders


This use case describes how the manager provides orders for new stock in the stock in the stock maintenance system.

3.2 Flow of events:

3.2.1 Basic flow:

This use case starts when the manager wishes to record and maintain purchase orders. This includes adding, changing, and deleting purchase orders.

1. The system requests that the manager specify the function he/she would like to perform (add, change or delete).

2. Once the manager provides the required information; one of the sub flow is executed.

3. If the manager selected creates purchase order, it is executed.4. If the manager selected change purchase order, the sub flow is

executed.5. If the manager selected delete purchase order then that sub flow

is executed.

3.2.1.1 Create Purchase Orders

1. The system requests the manager to enter the purchase order information; this includes the name of the book, quantity, and edition.

2. Once the information is provided, the system generates and assigns an order number.

3.2.1.2 Change Purchase Orders

1. The system requests to enter the order number.2. The manager enters the id number; the system retrieves and

displays the information.3. The manager makes the desired changes to the orders.4. The system updates the information.

3.2.1.3 Delete Purchase Orders

1. The system requests the manager to enter the id number.2. The manager enters the number; the system retrieves and

displays information.3. The system provides manager to confirm deletion of orders.4. The manager verifies deletion.5. The system deletes the orders specified.


i. Purchase Order not found:

If in the change order or delete purchase order sub-flows, the purchase order with specified id number does not exist, the system displays an error message the manager can then enter a different number or cancel the operation at which point the use case ends.

ii. Cancel Deleted:

If in the delete purchase order sub-flow the manager decides not to delete the purchase order, the delete is cancelled and basic flow is started at the beginning.

3.3 Pre Condition:

The manager logs on the system.

3.4 Post Condition:

If the use case is successful the manager makes the purchase orders else the system is unchanged.

4. View stock


This use case describes how the customer views the stock maintenance system.

4.2 Flow of events:

4.2.1 Basic flow:

This use case starts when the customer wishes to view the books available in the system.

1. The system requests to customer to enter the details (author, name, publication, and edition) of the book required.

2. Once the information is provided the system displays the book information.


1. If in the basic flow the book specified is not found the system displays an error message.

2. The customer can enter the different book detail or cancel the operation at which point the use case ends.

4.3 Pre Condition:

None

4.4 Post Condition:

If the use case was successful the customer is provided with the information if not the system state is unchanged.5. View Report


This use case describes how the administrator views the reports in the stock maintenance system.

5.2 Flow of events:

5.2.1 Basic flow:

This use case starts when the administrator wishes to view the report generated after tall the stock update.

1. The system specifies the administrator to enter his id.2. Once the administrator is provided, the system retrieves and

displays the report.3. The administrator is provided; the system retrieves and displays

the report.


1. If the id is incorrect the system displays an error message.

2. The administrator can either re-enter the correct id or else he can cancel the operation at which point the use case ends.

5.3 Pre condition:

The administrator logs on the system.

5.4 Post condition:

If the use case is successful, the administrator views the report, if not, the system report is unchanged.

SEQUENCE DIAGRAM:

1.Login

: Customer Main form Login form Login controller

Welcome screen

Error message : Database

login( )

Enter username and password( )

Verification( )

Retrieve from database( )

Valid( )

Invalid( )

Displays error message( )

re-login( )

2.View Reports

3. View Stock

: Administratormain form controller error message

: Database

request ID( )

Enter ID( )

Verification( )

Valid( )

Generate report( )

Invalid( )


re-enter ID( )

4. Maintain Stock

4.1 Add

: Customer : Administrator Controller Error message : Database

request book details( )

Enter book details( )

Verify( )

Verified( )

Generate report( )

not filled properly( )

error message( )

: Employeeoption form book profile

form

to avail options( )

add books( )

update books( )

delete books( )

Sequence diagram...

Sequence diagram...


4.2 Modify

4.3 Delete

: EmployeeSelection

formmodification

formError message

: Database

Request for new books( )

add new books( )

Verification( )

filled properly( )

Generate ID( )

Not filled properly( )

Error message( )

: Employee Selection form

Modification form

Modification controller

Error message : Database

Request to select books( )

Selecting books( )

intimate database( )

Retrieve datas( )

modify( )

Verification( )

improper modification( )


5. Purchase Orders

5.1 Create Order

: ManagerSelection

formDeletion form

: Database

Select order( )

retrieving datas( )

Deleting( )

update( )

: Manageroption form order profile

form

avail options( )

create orders( )

change orders( )

delete orders( )


Sequence diagram...


5.2 Change Orders

5.3 Delete Orders

: Managercreate order

formcontroller Error message

: Database

Request for new order( )

Create new order( )

Verification( )

filled properly( )

Generate ID( )

not filled properly( )

Error message ( )

: Manager order selection form

modification form

modification controller : Database

Request to select order( )

Selecting order( )

intimate database( )

retrieve datas ()

modifying( )

Verification ( )

Improper modification ( )

Error message( )

Error Message


1. Login

2. View Reports

: ManagerSelection

formDeletion form

: Database

Selecting order( )

retrieving datas( )

Deleting( )

Update ( )

: Customer

Main form

Login form

Login controller

Welcome screen

Error message

: Database

1: login( )

2: Enter username and password( )

3: Verification( )

5: Valid( )

6: Invalid( )

7: Displays error message( )

8: re-login( )

4: Retrieve from database( )

3. View Stock

4. Maintain Stock

: Administrator

main form

controller

error message

1: request ID( )

2: Enter ID( )3: Verification( )


8: re-enter ID( )

: Database

5: Generate report( )

6: Invalid( )

4: Valid( )

: Customer

: Administrator

Controll

er

Error message

: Database

1: request book details( )

2: Enter book details( )

3: Verify( )

4: Verified( )

5: Generate report( ) 6: not filled properly( )

7: error message( )

4.1 Add

4.2 Modify

4.3 Delete

: Employee

option

formbook profile

form


2: add books( )3: update books( )4: delete books( )

: Employee

Selection form

modification form

Error message

: Database

1: Request for new books( )

2: add new books( )

3: Verification( )5: Generate ID( )

7: Error message( )


6: Not filled properly( )

: Employee

Selection form

Modification form

Modification controller

Error message

: Database1: Request to select books( )

2: Selecting books( )

3: intimate database( )

4: Retrieve datas( )

5: modify( )

6: Verification( )

7: improper modification( )


5. Purchasing Orders

5.1 Create Orders

5.2 Change Orders

: Manager

Selection form

Deletion form

: Database

1: Select the book( )

2: retrieving datas( )3: Deleting( )

4: update( )

: Manager

option form

order profile form

1: avail options( )

2: create orders( )3: change orders( )4: delete orders( )

: Manager

create order form

controller

Error message

: Database

1: Request for new order( )

2: Create new order( )

3: Verification( )


5: Generate ID( )

6: not filled properly( )


5.3 Delete Orders

CLASS DIAGRAM:

1. Login

: Manager

order selection form

modification form


error message

: Database1: Request to select order( )

2: Selecting order( )

3: intimate database( )

4: retrieve datas ()

5: modifying( )

6: Verification ( )

7: Improper modification ( )

8: Error message( )

: Manager

Selection form

Deletion form

: Database

1: Selecting order( )

2: retrieving datas( )3: Deleting( )

4: Update ( )

2. Maintain Books

3. Purchase Orders

Login form

username()

password()re-login()

Error Message

incorrect()

Main form

login ()

Welcome screen

correct()enter()

Login Controller

verification()

+1 +1

+1

+1

Update books

enter id()change()update()

Delete books

retrieve details

confirm()verify()delete specified()

Add books

book information

edition()author name()publication()

4. View stock & Report

3.5 Component diagram

Create purchase orders

assign order

name of the book()

quantities()edition()

Change purchase order

Identify ID()desired changes()

updates()

Delete purchase

order

request()confirm()

deletion()displays()

view stock

verification()

book details

books available

book required()book specification()

displays()

report

administrator report

enter hid ID()retrieves and displays()track()

CLASS CODE

1.Login

Option Explicit

Public NewProperty As Welcome screen

Public NewProperty2 As Error message

Public Sub login()

End Sub

2.Maintain Books

Option Explicit

Private book_information As Variant

maintain

booksview reports

view stock

Login

purchase

orders

Public NewProperty As Update books

Public NewProperty2 As Delete books

Public Sub edition()

End Sub

Public Sub author_name()

End Sub

Public Sub publication()

End Sub

3.Purchase OrdersOption Explicit

Private assign_order As Variant

Public NewProperty As Change purchase order

Public Sub name_of_the_book()

End Sub

Public Sub quantities()

End Sub

Public Sub edition()

End Sub

4.View stock

Option Explicit

Private books_available As Variant

Public NewProperty As view stock

Public NewProperty2 As report

Public Sub book_required()

End Sub

Public Sub book_specification()

End Sub

Public Sub displays()

End Sub

Date post:	18-Dec-2014
Category:	Documents
Upload:	dina27nov
View:	243 times
Download:	22 times

Ooad Lab Final Manual1

Documents