Professional Documents
Culture Documents
UNDER THE GUIDANCE OF DR. M ROBERTS MASILLAMANI DEAN (CS) SCHOOL OF COMPUTING SCIENCES
IT1333
L 0
T 0
P 3
C 1
TCH 3
Ex.No:1 Date:
Study Of UML
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.
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
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.
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.
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:
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.
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.
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.
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.
faculty
login
database
mark analysis
mark analyser
student
result report
Placement officer
view reports
If the use case was successful, the actor is now logged into the system, if not, the system status unchanged.
2.2
Flow of events:
2.2.2
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.
This use case describes how the system generates overall results by analyzing the marks, Marks Analyzer monitors this process.
3.2
Flow of events:
If in basic flow, the information about student marks could not be located, the system displays error message and use case ends.
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.
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.
database.
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.
System provides the report satisfying the report criteria. 10.The user may require saving the report.
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.
: Student
Login control
Welcome Form
Error Message
: Database
2: Select to login()
2. Marks Entry
Faculty
Main Form
Entry Controller
Error Message
: Database
7: Valid marks()
8: valid(store in database)
9: Invalid marks()
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()
: 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-...
Add form
Addition controller
Error message
: Database
3: Validate Details() 4: Valid generates a new reg no and add it to the database()
: 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()
:
Administrator
Delete form
Deletion controller
Error message
: Database
6: Invalid reg no
5.Create Result/Report
: Administrator
main form
report form
report controller
error message
: Database
3: Validate type
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()
Error Message
Welcome Form
: Database
2.Marks Entry
Main Form
6: Faculty enter marks() 1: Request to specify opreration() 5: Request to enter marks() Faculty
Entry Controller
9: Invalid marks()
Error Message
: Database
3.Mark Analysis
2: Processing marks() Main Form 3: Enters into the form() Student Information 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
3: Add option()
4.1.Add Student
3: Validate Details() 2: Enter details() Add form Addition controller 1: Request to enter name,dept,addr() : Administrator
Error message
: Database
4.2.Update Student
Update form
3: Validate reg no
6: Update marks() 1: Request to enter reg no() 5: Request to update form() : Administrator
update controller
Error message
: Database
4.3.Delete Student
2: Enter reg no() 3: Validate reg no() Delete form Deletion controller
: Administrator
7: Re-enter reg no or cancel() 6: Invalid reg no
Error message
: Database
5.Create Result/Report
main form
8: Valid display report 7: Validate the criteria 12: Restart or cancel 9: Store to database report controller
error message
Cancelled Cancel
Cancelled
2.Mark Analysis
Displaying details
Processing marks
Processing marks
Lock
cancelled
Cancel
cancelled
ACTIVITY DIAGRAM
2.Adding a Student
Administrator
System
Database
add the student to database Confirmation that student have been added
3. Deleting a Student
Administrator
System
Database
Delete
Update database
Database
2.Marks Entry
Marks Entry form Entry Controller display mark entry form() faculty enters marks() Refer from database() Validate marks()
Database
3. Mark Analysis
Main form enter operation() Mark analyser Error message Invalid marks() Display error message()
Student Information flow retrieves information from database() refers student information from database()
Database
Main form enter operation() Student Error message Invalid marks() Display error message()
Report form Request the user to enter the criterias() validates() validate type() retrieves information from database()
Report Controller Validate the criteria() Ask whether to save or not() selects to save() selects not to save()
Database
COMPONENT DIAGRAM
<<ActiveX DLL>>
Login
Marks Entry
<<ActiveX DLL>>
Mark Analysis
<<ActiveX DLL>>
Create
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.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 customers 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 customers information is stored.
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.
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.
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.
bank
login
atm system
database
administrator
1. If the user enters the wrong name and the PIN then the system displays an error message. 2. The actor can either return to the basic flow or cancel login at which point use case ends.
: customer
login controller
welcome screen
error message
1: run atm()
6: un successfull()
2. Maintenance:
: administrator
main window
maintanance window
3: add
sequence diagram
3. Adding customer:
: administrator
add customer
: database
4. Deleting customer:
maintenance window delete error message updete database
: administrator
customer
5: invalid details
5. Updating customer:
maintain window update database error message
: administrator
4: incorrect details
6. Transaction:
transaction screen update database error message
: customer
1: initiate transaction
4: incorrect
COLLABORATION DIAGRAM:
1. Login:
main window welcome screen
1: run atm() 3: provide login id() login window 2: ask login id() : customer
6: un successfull()
2. Maintenance:
2: provide information main window 3: add 4: delete 5: updete customer information
maintanance window
3. Adding customer:
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
updete database
5. Updating customer:
maintain window
error message
6. Transaction:
1: initiate transaction transaction screen 2: provide information : customer 3: correct update database
4: incorrect
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
main window
login contooller
2. Transaction:
customer
<< >>
transaction screen initiate transaction() provide information() +1 +1...* +1 +1
+1
+0...*
<< >>
generate report
<< >>
update database
<< >>
error message.
COMPONENT DIAGRAM
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 Date:
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.
staff
database administrator
login
registration
database
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.
login control
welcome window
error message
6: error message
7: relogin cancel
2. Registration:
: student
from control
error message
: database
2: request for details() 3: enters details() 4: validation() 5: verfy elective details(()) 6: store details()
2.
Course details:
: student
course form
error message
: database
COLLABORATION DIAGRAM:
1. Login:
1: Logging
: student
3: verification
2. Registration:
1: registration() 3: enters details() 11: re-registration() registratio n from : student 9: display() 7: confirm message() 10: invalid() error message 8: invalid elective details() 2: request for details() 4: validation()
from control
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 5: invalid()
error message
initialize
open
close
cancel
CLASS DIAGRAM
1. Login
<<Class Module>> main window +1 +1 <<Class Module>> login window
2. Registration:
<<Class Module>> error message <<Class Module>> +1 control form +1 <<Class Module>> registration form
+1
+0..*
3. Course details:
<<Class Module>> error message <<Class Module>> +1 course form control +1 <<Class Module>> course form control
+0..*
+1
COMPONENT DIAGRAM
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
Ex.No:5 Date:
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.
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.
This use case is accessible only to the administrator that allows him to add, update and delete the required information directly form the database.
user
login
administrator
doctor
maintain information
pharmist
view medicine
database
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.
: 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( )
: user
1: Request for symptoms( ) 2: Enter the symptoms( ) 3: Get the medical information( )
: administrator
1: request for selecting of operation( ) 2: selection of operation( ) 3: add an option( ) 4: delete an option( ) sequence diagram sequence diagram
5: update an option( )
sequence diagram
: administrator
add form
error message
: database
2: select the necessary details( ) 3: validating the given details( ) 4: getting information from the database( )
5: invalid details( )
: administrator
delete form
: database
1: request for details( ) 2: enter the details( ) 3: validation and confirmation( ) 4: querries deleted from database( )
: administrator
update form
: database
option contorller
: administrator
: database
5: [valid]send ack. about deletion( ) : administrator 6: [invalid]unsuccessful mission( ) 1: request for details( )
: database
user
+1
administrator
database
administrator
database
administrator
database
check:invalid check:valid
error message
welcome screen
2.Viewing of Medicines
check:valid input
check
check:invalid input
add operation
delete operation
update form
check:valid
chech:invalid
CLASS CODE:
1.Login
Option Explicit Public NewProperty As login_controller
Ex.No:6 Date:
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.
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.
Students
Database1
Login
Professor/HOD
Administrator
monitor students
monitor professor/HOD
2. System gets details from database2. 3. Compares it with already stored details in database1. 4. Quits.
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.
: Professor/HOD
login( )
Verification( )
Valid entry( )
Invalid entry( )
re-entry /cancel( )
: Students
Lab exercise
: Database1
3. Monitor Students
: Professor/HOD
Selector form
Domain controller
: Database1
: Database2
Report
login( ) Request for student details( ) Get details about current working( )
Compares( )
Valid(generates report)
Invalid(operation mismatch)
: Administrator
Selection form
Selection controller
Report
Select an operation(add/delete/update)
delete option( )
4.1 Add
: Administrator
Entry form
Entry controller
Error message
: Database1
Verification( )
invalid(details missing)
Re-enter/cancel( )
4.2 Delete
: Administrator
Entry form
Entry controller
Error message
: Database1
verification( )()
re-enter /cancel( )
4.3 Update
: Administrator
Entry form
Entry controller
Error message
: Database1
Verification( )
re-enter/cancel( )
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( )
3. Monitor Students
5: Compares( )
Selector form
3: Get details about current working( ) Domain controller 1: login( ) 7: Invalid(operation mismatch) : Professor/HOD : Database1 6: Valid(generates report)
Report : Database2
form
1: Request for selection( )
: Administrator
Selection controller
Report
4.1 Add
2: admin enter details( ) 7: Re-enter/cancel( ) Entry form 1: Request admin to enter client details( ) : Administrator
3: Verification( )
4: Valid(sys generates new id &adds client) Error message 5: invalid(details missing) Entry controller : Database1
4.2 Delete
Error message
: Database1
4.3 Update
2: admin enters id( ) 7: re-enter/cancel( ) Entry form : 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)
STATECHART DIAGRAM
stud current page=lab... trans_monitor( stud current ex )[ stud current ex=lab e... Server monitor students
Lock
Cancel
user name password enter name and password() Main form display()
Students
3. Monitor Students
selection form login() Database2 details of student monitoring details maintenance() Professor/HOD
report print()
administrator
report print()
4.1 Add
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 display() entry controller 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
CLASS CODE:
1.Login
Option Explicit Private name As Variant Private password As Variant Public Sub enter_name_and_password() End Sub
End Sub
3.Monitor Students
Option Explicit Public Sub login() 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 Date:
QUIZ SYSTEM
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.
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.
v Reporting:
This use case describes how the results are taken from questioning session.
iii Administrator:
The Administrator is the only user who has access to the user profile database. He also has the rights to make changes if necessary.
iv Database:
This actor stores the entire contents of the quizzing system including databases such as report, questions and user profiles.
v Printer:
This actor prints the report database.
vi Timer:
This actor maintains the time during the quizzing the quizzing session and intimates the database to change the questions when the time elapses.
Time out
Database
Login
professor/HOD
Administrator
Reporting
Printers
The use case describes how a student enters into questioning part of quizzing system.
: Student
Main form
Login form
Login controller
Welcome screen
Error message
1: Login()
3: Verification()
4: Valid()
5: Invalid()
6: Error message()
7: Relogin()
2.Enter Exam
: Student
options form
Quizzing form
Questioning form
: Database
: Time out
2: to avail options( )
3: Options taken( )
4: start time( )
5: Getting questions( )
3.View Results
: Student
: professor/HOD
options form
Individual performance
Overall performance
: Database
3: to avail options( )
4: to see a particular record( ) 5: individual record( ) 6: to see overall performance( ) 7: Overall performance( )
: professor/HOD
options form
3: modify( )
4: delete( )
: professor/HOD
error message
: Database
3: Validate( )
4: valid[filled properly]
6: Error message( )
7: retype question( )
: professor/HOD
error message
: Database
3: Validate( )
4: valid[filled properly]
6: Error message( )
7: retype question( )
: professor/HOD
deletion form
deletion controller
error message
: Database
2: select Q&A ( )
3: Intimate to database( )
4: retrieving Q&A( )
5: Verification( )
6: Valid( )
7: Invalid( )
8: Error message( )
9: re-entry( )
: Administrator
options form
3: modify user( )
4: delete user( )
: Administrator
: Database
1: request for new user( ) 2: adding new user( ) 3: Verification( ) 4: not filled properly( )
7: Generating ID( )
modification form
: Database
4: retrieve database( )
5: modifying ( )
6: Verification( )
7: Improper modification( )
: Administrator
deletion form
: Database
3: Deleting( )
4: Updating( )
6.Reporting
: Database
Reporting controller
2: UPDATE( )
COLLOBORATION DIAGRAM
1.Login
1: Login()
: Student 3: Verification() 6: Error message() 4: Valid() 5: Invalid() Error message Welcome screen
Login controller
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( ) : Time out
5: Getting questions( )
9: time out( )
: Database
3.View Results
3: to avail options( ) options form : Student 1: to see his results( ) 4: to see a particular record( ) 6: to see overall performance( ) Individual performance : professor/HOD
: Database
1: to avail options( )
: Database
5: modify( ) 2: select question( ) 10: reentry( ) : professor/HOD 1: requesting question to be selected( ) Question selection form
4: retrieve( ) 6: Verification( )
9: Error message( )
2: adding new user( ) new user add form 1: request for new user( ) : Administrator 5: Error message ( )
3: Verification( ) add user controller 4: not filled properly( ) 6: filled properly( ) 7: Generating ID( )
error message
: Database
6.Reporting
cancel
2.Update User
details of user
if wrong
if correct
database updation
CLASS DIAGRAM
1.Login
+1
+1
+1 +1
<<Class Module>> Login form ID and password() Re-login()
login()
+1
+1 +1
+1
+1 <<Class Module>>
Welcome screen Correct()
+1 +1
2.Enter Exam
+1
<<Class Module>> Questioning_form Valid student ID &pwd() providing Q&A() options taken() Getting questions() time management() Answer the questions()
+NewProperty
3.View Results
<<Class Module>> Individual_performance To see his results() Individual records() To see a particular record() +NewProperty +1 <<Class Module>> Options_form Available_options() to_avail_options() <<Class Module>> Overall_performance +1 +NewProperty Overall records() Overall performance() To see overall performance()
<<Class Module>> Options_form Available_options() to_avail_options() +1 +1 +NewProperty <<Class Module>> Modify_Questions_form Retrieve() Modify()
+NewProperty <<Class Module>> Deletion_form Selecting Q&A() Retrieving Q&A() Re-enter() +1 +1 +1 <<Class Module>> Controller +1 +1 <<Class Module>> Error message Incorrect() +1
+1
+1
+NewProperty <<Class Module>> Modification_form Modifying() Retrieve data() Error message()
+1
+1
+1
+1
+1 <<Class Module>> Error message Incorrect()
COMPONENT DIAGRAM
SOURCE CODE:
1. Login
Option Explicit Public NewProperty As main_form Public NewProperty2 As login_cintroller Public Sub id___password() End Sub Public Sub relogin() 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.
5.
Ex.No:8 Date:
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.
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.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.
View status
Passenger
Booking Tickets
Login
Clerk
Cancellation
Report
required. From the database given by the passenger are checked and saved. If there is no contradiction the tickets is booked for the passenger.
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.
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.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.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.
: Passenger
Enter details:data db controller Display EnquiryError message entry form form form
: Database
2: Enter details( )[enter above details] 3: refer( )[availability of seat and airlines] 4: validate( )[check entered details]
5: valid( )
2.Booking Tickets
: Passenger
error form
: Database
1: request( )
2: enter details( )
3: validate( )
4: valid( )
5: confirmation( ) 6: update( )
7: invalid( )
8: error message( )
3.Payment mode
: Passenger
db controller
mode selection
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( )
4.Login
: Clerk
Login form
Main form
Login controller
Welcome form
Error message
1: Login( )
5: valid( )
6: display( ) 7: invalid( )
8: error message( )
5.Cancellation
: Passenger
: 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 : Database
5: output( ) 6: invalid( )
7: error message( )
COLLABORATION DIAGRAM
1.View Status
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( ) Error message form db controller 7: invalid( ) 3: refer( )[availability of seat and airlines] : Database
2.Booking Tickets
2: enter details( )
data entry form 1: request( ) : Passenger 8: error message( ) error form 7: invalid( ) 3: validate( ) db controller
5: confirmation( )
: Database
3.Payment mode
4: validation
2: enter details( ) data entry form 1: request( ) : Passenger 12: error message( ) error message form
3: validate( ) db controller
4.Login
1: Login( ) Login form 3: enter details( ) Main form 2: request to enter details( ) : Clerk 8: error message( ) 4: validate( ) Login controller 6: display( ) Error message 7: invalid( ) 5: valid( )
Welcome form
5.Cancellation
2: enter details( ) data entry form 1: request to enter details( ) : Passenger 8: error message ( )
3: validate( ) db controller
7: invalid( )
4: valid ( )
form
5: update( ) : Database : Clerk
6.Report
error message 7: error message( ) 6: invalid( )
CLASS DIAGRAM
1.View status
Passenger
Database
+1 +1
<<Class Module>> Display form confirmed()
2.Booking Tickets
Passenger
Database
+1 <<Class Module>> display form confirmed() <<Class Module>> Error message form invalid()
3.Payment Mode
Passenger
+1
4.Login
<<Class Module>> main form Clerk login()
5.Cancellation
Passenger
Database
Clerk
6.Report
Clerk
Database
ACTIVITY DIAGRAM
Enter details
Airline details
Select Airline airline selected Enter passenger list check availability Check availability
status availability record locked Mode of payment select mode Enter bank details cash available paid paid valid credit card Validate account details Locked
invalid
Deliver ticket
Update Database
COMPONENT DIAGRAM
SOURCE CODE:
1. View Status: Option Explicit Public NewProperty As error_form Public NewProperty2 As passenger Public Sub enter_dataild() End Sub
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
End Sub
5. Cancellation:
Option Explicit Public NewProperty As db_controller Public Sub if_confirmed() End Sub
6. Report:
Option Explicit Public NewProperty As error_form Public NewProperty2 As passenger Public Sub enter_dataild() End Sub
Ex.No:9 Date:
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 : 15TFT : Multimedia Keyboard : USB Optical type
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
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
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
Client
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:
Client
Server
System Admin
Close
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" <string> ( int argc, int argv[] )
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; }
} } catch ( SocketException& e ) { std::cout << "Exception was caught:" << e.description() << "\nExiting.\n"; } } return 0;
} catch ( SocketException& ) {} } } catch ( SocketException& e ) { std::cout << "Exception was caught:" << e.description() << "\nExiting.\n"; } } return 0;
while ( true ) { std::string data; new_sock >> data; new_sock << data; }
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
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
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:
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.
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.
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.
Employee
Maintain books
Manager
Login
Database
Purchase order
Administrator
View report
View stock
Customer
This use case describes how a user logs into the stock maintenance system.
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.
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.
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.
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.
SEQUENCE DIAGRAM:
1.Login
: Customer
Main form
Login form
Login controller
Welcome screen
login( ) Enter username and password( ) Verification( ) Retrieve from database( ) Valid( ) Invalid( )
2.View Reports
: Administrator
main form
controller
error message
: Database
Verification( )
Valid( )
Generate report( )
Invalid( )
re-enter ID( )
3. View Stock
: Customer
: Administrator
Controller
Error message
: Database
4. Maintain Stock
: Employee
option form
to avail options( ) add books( ) Sequence diagram... update books( ) Sequence diagram...
delete books( )
Sequence diagram-...
4.1 Add
: Employee
Selection
form
modification
form
Error message
: Database
Request for new books( ) add new books( ) Verification( ) filled properly( ) Generate ID( ) Not filled properly( ) Error message( )
4.2 Modify
: Employee
Modification form
Modification controller
Error message
: Database
intimate database( ) Retrieve datas( ) modify( ) Verification( ) improper modification( ) Displays error message( )
4.3 Delete
: Manager
Selection form
Deletion form
: Database
5. Purchase Orders
: Manager
option form
order profile
form
change orders( )
Sequence diagram-...
: Manager
create order form Request for new order( ) Create new order( )
controller
Error message
: Database
Error message ( )
: Manager
: Database
Request to select order( ) Selecting order( ) intimate database( ) retrieve datas () modifying( ) Verification ( ) Improper modification ( ) Error message( )
: Manager
Selection form
Deletion form
: Database
Deleting( )
Update ( )
COLLABORATION DIAGRAM:
1. Login
Main
form
1: login( ) 8: re-login( )
: Database
2. View Reports
3: Verification( ) controller
4: Valid( )
3. View Stock
Error message 2: Enter book details( ) : Customer 7: error message( )
5: Generate report( )
: Administrator Controll
er
4: Verified( ) : Database
4. Maintain Stock
form
: Employee
form
4.1 Add
2: add new books( ) Selection form 1: Request for new books( ) : Employee 5: Generate ID( ) 7: Error message( ) : Database 4: filled properly( ) 3: Verification( )
Error message
modificatio n form
4.2 Modify
3: intimate database( ) Selection form 1: Request to select books( ) 2: Selecting books( ) 5: modify( ) Modification form : Employee 8: Displays error message( ) : Database 4: Retrieve datas( )
6: Verification( )
Modification controller
4.3 Delete
5. Purchasing Orders
1: avail options( ) option form : Manager 2: create orders( ) 3: change orders( ) 4: delete orders( ) order profile form
form
: Manager
Error message
4: filled properly( )
controll
er
3: intimate database( ) order selection form : Database 1: Request to select order( ) 2: Selecting order( ) 5: modifying( ) modification form : Manager 8: Error message( ) 6: Verification ( ) 4: retrieve datas ()
modification controller
form
CLASS DIAGRAM:
1. Login
+1
+1
Welcome screen
Login Controller
+1
+1
verification()
correct()
enter()
password()
re-login()
2. Maintain Books
Update books
enter id()
author name()
publication()
change() update()
verify()
delete specified()
3. Purchase Orders
assign order
name of the book()
quantities() edition()
Delete purchase
order
request() confirm()
updates()
deletion() displays()
report administrator report enter hid ID() retrieves and displays() track()
book required()
book specification() displays()
maintain
view reports
books
Login
purchase
view stock
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
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