Ooad Lab Final Manual1

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

CASE TOOLS LAB IT1333 LAB MANUAL

PREPARED BY S.RAVI ASSISTANT PROFESSOR S.S DEPARTMENT CSE

UNDER THE GUIDANCE OF DR. M ROBERTS MASILLAMANI DEAN (CS) SCHOOL OF COMPUTING SCIENCES

IT1333

CASE TOOLS LAB

L 0

T 0

P 3

C 1

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

TCH 3

Ex.No:1

Study Of UML

Date:

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

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.

Actor An 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 Case A 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.

Association Associations 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.

Lifeline The Lifeline identifies the existence of the object over time. The notation for a Lifeline is a vertical dotted line extending from an object.

Activation Activations, 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 bidirectional. 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 0..1 0..* or * 1 1..* Every class diagram

Meaning zero or one instance. The notation n . . m indicates n to m instances. no limit on the number of instances (including none). exactly one instance at least one instance 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:2 Date:

STUDENT MARK ANALYZING SYSTEM

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

login

mark entry administrator

database

mark analysis

mark analyser

maintain student information

student

Placement officer

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 2.1 Brief description: 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.

2.2.2

Alternative flow: 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 3.1

Brief description:

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.

3.2.2 Alternative flow: 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 4.1 Brief description: 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.

4.2.2 Alternative flow: 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 5.1 Brief description: 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.

5.2.2 Alternative flow: 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

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()

: Database

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. Maintain Student Information

: 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() sequence diagram... 5: Delete option() sequence diagram... sequence diagram-...

4.1 Add a student

:

Add form

Addition controller

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

Error message

: Database

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.2 Update Student Information

: Administrator

Update form

update controller

Errormessa ge

: 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()

4.3 Delete a student

:

Delete form

Administrator

Deletion

Error

controller

message

: Database

1: Request to enter reg no()

2: Enter reg no()

3: Validate reg no()

4: Refer from database()

5: Valid reg no student deleted()

6: Invalid reg no

7: Re-enter reg no or cancel()

5.Create Result/Report

: Administrator

main form

report form

report controller

error 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 Main 1: User enter mainform()

Form

2: Select to login()

4: User enters username and password() Local Form : Student

3: System request username and password()

8: Welcome message generate() 10: Error message-relogin or cancel() 5: Validate username and password() Login control

7: Valid username and password() 9: Invalid username and password()


: Database

2.Marks Entry

Welcome Form

Error Message

2: Enter operation(mark entry)

Main Form

3: Enter mark entry form()

6: Faculty enter marks()

Marks Entry Form

1: Request to specify opreration() 5: Request to enter marks() Faculty

4: Refer from Database() 7: Valid marks() 8: valid(store in database)

Entry Controller

10: Request to restart/cancel()

Error Message

9: Invalid marks()

: Database

3.Mark Analysis 2: Processing marks()

3: Enters into the form() Student Information

Main Form

Form

1: Request to enter the operation() : Mark analyser

4: Refer student information from database()

5: Calculation of total,Average() 8: Restart the operation() 6: Valid modified table into the database() 7: Invalid incorrect marks entry form Processing controller

Error message

: Database

4. Maintain Student Information 2: Allows the administrator to select an option() Selection Form 1: Request to select an option() : Administrator

3: Add option()

4: Update option() 5: Delete option() Session Controller

4.1.Add Student 3: Validate Details() 2: Enter details() Add form Addition controller 1: Request to enter name,dept,addr() : Administrator

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

Error message

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

: Database

4.2.Update Student

Update form

2: Administrator enter reg no()

3: Validate reg no

6: Update marks() 1: Request to enter reg no()

update controller

5: Request to update form() : Administrator

4: Validate system returns corresponding record()

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

Error message

: Database

4.3.Delete Student 2: Enter reg no()

3: Validate reg no() Delete form

Deletion controller

1: Request to enter reg no()

: Administrator


7: Re-enter reg no or cancel() 6: Invalid reg no 5: Valid reg no student deleted()

Error message

: Database

5.Create Result/Report

main form

2: Enter report type

3: Validate type

6: Enter the criteria report form

1: Request to enter report type 5: Request to enter the criteria : Administrator

4: Refer from database

8: Valid display report 7: Validate the criteria

11: Invalid type

12: Restart or cancel 9: Store to database report controller

10: Invalid criteria : Database

error message

STATECHART DIAGRAM 1.Login

/ Enter username and password Initialization Validate Details

[ Valid Details ] / Enter into Welcome Screen Open

[ Invalid details ] / Error message Error message

Cancelled

Cancelled Cancel

2.Mark Analysis

Displaying details

[ all record retrieved ] / process the marks

[ all records not retrieved ]

Processing marks

Processing marks

Lock

Updating the database

cancelled

ACTIVITY DIAGRAM

Cancel

cancelled

1.Updating the Database Administrator

System

Request to enter reg.no and details to be updated

Database

Details from database retrieval

Process the register no.

Updating the database Confirmation that details have been updated.

2.Adding a Student

Administrator

Request to enter the details of the student to be added.

System

Database

Process the details valid details

Generate register no. for the student

add the student to database Confirmation that student have been added

3. Deleting a Student

Administrator

Request to enter reg.no

System

Database

Process the register no. check reg.no

register no. available Confirmation that student have been deleted

Delete

Update database

CLASS DIAGRAM 1.Login Main form enter operation() Student

Error message Invalid marks() Display error message()

Login form name password

Welcome form Display to user() valid username and password()

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

Refer from database() Validate username and password()

Database

2.Marks Entry

Main form enter operation() Student

Marks Entry form

Error message

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

Validate marks()

Invalid marks() Display error message()

Database

3. Mark Analysis Main form enter operation() Mark analyser

Student Information flow retrieves information from database() refers student information from database()

Database

4. Create Student Report


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

Main form enter operation() Student Error message Invalid marks() Display error message()

Report Controller

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

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

Database

5.Maintain Student Information Selection form Allows the administrator to select an option() Administrator Selection controller add option() Update option() Delete option()

Add form(into database) Enter details()

1 1 1

Delete form(from database) Enter register number()

Update form(from database) Admin enters reg. no()

Controller validate respective operation()

Database


COMPONENT DIAGRAM

<>

Login

<> Maintain Student Information

<>

Marks Entry

<>

Mark Analysis

<>

Create

Result/Report

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

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 Sub

4) Student report: Option Explicit Public NewProperty As student Public NewProperty2 As student Public Sub enter_opreation() End Sub

Ex.No:3 Date:

ATM SYSTEM

1. Problem analysis and project planning 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.

1.4 Problem Statement 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.

2. Problem statement(Use case)analysis 2.1 Identified use cases 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.

2.2 Identified Actors 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.


customer

bank

ask login id() display error message()

login

transaction (withdrawal) maintain customer information

atm system

database

administrator

3. Design of ATM system 3.1 Design Documentation 1. Login 1.1 Brief description: 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.

1.2.2 Alternative flow:

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

1.4 Post conditions: User will perform corresponding transaction.

2. Transaction 2.1 Brief description: 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.

2.2.2 Alternative flow: 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 3.1 Brief description: 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.

3.2.2 Alternative flow: 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 3.2.1.2.1 Basic flow: 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.

3.2.1.2.2 Alternative flow: If the administrator has entered any wrong information then the system displays administrator error message.

3.2.1.3 Updating an existing Customer account 3.2.1.3.1 Basic flow: 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.

3.2.1.3.2 Alternative flow: If the administrator has entered any wrong information then the system displays administrator error message.

SEQUENCE DIAGRAM 1. Login:

: 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()

7: display error message()

2. Maintenance:

: administrator

main window

maintanance window

1: ask type of maintanence 2: provide information

3: add

4: delete sequence diagram 5: updete customer information sequence diagram

sequence diagram

3. Adding customer:

: administrator

add customer information

add customer

error message form

1: request customer information

2: provide customer information 3: verification 4: valid information

5: display error message 6: re-enter

: database

4. Deleting customer:

: administrator

maintenance window

delete

error message

customer

1: ask customer details

2: provide information 3: valid details 4: remove form database

5: invalid details

6: display error message

updete database

5. Updating customer:

: administrator

maintain window

update database

1: ask customer details

2: enter customer details 3: correct details

4: incorrect details


error message

6. Transaction:

: customer

transaction screen

update database

1: initiate transaction

2: provide information 3: correct

4: incorrect


COLLABORATION DIAGRAM:

error message

1. Login: main window

welcome screen

1: run atm()

5: successful() 3: provide login id()

4: verification() login window

login controller

2: ask login id() : customer 6: un successfull()

error message 7: display error message()

2. Maintenance: 2: provide information

1: ask type of maintanence : administrator

main window 3: add 4: delete 5: updete customer information

maintanance window

3. Adding customer:

error message form

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

5: display error message 1: request customer information 3: verification add customer information

add customer 4: valid information

: database

4. Deleting customer: 2: provide information maintenance window 1: ask customer details : administrator

3: valid details delete customer

4: remove form database 6: display error message

updete database

error message 5: invalid details

5. Updating customer:

2: enter customer details

maintain window

1: ask customer details : administrator

3: correct details 4: incorrect details

5: display error message update database

error message

6. Transaction: 3: correct

1: initiate transaction transaction screen 2: provide information : customer

4: incorrect

error message 5: display error message

update database

STATE CHART DIAGRAM

initilisation

event(add record)[fullfill bank req]/rec is added to the datab... event(delete record)[bank balance less than request]/ record is dele... add

delete

update

CLASS DIAGRAM 1.Login

customer ask login id() display error message()

main window

<< >> error message. login window welcome message

login contooller

2. Transaction:

customer

ask login id() display error message()

<< >> transaction screen initiate transaction() provide information() +1 +1...*

<< >> generate report

+1

+1

+0...*

+1

<< >>

<< >>

update database

error message.

COMPONENT DIAGRAM

<< >> login

<< >> transacti on

<< >> 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:4

COURSE REGISTRATION SYSTEM

Date:

1. Problem analysis and project planning 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.

1.4

Problem Statement

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 2.1 Identified use cases i Login ii Registration iii Course details

2.2 Identified Actors i Student ii Staff iii Database iv Database Administrator

2.3 Use Case Diagram course details

student

staff

database administrator

login

registration

database

3. Design of Course Registration System 3.1 Design Documentation 1. Login 1.1 Brief description: 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.

1.2.2 Alternative flow: 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.4 Post conditions: The use case was successful and the actor is now logged into the system. If not the system state is unchanged.

2. Registration 2.1 Brief description: 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.

2.2.2 Alternative flow: 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 3.1 Brief description: 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.

3.2.2 Alternative flow: 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.


: student Main window Login window

login control

welcome window

1: Logging

2: Asking for ID 3: verification 4: valid 5: invalid

6: error message

7: relogin cancel

2. Registration:

error message

registration from 1: registration()

from control

: student

error message

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:

: database

: student

course form

course form control

error message

1: select course() 2: validation() 3: Get course information()

4: display course information() 5: invalid()

6: display error message()

COLLABORATION DIAGRAM: 1.

Login:

: database

Main window

1: Logging

Login window : student

2: Asking for ID 7: relogin cancel

welcome window

3: verification

6: error message

4: valid login control

error message 5: invalid

2. Registration: 1: registration() 3: enters details() 11: re-registration() registratio n from : student

2: request for details()

9: display() 7: confirm message() 10: invalid()

4: validation()

5: verfy elective details(())

error message

from control 8: invalid elective details()

6: store details()

: database

3. Course details:

1: select course() course form : student 6: display error message()

2: validation() 4: display course information() course form control

error message

5: invalid()

3: Get course information() : database

STATE CHART DIAGRAM

initialize

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

open

student registered <20

cancel

close

CLASS DIAGRAM 1. Login <> main window +1

+1

+1 <> login window

+1 <> welcome window

<> error message

<> login control

2. Registration: <> error message

<>+1 control form

+1 <> registration form

+1

+0..*

3. Course details: <> error message

<> +1 course form control

+0..*

COMPONENT DIAGRAM

+1

<> course form control

+1

<> view courses details

<> login

<> security

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

<> registration

<> validation

Ex.No:5 Date:

EXPERT MEDICAL SYSTEM

1. Problem analysis and project planning 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.

1.4 Problem Statement 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.

2. Problem statement (Use case) analysis

2.1 Identified use cases 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.

2.2 Identified Actors 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

login

administrator

maintain information

view medicine

database

3. Design of Expert Medical System 3.1 Design Documentation 1. Login 1.1 Brief description: 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.2.2 Alternative flow: 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.4 Post conditions: The use case was successful and the actor is now logged into the system. If not the system state is unchanged.

2. View Medicines 2.1 Brief description: 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. 2.2.2 Alternative flow: 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 3.1 Brief description: 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 3.2.1.1.1 Basic flow: 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.

3.2.1.1.2 Alternative flow: 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 3.2.1.2.1 Basic flow: 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. 3.2.1.2.2 Alternative flow: 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 3.2.1.3.1 Basic flow: 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.

3.2.1.3.2 Alternative flow: 1. An error message occurs if an invalid field name is entered into the system. 2. The administrator re-enters the information or exists the system.

3.2.2 Alternative flow: 1. An error message occurs when the information given is not sufficient. 2. The administrator re-enters the information or exists the system.

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

: user

symptoms

symptom controller

Medicine List

1: Request for symptoms( ) 2: Enter the symptoms( )

3: Get the medical information( )

4: validate( ) 5: Valid( ) 6: Dispaly the medicine list( ) 7: Invalid( )

8: Dispaly error emssage( )

3.Administrator Domain Form

: administrator

admin domain controller

option contorller

1: request for selecting of operation( ) 2: selection of operation( ) 3: add an option( ) 4: delete an option( )

sequence diagram

5: update an option( )

sequence diagram

sequence diagram

error message

3.1 Adding of Information to the Database

: administrator

add form

add form controller

error 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( )

3.2 Deleting 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( )

3.3 Updating of Information from Database

: 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.3 Collaboration diagram 1.Login

1: enter user name & pwd( )

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

welcome screen

login controller

: user 7: re-invoke the form again( ) 2: get information from the database( ) 6: display the error message to the user( ) 5: invalid user name & pwd( ) error message : database

2.View of Medicines by the User 2: Enter the symptoms( ) symptoms

4: validate( ) symptom controller

1: Request for symptoms( ) : user 3: Get the medical information( ) 5: Valid( ) 8: Dispaly error emssage( ) 7: Invalid( ) 6: Dispaly the medicine list( ) error message

Medicine List

3.Administrator Domain Form 2: selection of operation( ) admin domain controller 1: request for selecting of operation( ) : administrator 3: add an option( ) 4: delete an option( ) 5: update an option( )

option contorller

3.1 Adding of Information to the Database 3: validating the given details( ) add form

5: invalid details( )

add form controller

4: getting information from the database( ) 1: request to give details( )

2: select the necessary details( )

: administrator

: database

error message


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

: database

1: request for details( ) 4: querries deleted from database( ) 2: enter the details( )

3: validation and confirmation( ) delete form

delete form controller

3.3 Updating of information from Database 2: give the details of updation( ) update form 1: request details for update( ) : administrator 5: send ack. of successful updation( ) 6: unsuccessful mission( )

3: validate( )

update form controller 4: querries and update the form( ) : database

3.4 Class Diagram 1.Login +1

<< >> main_form

+1 +1

user

+1

+1

+1

<< >> login_controller

+1

+1

+1

+1 << >> welcome_screen

<< >> log_on

<< >> error_message

2.Viewing Medicines by the User +1...*

+1...*

<< >> symptoms

+1

user

+* << >> medicine_list_

<< >> symptom_controller

3.Administrator Domain Form +1

+1

<< >> admin_domain_controller +1

administrator

+1..* << >> option_controller


<< >> add_form administrator

+1..* << >> error_msg

+1

+1

+1 << >> add_form_controller

database


<< >> delete_form

administrator

+1

database

+1 << >> delete_from_controller

3.3 Updation of Information from Database

<< >> update_form

administrator

+1

+1 << >> update_controller

database

3.5 State Chart Diagram 1.Login

get the user input

get the information from the database

check:invalid

error message

check:valid

welcome screen

reinvoke the login form again

2.Viewing of Medicines

get the symptoms list from the user

validate the input

check:valid input

gives the medicines from medicine list

refer to the database

check

check:invalid input

display error message

3.Administrator Domain Form

get theselected operations

add operation

add domain form

delete operation

delete domain form

update form

update domain form


get the input details


check for the correct input

check:valid

add details to the database

chech:invalid

show error message


get the input details

check for the correct input


chech:valid delete the details from database

check:invalid show error message

3.6 Component Diagram

<< >> login

<< >> security

<< >> maintainini information for doctors

<< >> view medicine

<< >> maintaining information for the medicine

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_

3.Administrator Domain Form 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:6

REMOTE COMPUTER MONITORING SYSTEM

Date:

1. Problem analysis and project planning 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.

1.4 Problem Statement 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.

2. Problem statement(Use case)analysis 2.1 Identified use cases i Login ii Students work with lab exercise iii Monitor students iv Maintain client information

2.2 Identified Actors i Student ii Professor/HOD iii Administrator iv ManagementDatabase1(current working environment) v Database2(student details) vi Login Controller


Students

work with lab exercise

Database1

Login

Professor/HOD

Administrator

monitor students

Database2 Management

add/remove clients

monitor professor/HOD

3. Design of Students Mark analyzing System 3.1 Design Documentation 1. Login 1.1 Brief description: 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.2.2 Alternative flow: 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.4 Post conditions: 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

2.1 Brief description: 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.

2.2.2 Alternative flow: If user opens those applications which he is not permitted to error message is displayed.


2.4 Post Condition: None

3. Monitoring Students 3.1 Brief description: 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.

3.2.2 Alternative flow: 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 4.1 Brief description: 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 4.2.1.1.1 Basic flow: 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.

4.2.1.1.2 Alternative flow: 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 4.2.1.2.1 Basic flow: 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.

4.2.1.2.2 Alternative flow: 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 4.2.1.3.1 Basic flow: 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.

4.2.1.3.2 Alternative flow: 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.3 Pre Condition: Login

4.4 Post Condition: Report Generation.


: Professor/HOD

Main form

Login form

Login Controller

Error 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( )

Welcome message

2. Students working with lab exercise

: Students

Lab exercise

: Database1

Work with lab exercise( )

record the current workspace( )

3. Monitor Students

: Professor/HOD

Selector form

Domain controller

: Database1

: Database2

login( ) Request for student details( ) Get details about current working( )

Details already stored in the file( )

Compares( )

Valid(generates report)

Invalid(operation mismatch)

Report

4. Maintain client information

: Administrator

Selection form

Selection controller

Report

Request for selection( )

Select an operation(add/delete/update)

add option( )

delete option( )

Sequence diagram...

Sequence diagram-... Update option( ) Sequence diagram...

4.1 Add

: Administrator

Entry form

Entry controller

Error message

: Database1

Request admin to enter client details( )

admin enter details( )

Verification( )

Valid(sys generates new id &adds client)

invalid(details missing)

Display error message( )

Re-enter/cancel( )

4.2 Delete

: Administrator

Entry form

Entry controller

Error 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

: Administrator

Entry form

Entry controller

Error 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( )

COLLOBORATION DIAGRAM 1. Login Main form

1: login( ) 9: re-entry /cancel( ) 3: Enter username and password( ) Login form 2: Request for username and password( ) : Professor/HOD 8: Display an error message( ) Error message 6: Dispalay welcome message( )

4: Verification( )

7: Invalid entry( ) Welcome message

Login Controller 5: Valid entry( )

2. Students working with lab exercise 1: Work with lab exercise( )

2: record the current workspace( ) Lab exercise

: Students

3. Monitor Students

: Database1

5: Compares( )

3: Get details about current working( ) Domain controller 1: login( ) 7: Invalid(operation mismatch) : Professor/HOD : Database1

Selector form

2: Request for student details( )

6: Valid(generates report)

4: Details already stored in the file( ) Report : Database2

4. Maintain client Information 2: Select an operation(add/delete/update) Selection

form 1: Request for selection( )

: Administrator

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


Report

4.1 Add 2: admin enter details( ) 7: Re-enter/cancel( ) Entry form 1: Request admin to enter client details( ) : Administrator

6: Display error message( )

3: Verification( )

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

Entry controller 5: invalid(details missing)

4.2 Delete

: Database1

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

3: verification( )() Entry form

Entry controller

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

6: Display error message( )

4: valid(id available,client deleted) 5: invalid(id not available)

Error message

: Database1

4.3 Update 2: admin enters id( ) 7: re-enter/cancel( )

3: Verification( ) Entry form

Entry controller

: Administrator 1: Request admin to enter client details to be updated( ) 6: Displays an error message( )

4: valid(sys displays the rec for admin to update) 5: invalid(id not exist)

Error message : Database1

STATECHART DIAGRAM

stud current page=lab... trans_monitor( stud current ex )[ stud current ex=lab e... Server monitor students

stud current page<>lab...

stud current ex=lab ex

Cancel

CLASS DIAGRAM 1. Login

Lock

user Main form

name password

display() enter name and password()

Error message display()

Welcome form validate()

Login form get()

Login Controller validate()

2. Students working with lab exercise Lab exercise programs

Students

execute programs() opname()

Database1 current working details record current details()

3. Monitor Students

selection form login() Database2 details of student monitoring details maintenance() Professor/HOD

Domain controller refers() validate()

report print()

Database1 current working details record current details()

4. Maintain client information

administrator


report print()

validate()

Selection form login()

delete form update form

add form

entry controller validate()

4.1 Add

error message display()

entry form details to be updated get() Administrator error message display()

entry controller validate() Database1 current working details record current details()

4.2 Delete Entry form details to be updated get() Administrator Error message

entry controller

display()

validate() Database1 current working details record current details()

4.3 Update entry form details to be updated get() Administrator Error message display()

entry controller validate() Database1 current working details record current details()

COMPONENT DIAGRAM

Login

Monitor Students

Maintain client information

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()

Students working with lab exercise

End Sub

3.Monitor Students Option Explicit Public Sub login() End Sub

4.Maintain client information Option Explicit Public NewProperty As report Public Sub validate() End Sub

4.1Add Option Explicit Private details_to_be_updated As Variant Public Sub get() End Sub

4.2Delete Option Explicit Public Sub validate() End Sub

4.3Update Option Explicit Public NewProperty As Main_form Public Sub display() End Sub

Ex.No:7

QUIZ SYSTEM

Date:

1. Problem analysis and project planning 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.

1.4 Problem Statement 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.

2. Problem statement (Use case) analysis 2.1 Identified use cases 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.

2.2 Identified Actors 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.


Enter exam

Time out

Student View results Database

Login

Administrator

professor/HOD

Maintain questions and answers

Reporting

Printers

Maintain staff and student information

3. Design of Quiz System 3.1 Design Documentation 1. Login 1.1 Brief description: 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.2.2 Alternative flow: 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.4 Post conditions: The use case was successful and the actor is now logged into the system.

2. Enter Exam 2.1 Brief description:

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.

2.2.2 Alternative flow: 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 3.1 Brief description: 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.

3.2.2 Alternative flow:

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 4.1 Brief description: 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.

4.2.2 Alternative flow: 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 5.1 Brief description: 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.

5.2.2 Alternative flow: 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 6.1 Brief description: 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.


6.3 Pre condition: The question answered by the students.

6.4 Post condition: Reports are being stored into the database.


: Student

Main form

Login form

Login controller

Welcome screen

1: Login()

2: Enter id and password()

3: Verification()

4: Valid()

5: Invalid()

6: Error message()

7: Relogin()

Error message

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

: Student

: professor/HOD

options form

Individual performance

Overall performance

: Database

1: to see his results( ) 2: Options( )

3: to avail options( ) 4: to see a particular record( ) 5: individual record( ) 6: to see overall performance( ) 7: Overall performance( )

4.Maintain Question & Answers

: professor/HOD

options form

Question & answer form

1: to avail options( ) 2: add( )

3: modify( )

add Q&A sequen...

4: delete( )

modify Q&A sequen...

delete Q&A sequen...

4.1Add Question & Answer

: professor/HOD

add question form

add question controller

error message

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.2 Modify Question & Answer

: Database

: professor/HOD

add question form


error message

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

: Database

: professor/HOD

deletion form

deletion controller

error message

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.Maintain User Details

: Database

: Administrator

options form

User profile form

1: to avail options( ) 2: add user( )

3: modify user( )

add user sequen...

4: delete user( )

modify user sequen...

delete user sequen...

5.1 Add User

: Administrator

new user add form

add user controller

error message

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.2 Modify User Details

: Database

user selector : Administrator form

modification form

modification error message controller

: 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( )

5.3 Delete User

: Administrator

user selection form

deletion form

: Database

1: selecting user( ) 2: retrieving datas( )

3: Deleting( )

4: Updating( )

6.Reporting

Reporting controller

: Database

TRIGGER DUE TO DATABASE CHANGES 1: intimation( )

2: UPDATE( )

COLLOBORATION DIAGRAM 1.Login

Main form

1: Login()

2: Enter id and password() 7: Relogin() Login form : Student 3: Verification() 6: Error message()

Login controller 4: Valid()

5: Invalid() Error message Welcome screen

2.Enter Exam 2: to avail options( )

options form 1: Enter the quiz ( )

Quizzing form

: Student 7: Answer the questions( ) 3: Options taken( ) Questionin g form 6: time maintainance( ) 8: Stored( )

4: start time( )

9: time out( )

5: Getting questions( )

: Database

3.View Results

: Time out

3: to avail options( ) options form : Student

: professor/HOD

1: to see his results( ) 4: to see a particular record( ) 6: to see overall performance( ) Individual performance

2: Options( ) 5: individual record( )

: Database

7: Overall performance( )

Overall performance

4.Maintain Question & Answers 2: add( ) 3: modify( ) 4: delete( )

1: to avail options( )

Question & answer form

options form : professor/HOD

4.1 Add Question & Answer 2: add new questions( ) 7: retype question( )

3: Validate( )

add question form


1: request for new Q&A( ) : professor/HOD 4: valid[filled properly] 6: Error message( ) 5: Invalid[not filled properly] error message

4.2 Modify Question & Answer

: Database

5: modify( )

modify question form

2: select question( ) 10: reentry( ) : professor/HOD

4: retrieve( )

1: requesting question to be selected( ) Question selection form

9: Error message( )

6: Verification( )

3: intimate to database( ) 7: Valid modify question controller

error message 8: Invalid( )

: Database

4.3 Delete Question & Answer 2: select Q&A ( ) 9: re-entry( ) deletion form

3: Intimate to database( )

1: Request question to be deleted( ) : professor/HOD 5: Verification( )

8: Error message( )

4: retrieving Q&A( ) 6: Valid( ) : Database

deletion controller

error message 7: Invalid( )

5.Maintain User Details 1: to avail options( ) options form : Administrator

5.1 Add User

2: add user( ) 3: modify user( ) 4: delete user( ) User profile form

3: Verification( )

2: adding new user( ) new user add form 1: request for new user( ) : Administrator

add user controller 4: not filled properly( ) 6: filled properly( )

5: Error message ( ) 7: Generating ID( )

error message

: Database

5.2 Modify User Details 6: Verification( )

5: modifying ( ) modificatio n form

modification controller

: Administrator 1: Request to select user( ) 7: Improper modification( ) 2: select user( ) 4: retrieve database( ) 8: Error message( )

3: intimate to database( ) user selector form

error message 9: Storing to database( ) : Database

5.3 Delete User 1: selecting user( ) user selection form : Administrator 3: Deleting( )

2: retrieving datas( )

4: Updating( ) deletion form : Database

6.Reporting

1: intimation( ) Reporting controller 2: UPDATE( ) : Database

STATE CHART DIAGRAM 1.Delete User deleting again

admin enter into delete user form

enter the details

delete controller if correct

if wrong re-enter the details

user is deleted

cancel

2.Update User

main form for updation

details of user

return to main form

Updating the controller

if wrong

Insufficient detail

if correct

database updation

CLASS DIAGRAM 1.Login +1

<> +1 Main form

+1 +1

login()

<> Error message

+1

+1

Incorrect()

<> Login form ID and password() Re-login()

+1

+1 +1

<> Login Controller Verification()

+1 <> Welcome screen Correct()

+1 +1

2.Enter Exam

+1 +NewProperty

+1

<> Options_form

<> Questioning_form

Available_options() to_avail_options()

+NewProperty

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

<> Quizzing_form Enter the quiz()

3.View Results <> Individual_performance To see his results() Individual records() To see a particular record() +NewProperty +1 <> Options_form

<> Overall_performance +1

+NewProperty

Available_options() to_avail_options()

4.Maintain Question & Answers

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

<> Options_form

+1

Available_options() to_avail_options() +1 +1

+NewProperty <> Add_Questions_form Add new question() retype question() +1

+NewProperty

+NewProperty

<> Modify_Questions_form

<> Deletion_form Selecting Q&A() Retrieving Q&A() Re-enter() +1 +1

+1 +1 <> Controller +1 +1 <> Error message Incorrect()

+1

Retrieve() Modify()

5.Maintain User Profile

<> Options_form Available_options() to_avail_options()

+1

+1

+1

+NewProperty <> New_user_add_form

+NewProperty <> Modification_form

Adding new user()

Modifying() Retrieve data() Error message()

+1 +1

+1

+1

+1 <> Controller

+1 +1 <> Error message Incorrect()

+NewProperty <> Delete_form Deleting() +1

COMPONENT DIAGRAM

<> Exam <> Security

<> Question and answer

<> Login

<> Profiles

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() 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 NewProperty As options_form 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 NewProperty As options_form 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:8

ONLINE RESERVATION SYSTEM

Date:

1. Problem analysis and project planning 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.

1.4 Problem Statement 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.

2. Problem statement (Use case) analysis 2.1 Identified use cases 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

Booking Tickets

Database Payment mode Bank System

Login

Clerk

Cancellation

Report

3. Design of Expert Medical System

3.1 Design Documentation 1. View status 1.1 Brief description: 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.2.2 Alternative flow: 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.4 Post conditions: If the use case is successful the actor books the tickets in the desired airline.

2. Book Ticket 2.1 Brief description: 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 3.1

Brief description:

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.

3.2.2 Alternative flow: If the bank details are incorrect an error message is given to the passenger.


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. 5.2.3 Alternative flow: 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 6.1 Brief description: 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. 6.2.2 Alternative flow: None

6.3 Pre Conditions: None

6.4 Post Conditions: A report is generated.

SEQUENCE DIAGRAM 1.View Status

: Passenger

Enter details:data db controller Display EnquiryError message entry form form 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]

2.Booking Tickets

: Passenger

data entry form db controller display form

error form

1: request( )

2: enter details( )

3: validate( )

4: valid( )

5: confirmation( ) 6: update( )

7: invalid( )

8: error message( )

3.Payment mode

: Database

: Passenger

data entry form

db controller

mode selection

error message : Bank System: Database form

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( )

4.Login

: Clerk

Login form

Main form

Login controller

Welcome form

1: Login( )

2: request to enter details( ) 3: enter details( ) 4: validate( )

5: valid( )

6: display( ) 7: invalid( )

8: error message( )

5.Cancellation

Error message

: Passenger

data entry form

db controller error message form

: Clerk

: Database

1: request to enter details( ) 2: enter details( ) 3: validate( ) 4: valid ( ) 5: update( ) 6: refund ( ) 7: invalid( ) 8: error message ( )

6.Report : Clerk

data entry form

db controller

error message

1: request to enter details( ) 2: enter details( ) 3: validate( ) 4: update( )

5: output( ) 6: invalid( )

7: error message( )

COLLABORATION DIAGRAM 1.View Status

: Database

2: Enter details( )[enter above details] Enter details:data entry form 1: request( )[date time destination] : Passenger 6: display seat and airline status info( ) Display Enquiry 4: validate( )[check entered details] 8: error message( )[re-enter data] form

5: valid( ) db controller

Error message form

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

2.Booking Tickets 3: validate( )

2: enter details( ) data entry form

db controller

1: request( ) : Passenger

5: confirmation( )

7: invalid( ) 8: error message( ) error form

4: valid( ) display form

6: update( )

: Database

3.Payment mode

4: validation

3: validate( )

2: enter details( ) data entry form

db controller

1: request( ) : Passenger

5: reference

12: error message( )

11: invalid( ) error message form

7: enter mode( )

: Database

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

9: update( ) 8: credit card( ) mode selection : Bank System

4.Login 1: Login( )

Login form 3: enter details( ) Main form

2: request to enter details( ) : Clerk

4: validate( )

8: error message( )

Login controller 6: display( )

Error message

7: invalid( )

5: valid( )

Welcome form

5.Cancellation

2: enter details( )

3: validate( ) data entry form

db controller

1: request to enter details( ) : Passenger 7: invalid( )

8: error message ( )

4: valid ( )

6: refund ( ) error message

form 5: update( ) : Database

6.Report error message 7: error message( )

6: invalid( )

2: enter details( )

data entry form

1: request to enter details( ) : Clerk 3: validate( ) 5: output( ) db controller 4: update( ) : Database

CLASS DIAGRAM 1.View status

: Clerk

`

Passenger

<> data entry form enter details()

+1 +1 <> Display form confirmed()

Database

<> Db controller refer to database() Validate()

<> Error message form invalid()

2.Booking Tickets

Passenger


Database


+1

+1 <> display form confirmed()

3.Payment Mode


Passenger

<> mode selection

+1

valid() enter mode()

<> +1 data entry form enter details()


<> Error message form invalid() Bank System

4.Login <> main form Clerk

<> Login form enter() reenter/cancel()

<> Login controller Validate()

5.Cancellation

login()

<> Welcome form Validate()


<> Login information name password ID get()

Passenger

<> Display form confirmed()

Database


Clerk


6.Report

Clerk




ACTIVITY DIAGRAM

Database

Enter details

look up

Airline details

airline specification Select Airline airline selected Enter passenger list

check availability

Check availability

status availability record locked

Locked

Mode of payment

invalid

select mode Enter bank details cash available

credit card

account details

paid paid

Deliver ticket

COMPONENT DIAGRAM

Validate

valid

Update Database

<> Payment mode

<> Booking tickets

<> Login

<> Cancellation

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

<> Report

<> View status

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

REMOTE PROCEDURE CALL (RPC)

Date: 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 RAM Hard Disk Monitor Keyboard Mouse

: Intel Pentium @ 3.06GHz : 512MB DDR : 80GB SATA : 15’’TFT : Multimedia Keyboard : 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 runtime 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. Client 2. 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 1. Establish a listening socket and wait for connections from clients.

Client

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

Send File

Receive File Server

Client

Client Bank





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. Client 2. Server 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. 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.

COLLABORATION DIAGRAM:

System Admin

Close

2: Edit File on Client Part

4: Close the System 3: Connection from Client to Server

Server

Client 1: Call the 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

Client

System Admin

Close

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. Client 2. Server 3. System Admin 4. Close 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. 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 #include #include int main { try { //

"ServerSocket.h" "SocketException.h" ( int argc, int argv[] )

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 Server Creating a client socket ( part of client main.cpp) #include "ClientSocket.h" #include "SocketException.h" #include #include 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 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 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 #include #include #include

"ClientSocket.h" "SocketException.h"

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_created prompt$ 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:

OUTPUT

first prompt: prompt$ ./simple_server running....

second prompt: prompt$ ./simple_client We 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 Date:

STOCK MAINTENANCE SYSTEM

1. Problem analysis and project planning 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.

1.4 Problem Statement 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.

2. Problem statement (Use case) analysis 2.1 Identified use cases 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.

2.2 Identified Actors 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:

Employee

Maintain books

Manager

Login

Database

Purchase order

Administrator

View report

View stock

3. Design of Stock Maintenance System 3.1 Design Documentation 1. Login 1.1 Brief description:

Customer

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.2.2 Alternative flow: 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 2.1 Brief description: 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 subflow 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. 2.2.2 Alternative flow: 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 3.1 Brief description: 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. 3.2.2 Alternative flow:

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 4.1 Brief description: 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. 4.2.2 Alternative flow: 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.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 5.1 Brief description: 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. 5.2.2 Alternative flow:

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

: Administrator

main form

error message

controller

request ID( ) Enter ID( )

Verification( )

Valid( )

Generate report( )

Invalid( )

Displays error message( )

re-enter ID( )

3. View Stock

: Database

: Customer

Controller

: Administrator

Error message

request book details( ) Enter book details( ) Verify( ) Verified( )

Generate report( ) not filled properly( ) error message( )

4. Maintain Stock

: Employee

option form

book profile form

to avail options( ) add books( ) Sequence diagram... update books( )

delete books( )

Sequence diagram...

Sequence diagram-...

4.1 Add

: Database

: Employee

Selection

form

modification

Error message

form

: Database

Request for new books( ) add new books( ) Verification( ) filled properly( ) Generate ID( ) Not filled properly( ) Error message( )

4.2 Modify

Selection form Request to select books( )

: Employee

Modification form

Modification controller

Error message

Selecting books( ) intimate database( ) Retrieve datas( ) modify( ) Verification( ) improper modification( ) Displays error message( )

4.3 Delete

: Database

: Manager

Selection form

Deletion form

: Database

Select order( ) retrieving datas( ) Deleting( ) update( )

5. Purchase Orders

: Manager

option form

order profile

form

avail options( ) create orders( )

change orders( )


Sequence diagram... delete orders( )


5.1 Create Order

create order form Request for new order( )

: Manager

controller

Error message

: Database

Create new order( ) Verification( ) filled properly( )

Generate ID( ) not filled properly( )

Error message ( )

5.2 Change Orders

: Manager

order selection form

modification form

modification controller

Error Message

Request to select order( ) Selecting order( ) intimate database( ) retrieve datas () modifying( ) Verification ( ) Improper modification ( ) Error message( )

5.3 Delete Orders

: Database

Selection form

: Manager

Deletion form

: Database

Selecting order( ) retrieving datas( )

Deleting( )

Update ( )

COLLABORATION DIAGRAM: 1. Login Main

form

1: login( ) 8: re-login( )

2: Enter username and password( ) Login form

: Customer 3: Verification( )

7: Displays error message( )

5: Valid( ) Login controller

Error message

Welcome screen

6: Invalid( ) 4: Retrieve from database( )

: Database

2. View Reports

2: Enter ID( ) 8: re-enter ID( )

3: Verification( ) main form

controller

1: request ID( ) : Administrator

5: Generate report( ) 7: Displays error message( )

4: Valid( )

: Database error message 6: Invalid( )

3. View Stock Error message 2: Enter book details( )

7: error message( )

: Customer

1: request book details( )

5: Generate report( )

6: not filled properly( ) 3: Verify( )

: Administrator Controll

er 4: Verified( ) : Database

4. Maintain Stock

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

1: to avail options( ) option

book profile

form

form

: Employee

4.1 Add 2: add new books( ) Selection form 1: Request for new books( ) : Employee 5: Generate ID( )

3: Verification( )

7: Error message( ) : Database 4: filled properly( )

Error message

modificatio n form

6: Not filled properly( )

4.2 Modify 3: intimate database( ) Selection form 1: Request to select books( )

: Database 4: Retrieve datas( )

2: Selecting books( )

5: modify( ) Modification form

: Employee 8: Displays error message( )

6: Verification( )

Error message

Modification controller 7: improper modification( )

4.3 Delete

1: Select the book( ) Selection form : Manager 2: retrieving datas( )

3: Deleting( )

4: update( ) Deletion form : Database

5. Purchasing Orders 2: create orders( ) 3: change orders( ) 4: delete orders( )

1: avail options( ) option form

order profile form

: Manager

5.1 Create Orders 2: Create new order( ) create order

form

: Manager

1: Request for new order( )

5: Generate ID( ) 7: Error message ( )

3: Verification( ) : Database

Error message

4: filled properly( )

er

6: not filled properly( )

5.2 Change Orders

controll

3: intimate database( ) order selection form : Database 1: Request to select order( )

4: retrieve datas ()

2: Selecting order( )

5: modifying( ) modification form

: Manager 6: Verification ( )

8: Error message( )

error message

modification controller 7: Improper modification ( )

5.3 Delete Orders 1: Selecting order( ) Selection

form

: Manager 2: retrieving datas( )

3: Deleting( )

4: Update ( ) Deletion form : Database

CLASS DIAGRAM: 1. Login

Main form

+1

login ()

+1

Error Message

Login Controller

incorrect()

+1

correct()

verification()

enter()

Login form username()

password() re-login()

2. Maintain Books

Update books

Add books book information edition()

enter id()

author name()

change() update()

publication()

Delete books retrieve details confirm()

verify() delete specified()

3. Purchase Orders

+1

Welcome screen

Create purchase orders

assign order name of the book()

quantities() edition() Delete purchase

Change purchase order

order request() confirm()

Identify ID() desired changes()

deletion() displays()

updates()

4. View stock & Report

view stock verification()

book details

report

books available

administrator report

book required()

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

book specification() displays()

3.5 Component diagram

maintain

view reports

books

Login

purchase

orders

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

view stock

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 Orders Option 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

Ooad Lab Final Manual1

Recommend Documents