SRM INSTITUTE OF SCIENCE AND TECHNOLOGY

FACULTY OF SCIENCE AND HUMANITIES

DEPARTMENT OF COMPUTER APPLICATIONS

PRACTICAL RECORD NOTE

STUDENT NAME :

REGISTER :
NUMBER

CLASS : BCA SECTION:

YEAR & : III YEAR & VI SEM

SEMESTER

SUBJECT CODE : UCA20D08J

SUBJECT : OBJECT ORIENTED ANALYSIS AND

TITLE DESIGN

APRIL 2025
 SRM INSTITUTE OF SCIENCE AND TECHNOLOGY
FACULTY OF SCIENCE AND HUMANITIES
DEPARTMENT OF COMPUTER APPLICATIONS
SRM Nagar, Kattankulathur – 603 203
CERTIFICATE

Certified to be the bonafide record of practical work done by

Register No. of BCA Degree programme for

UCA20D08J – OBJECT ORIENTED ANALYSIS AND DESIGN in the Computer

lab in SRM Institute of Science and Technology during the academic year 2024-2025.

Staff In-charge Head of the Department

Submitted for Semester Practical Examination held on .

Internal Examiner External Examiner

 INDEX

S. No Date Name of the Experiment Page No Sign

1 ATM system

2 Payroll Management System

3 Quiz System

4 Stock Maintenance System

5 Passport Registration System

6 Student Mark Analysis System

7 Library Management System

8 Railway Ticket Reservation System

9 Placement Registration System

10 Exam Registration System

 ATM SYSTEM

Ex No :
Date :

AIM

ALGORITHM

USE CASE DIAGRAM

Step 1: Identify Actors

Actors represent entities that interact with the system. For an ATM system, the actors are:

 Client: The person using the ATM.

 ATM: The machine the client interacts with.
 System/Bank: The bank's backend system that processes requests.

Step 2: Identify Use Cases

Use cases describe the interactions or services provided by the system. For the ATM system, the
use cases are:

1. Deposit Amount: Client deposits money into their account.

2. Withdraw Amount: Client withdraws money from their account.
3. Review Details: Client checks account details (e.g., balance, recent transactions).
4. Update Details: Client updates account information (e.g., phone number, email).
5. Terminate Transaction: The transaction is completed and the system logs out the client.
6. Cancel Transaction: The client cancels an ongoing transaction.
7. Check PIN/Card: The system verifies the client’s card and PIN for security.

Step 3: Define Actor-Use Case Relationships

 Client: Interacts with all use cases.

 ATM: Manages deposit, withdrawal, transaction termination, cancellation, and PIN
check.
 System/Bank: Processes transactions and handles account details.
Step 4: Draw the Diagram

 Draw actors: Place actors (Client, ATM, System/Bank) outside the system boundary.
 Draw use cases: Inside the system boundary, use ovals for each use case.
 Connect: Draw lines between actors and relevant use cases.

Step 5: Define Optional Relationships (if needed)

 Use <<include>> for mandatory steps (e.g., Check PIN/Card before transactions).
 Use <<extend>> for optional actions (e.g., Cancel Transaction).

Step 6: Review

Ensure all actors are correctly linked to the relevant use cases

CLASS DIAGRAM

Step 1: Identify Key Classes

 ATM, Client, BankAccount, Transaction, Bank

Step 2: Define Attributes and Methods

1. ATM:
o Attributes: ATMID, location, currentBalance
o Methods: validateCard(), deposit(), withdraw()
2. Client:
oAttributes: clientID, cardNumber, PIN
oMethods: enterPIN(), requestTransaction()
3. BankAccount:
o Attributes: accountNumber, balance
o Methods: getBalance(), deposit(), withdraw()
4. Transaction:
o Attributes: transactionID, type, amount
o Methods: execute(), cancel()
5. Bank:
o Attributes: bankName, bankID
o Methods: processTransaction(), verifyPIN()

Step 3: Define Relationships

 ATM interacts with Client and BankAccount (association).

 Client aggregates with BankAccount.
 Transaction associates with ATM and BankAccount.
 Bank oversees all components.
Step 4: Draw the Diagram

 Draw rectangles for each class with attributes and methods.

 Connect the classes with lines to show relationships (association, aggregation).

Step 5: Finalize

Ensure the correct relationships and elements are represented.

ACTIVITY DIAGRAM

Step 1: Identify the Process

For an ATM system, the typical process flow involves a client performing transactions like
withdrawing money or checking their balance. The steps can include:

1. Insert Card
2. Enter PIN
3. Select Transaction
4. Process Transaction (Deposit, Withdraw, Check Balance, etc.)
5. End Transaction

Step 2: Define Activities

Each process involves several activities. Common activities for an ATM system include:

 Insert Card
 Validate Card
 Enter PIN
 Validate PIN
 Select Transaction Type
 Perform Transaction (Withdraw, Deposit, etc.)
 Check Balance
 Print Receipt
 End Session

Step 3: Define Decision Points

Decision points represent choices the client can make:

 Valid Card?: If invalid, eject the card.

 Correct PIN?: If incorrect, ask to re-enter PIN or terminate.
 Transaction Type?: Deposit, Withdraw, Check Balance, etc.

Step 4: Draw the Diagram

1. Start Node: Draw a solid black circle to represent the start of the activity.
 2. Actions/Activities: Draw rounded rectangles for each activity (e.g., Insert Card, Enter
PIN, Withdraw Money).
3. Decision Points: Represent decisions with diamonds. Label the outcomes with arrows
(e.g., Yes/No, Valid/Invalid).
4. Flow Arrows: Use arrows to show the flow between activities.
5. End Node: Draw a solid black circle with a ring around it to represent the end of the
process.

SEQUENCE DIAGRAM

Step 1: Identify Participants

Identify the main objects involved in the ATM transaction process:

 Client
 ATM
 Bank System

Step 2: Define the Sequence of Messages

Outline the sequence of interactions between the participants. Typical interactions for an ATM
transaction include:

1. Client inserts card.

2. ATM validates card.
3. Client enters PIN.
4. ATM validates PIN.
5. Client selects transaction type (e.g., Withdraw, Deposit).
6. ATM processes transaction.
7. Bank System updates account balance.
8. ATM provides confirmation or receipt to the Client.
9. Client ends session.

Step 3: Draw the Diagram

1. Lifelines: Draw vertical dashed lines for each participant (Client, ATM, Bank System).
2. Activation Bars: Use rectangles to represent the active period of each participant during
the interaction.
3. Messages: Draw horizontal arrows to represent messages or actions:
o From Client to ATM: Insert Card, Enter PIN, Select Transaction.
o From ATM to Bank System: Validate PIN, Process Transaction, Update
Account.
o Responses from ATM back to Client: Display Receipt, Confirm Transaction.

Step 4: Review and Finalize

Ensure that the sequence accurately reflects the flow of interactions. Check for the correct order
of messages and that all necessary interactions are included.
RESULT:
 PAYROLL MANAGEMENT SYSTEM

Ex No :
Date :

AIM

ALGORITHM

USE CASE DIAGRAM

Step 1: Identify Actors

 Identify the external entities interacting with the system:

o Employee
o Administrator

Step 2: Identify Use Cases

 List out the primary use cases in the system:

o Employee Information
o Time Card Information
o Purchase of Resources
o Payment Method Details
o Reports
o Management and Updation
o Payroll Generation

Step 3: Define Relationships

 Define which actor interacts with which use case:

o Employee interacts with:
 Employee Information
 Time Card Information
 Purchase of Resources
 Payment Method Details
 Reports
o Administrator interacts with:
 Employee Information
 Management and Updation
 Reports
 Payroll Generation
Step 4: Draw the Diagram

 Place actors on the diagram and position use cases in the center.
 Draw lines connecting actors to their use cases.

Step 5: Refine and Add Details

 Include relationships like «extend» and «include» where appropriate for refining use
cases.

CLASS DIAGRAM

Step 1: Identify Key Classes

 List out main classes based on your use cases:

o Employee
o TimeCard
o Purchase
o PaymentMethod
o Report
o Payroll

Step 2: Define Class Attributes and Methods

 Define attributes and methods for each class:

o Employee:
 Attributes: employeeID, name, salary
 Methods: getDetails(), updateDetails()

Step 3: Determine Relationships

 Identify relationships such as inheritance or association:

o Employee associates with TimeCard, Purchase, and PaymentMethod.
o Administrator manages Payroll and Reports.

Step 4: Draw the Diagram

 Draw classes as boxes with attributes and methods.

 Add lines to show associations, inheritance, or multiplicity between classes.

Step 5: Refine with Multiplicity and Associations

 Show multiplicity (e.g., "1 Employee to many TimeCards") and label the
relationships.
ACTIVITY DIAGRAM

Step 1: Choose a Process

 Pick a specific process like Employee Submits Time Card.

Step 2: Define Key Activities

 Break down the process into actions:

o Log in
o Enter Time Card
o Verify Time Card
o Save Time Card
o Log out

Step 3: Sequence the Activities

 Organize the activities in a logical order from start to finish.

Step 4: Draw the Diagram

 Draw action nodes for each activity.

 Connect them with arrows to show the flow of actions.

Step 5: Add Decision Points and End

 Add decision nodes (e.g., verification of time card) and finish with an end node.

SEQUENCE DIAGRAM

Step 1: Pick a Scenario

 Select a scenario such as Employee Requests Payroll Details.

Step 2: Identify Objects

 Identify objects involved:

o Employee, PayrollSystem, Database

Step 3: Define Message Flow

 Sequence the interactions between objects:

o Employee -> PayrollSystem: requestPayrollDetails()
o PayrollSystem -> Database: getPayrollDetails(employeeID)
o Database -> PayrollSystem: returnPayrollDetails()
Step 4: Draw Lifelines and Messages

 Draw the objects and lifelines vertically, with arrows representing the messages
exchanged.

Step 5: Add Activation Bars

 Add activation bars to show when an object is active and processing a request
RESULT:
 QUIZ SYSTEM

Ex No :
Date :

AIM

ALGORITHM

USE CASE DIAGRAM

Step 1: Identify Actors

 Actors:
o Participant
o Quiz Master

Step 2: Identify Use Cases

 Use Cases:
o Registration
o Prepare Questions
o Participation
o Scoring
o Report

Step 3: Define Relationships

 Relationships:
o Participant interacts with:
 Registration (create account)
 Participation (take quiz)
o Quiz Master interacts with:
 Prepare Questions (create/edit questions)
 Scoring (evaluate quiz)
 Report (generate results)

Step 4: Draw Diagram

 Create a visual representation:

o Place actors outside the system boundary.
o List use cases inside the boundary.
o Connect actors to relevant use cases with lines.
Step 5: Review and Refine

 Ensure all use cases and relationships are accurately represented. Check for any
missing interactions or actors.

CLASS DIAGRAM

Step 1: Identify Classes

 Classes:
o Participant
o QuizMaster
o Quiz
o Question
o Score
o Report

Step 2: Define Attributes and Methods

 Participant:
o Attributes: name, email
o Methods: register(), participate()
 QuizMaster:
o Attributes: name, email
o Methods: prepareQuestions(), scoreQuiz(), generateReport()
 Quiz:
o Attributes: title, questions[]
o Methods: start(), end()
 Question:
o Attributes: text, options[], correctAnswer
o Methods: validateAnswer()
 Score:
o Attributes: participantId, quizId, points
o Methods: calculateScore()
 Report:
o Attributes: quizId, results[]
o Methods: generateReport()

Step 3: Define Relationships

 Relationships:
o Participant (1) ↔ (0..*) Score
o QuizMaster (1) ↔ (0..*) Quiz
o Quiz (1) ↔ (0..*) Question
o Score (1) ↔ (1) Participant and Quiz

Step 4: Draw Diagram

 Represent each class with a box, showing attributes and methods. Use lines to depict
relationships, including multiplicity.
Step 5: Review and Refine

 Verify that all necessary classes, attributes, methods, and relationships are included
and accurate.

ACTIVITY DIAGRAM

Step 1: Identify Activities

 Activities:
o Registration
o Prepare Questions
o Participation
o Scoring
o Reporting

Step 2: Define Flow

 Example flow for Registration:

o Start → Input Info → Validate → Complete Registration

Step 3: Identify Decision Points

 Example: Validation checks during registration and question preparation.

Step 4: Draw Diagram

 Use UML symbols to represent activities (rounded rectangles), decisions (diamonds),

and flows (arrows) to visualize the process.

Step 5: Review and Refine

 Ensure the flow accurately represents all activities and decisions, checking for logical
progression.

SEQUENCE DIAGRAM

Step 1: Identify Objects

 Objects:
o Participant
o QuizMaster
o Quiz
o Question
o Score
o Report
Step 2: Define Interactions

 Example interactions:
o Participant registers → QuizMaster confirms.
o QuizMaster prepares questions → System saves questions.
o Participant answers questions → System submits answers.
o QuizMaster calculates scores → System saves scores.
o QuizMaster generates report → System displays report.

Step 3: Arrange Lifelines

 Place objects horizontally and draw vertical dashed lines (lifelines) for each.

Step 4: Draw Messages

 Use arrows to represent messages exchanged between objects, indicating the order of
interactions.

Step 5: Review and Refine

 Ensure that the sequence and timing of interactions make sense and are complete.
RESULT:
 STOCK MAINTENANCE SYSTEM

Ex No :
Date :

AIM

ALGORITHM

USE CASE DIAGRAM

Step 1: Identify Actors

 Actors:
o Customer
o Agent
o Stock Person

Step 2: Identify Use Cases

 Use Cases:
o Make Order
o Collect Company’s Customer Information
o Check for Customer Records
o Verify Product Order
o Update Billing
o Receive Packing Order
o Retrieve Stock
o Delivery

Step 3: Define Relationships

 Relationships:
o Customer interacts with:
 Make Order
 Collect Company’s Customer Information
 Check for Customer Records
o Agent interacts with:
 Verify Product Order
 Update Billing
 Receive Packing Order
 Delivery
o Stock Person interacts with:
 Retrieve Stock
Step 4: Draw Diagram

 Create a diagram:
o Place actors outside the system boundary.
o List use cases inside the boundary.
o Connect actors to relevant use cases with lines.

Step 5: Review and Refine

 Ensure all use cases and relationships are accurately represented and check
for any missing interactions.

CLASS DIAGRAM

Step 1: Identify Classes

 Classes:
o Customer
o Agent
o StockPerson
o Order
o CustomerRecord
o Billing
o PackingOrder
o Stock

Step 2: Define Attributes and Methods

 Customer:
o Attributes: name, contactInfo
o Methods: makeOrder(), collectCustomerInfo()
 Agent:
o Attributes: name, agentId
o Methods: verifyProductOrder(), updateBilling(),
receivePackingOrder(), deliver()
 StockPerson:
o Attributes: name, employeeId
o Methods: retrieveStock()
 Order:
o Attributes: orderId, productDetails, status
o Methods: createOrder(), checkOrderStatus()
 CustomerRecord:
o Attributes: customerId, recordDetails
o Methods: checkRecords()
 Billing:
o Attributes: billingId, amount
o Methods: generateInvoice()
 PackingOrder:
o Attributes: packingId, orderId
o Methods: createPackingOrder()
 Stock:
o Attributes: productId, quantity
o Methods: updateStock(), checkStock(
Step 3: Define Relationships

 Relationships:
o Customer (1) ↔ (0..*) Order
o Agent (1) ↔ (0..*) PackingOrder
o StockPerson (1) ↔ (0..*) Stock
o Order (1) ↔ (1) CustomerRecord
o Billing (1) ↔ (1) Order

Step 4: Draw Diagram

 Create class boxes with attributes and methods. Use lines to depict relationships,
including multiplicity.

Step 5: Review and Refine

 Verify that all classes, attributes, methods, and relationships are included and
accurate.

ACTIVITY DIAGRAM

Step 1: Identify Activities

 Activities:
o Make Order
o Collect Customer Information
o Check Customer Records
o Verify Product Order
o Update Billing
o Receive Packing Order
o Retrieve Stock
o Delivery

Step 2: Define Flow

 Example flow for Make Order:

o Start → Input Order Details → Validate Order → Confirm Order → End

Step 3: Identify Decision Points

 Example: Validate order status, check stock availability.

Step 4: Draw Diagram

 Use UML symbols to represent activities (rounded rectangles), decisions (diamonds),

and flows (arrows).

Step 5: Review and Refine

 Ensure the flow accurately captures all activities and decision points, checking for
logical progression
SEQUENCE DIAGRAM

Step 1: Identify Objects

 Objects:
o Customer
o Agent
o StockPerson
o Agent Database
o CustomerDatabase
o Stock Database
o Shipping Agents
o Accountant Database
o Purchase Database

Step 2: Define Interactions

 Example interactions:
o Customer makes an order → Agent verifies product → Agent updates billing
→ StockPerson retrieves stock → Delivery is made.

Step 3: Arrange Lifelines

 Place objects horizontally, each with a vertical dashed line (lifeline).

Step 4: Draw Messages

 Use arrows to represent messages exchanged between objects, indicating the order of
interactions.

Step 5: Review and Refine

 Ensure that the sequence and timing of interactions are logical and complete.
RESULT:
 PASSPORT REGISTRATION SYSTEM
Ex.No :
Date :

AIM

ALGORITHM

USE CASE DIAGRAM

Step 1: Identify Actors

 Actors:
o Applicant
o Administrator

Step 2: Identify Use Cases

 Use Cases:
o Registration
o Check Status
o Process Application
o Dispatch Passport

Step 3: Define Relationships

 Relationships:
o Applicant interacts with:
 Registration
 Check Status
o Administrator interacts with:
 Process Application
 Dispatch Passport

Step 4: Draw Diagram

 Create a diagram:
o Place actors (Applicant, Administrator) outside the system boundary.
o List use cases (Registration, Check Status, Process Application, Dispatch
Passport) inside the boundary.
o Connect actors to relevant use cases with lines.

Step 5: Review and Refine

 Ensure all use cases and relationships are accurately represented and check for any
missing interactions.
CLASS DIAGRAM

Step 1: Identify Classes

 Classes:
o Applicant
o Administrator
o Application
o Passport
o Status

Step 2: Define Attributes and Methods

 Applicant:
o Attributes: name, contactInfo, applicationId
o Methods: register(), checkStatus()
 Administrator:
o Attributes: name, adminId
o Methods: processApplication(), dispatchPassport()
 Application:
o Attributes: applicationId, applicantId, status
o Methods: submitApplication(), updateStatus()
 Passport:
o Attributes: passportId, applicantId, issueDate, expiryDate
o Methods: generatePassport()
 Status:
o Attributes: statusId, applicationId, currentStatus
o Methods: getStatus()

Step 3: Define Relationships

 Relationships:
o Applicant (1) ↔ (0..*) Application
o Administrator (1) ↔ (0..*) Application
o Application (1) ↔ (1) Passport
o Application (1) ↔ (1) Status

Step 4: Draw Diagram

 Create class boxes with attributes and methods. Use lines to depict relationships,
including multiplicity.

Step 5: Review and Refine

 Verify that all classes, attributes, methods, and relationships are included and
accurate.
ACTIVITY DIAGRAM

Step 1: Identify Activities

 Activities:
o Login
o Registration
o Application Form
o Verification
o Enquiry
o Payment
o Getting Passport

Step 2: Define Flow

 Example flow for Registration:

o Start → Fill Application Form → Submit Application → Confirmation

Step 3: Identify Decision Points

 Example: Check if application is complete before processing.

Step 4: Draw Diagram

 Use UML symbols to represent activities (rounded rectangles), decisions (diamonds),

and flows (arrows).

Step 5: Review and Refine

 Ensure the flow accurately captures all activities and decision points, checking for
logical progression.

SEQUENCE DIAGRAM

Step 1: Identify Objects

 Objects:
o Administrator
o System
o Admin Panel
o Database
o Applicant

Step 2: Define Interactions

 Example interactions:
o Applicant registers → Administrator processes application → Status is
checked → Passport is dispatched.
Step 3: Arrange Lifelines

 Place objects horizontally, each with a vertical dashed line (lifeline).

Step 4: Draw Messages

 Use arrows to represent messages exchanged between objects, indicating the order of
interactions.

Step 5: Review and Refine

 Ensure that the sequence and timing of interactions are logical and complete.
RESULT:
 STUDENT MARK ANALYSIS SYSTEM
Ex No:
Date:

AIM

ALGORITHM
USE CASE DIAGRAM
Step 1: Identify the Actors
 Student: Views grades and subjects.
 Staff: Manages students, subjects, marks, and assigns grades.
Step 2: Identify Use Cases
 Student Use Cases:
o View subjects
o View marks
o View total marks
o View grade
 Staff Use Cases:
o Add/update subjects
o Enter marks
o Calculate total marks
o Assign grade
o Manage student records (add/remove students)
Step 3: Define Relationships
 Student interacts with:
o View subjects, marks, total marks, and grade.
 Staff interacts with:
o Add subjects, enter marks, calculate total, assign grades, and manage students.
Step 4: Draw the Diagram
 Draw Student and Staff as actors.
 Add use cases in ellipses inside the system boundary.
 Connect the actors to their related use cases.
Step 5: Add Relationships
 Use include between related use cases, e.g., “Calculate total” includes “Enter marks.”
 Use extend for optional use cases, e.g., “Assign grade” extends “Calculate total.”
CLASS DIAGRAM
Step 1: Identify the Classes
 Classes: Student, Staff, Subject, Marks, Total, Grade.
Step 2: Define Attributes and Methods
 Student:
o Attributes: studentID, name, totalMarks, grade.
o Methods: viewMarks(), viewTotal(), viewGrade().
 Staff:
o Attributes: staffID, name.
o Methods: addStudent(), enterMarks(), assignGrade().
 Subject:
o Attributes: subjectID, subjectName.
o Methods: addSubject(), viewSubject().
 Marks:
o Attributes: studentID, subjectID, mark.
o Methods: enterMark().
 Total:
o Attributes: studentID, totalMarks.
o Methods: calculateTotal().
 Grade:
o Attributes: gradeID, grade.
o Methods: assignGrade().
Step 3: Identify Relationships
 A Student has many Marks.
 Marks are associated with a Subject.
 Staff manages Student records and enters Marks.
 Total is calculated from Marks.
Step 4: Draw the Diagram
 Each class is represented as a box containing its attributes and methods.
 Use association lines to show relationships between Student, Marks, Subject, Grade,
and Total.
Step 5: Add Multiplicity and Associations
 Example: A Student is associated with many Marks, and each Mark is related to a
specific Subject.

ACTIVITY DIAGRAM
Step 1: Choose a Process
 Example: "Calculate and Assign Grades"
Step 2: Define Key Activities
 Student: Views total marks and grades.
 Staff: Enters marks, calculates total, assigns grades.
Step 3: Sequence the Activities
 Staff enters marks → System calculates total → System assigns grades → Student
views marks and grades.
Step 4: Draw the Diagram
 Use action nodes for activities: “Enter Marks,” “Calculate Total,” “Assign Grades,”
“View Marks/Grades.”
 Connect the nodes with arrows to indicate flow.
Step 5: Add Decision Points
 Add a decision point for assigning grades based on the total marks (e.g., "If total > 90,
assign grade A").

SEQUENCE DIAGRAM
Step 1: Pick a Scenario
 Example: Staff enters marks, system calculates total, and Student views grade.
Step 2: Identify Objects
 Staff, Student, System, Marks, Total, Grade.
Step 3: Define Message Flow
 Staff → System: enterMarks()
 System → Marks: storeMarks()
 System → Total: calculateTotal()
 System → Grade: assignGrade()
 Student → System: viewGrade()
Step 4: Draw Lifelines
 Add vertical lifelines for Staff, Student, System, etc.
 Draw arrows between lifelines for each interaction.
Step 5: Add Activation Bars
 Activation bars show when an object is processing (e.g., calculating total marks,
assigning grade).
RESULT:
 LIBRARY MANAGEMENT SYSTEM
Ex No:
Date:

AIM

ALGORITHM
USE CASE DIAGRAM

Step 1: Identify Actors

 Student: The individual who submits ID cards and requests to issue books.
 Librarian: The person who verifies ID cards, issues books, and manages the library
system.
 Supplier: The external entity that provides books to the library.

Step 2: Identify Use Cases

 Submit ID Card: The student submits their ID card.

 Verify ID Card: The librarian verifies the submitted ID card.
 Grant Permission Only if ID Card is Valid: Librarian grants permission based on ID
card validity.
 Request to Issue Book: Student requests to issue a book.
 Issue Book: Librarian issues the requested book.
 Return the Book: Student returns a previously issued book.
 Search the Database for Book: Librarian searches the library database for book
availability.
 Check Whether the Book is Available or Not: Librarian checks if the book is
available.
 Issue the Book if Available: Librarian issues the book if it's available.

Step 3: Create System Boundary

 Draw a rectangle labeled "Library Management System" to represent the system

boundary.

Step 4: Place Actors Outside the System

 Position the Student on the left, Librarian in the middle, and Supplier on the right
side of the rectangle.
Step 5: Connect Actors to Use Cases

 Draw ovals for each use case inside the rectangle and connect actors to the relevant use
cases:
o Student connects to:
 Submit ID Card
 Request to Issue Book
 Return the Book
o Librarian connects to:
 Verify ID Card
 Grant Permission Only if ID Card is Valid
 Issue Book
 Search the Database for Book
 Check Whether the Book is Available or Not
 Issue the Book if Available

CLASS DIAGRAM

Step 1: Identify Classes

 Student
 Librarian
 Book
 IDCard
 Supplier
 LibraryDatabase

Step 2: Define Attributes and Methods

 Student:
o Attributes: name, studentID, submittedIDCard
o Methods: submitIDCard(), requestBook(), returnBook()
 Librarian:
o Attributes: librarianID, password
o Methods: verifyIDCard(), grantPermission(), issueBook(), searchDatabase(),
checkAvailability()
 Book:
o Attributes: title, author, ISBN, availabilityStatus
o Methods: markAsIssued(), markAsReturned()
 IDCard:
o Attributes: idCardNumber, validityStatus
o Methods: verify()
 Supplier:
o Attributes: supplierID, name
o Methods: supplyBook()
  LibraryDatabase:
o Attributes: books (list of Book objects)
o Methods: searchBook(), updateBookStatus()

Step 3: Draw Relationships

 Connect Student to IDCard (1-to-1).

 Connect Librarian to Book (1-to-many).
 Connect Book to LibraryDatabase (1-to-1).
 Connect Supplier to Book (1-to-many).

Step 4: Layout Classes

 Arrange the classes logically to show their relationships.

Step 5: Add Visibility Modifiers

 Indicate access modifiers for attributes and methods (public +, private -, protected #).

ACTIVITY DIAGRAM

Step 1: Start Node

 Begin with a filled circle representing the start of the process.

Step 2: Define Activities

 For Submit ID Card:

o Fill out ID card submission form
o Submit ID card
 For Verify ID Card:
o Librarian retrieves submitted ID card
o Librarian verifies ID card
 For Grant Permission:
o If ID card is valid: grant permission
o If ID card is invalid: notify student
 For Request to Issue Book:
o Student requests a book
 For Issue Book:
o Librarian checks availability
o If available, issue book
o If not available, notify student
 For Return the Book:
o Student returns a book

Step 3: Control Flows

 Draw arrows to indicate the flow from one activity to the next.
Step 4: Decision Nodes

 Use diamond shapes to represent decisions (valid or invalid ID, availability of the
book).

Step 5: End Node

 Connect activities to an end node (represented by a circle with a ring).

SEQUENCE DIAGRAM

Step 1: Identify Objects

 Student
 Librarian
 Supplier
 Database

Step 2: Determine Sequence of Messages

 For Submit ID Card:

o Student → IDCard: submitIDCard()
o IDCard → Librarian: notifySubmission()
 For Verify ID Card:
o Librarian → IDCard: verify()
o IDCard → Librarian: returnValidity()
 For Grant Permission:
o Librarian → Student: grantPermission() (if valid)
o Librarian → Student: notifyInvalid() (if invalid)
 For Request to Issue Book:
o Student → Librarian: requestBook()
o Librarian → Book: checkAvailability()
o Book → Librarian: returnAvailabilityStatus()
 For Issue Book:
o If available:
 Librarian → Book: issueBook()
 Book → Librarian: markAsIssued()
 Librarian → Student: confirmIssuance()
o If not available:
 Librarian → Student: notifyNotAvailable()

Step 3: Draw Lifelines

 Vertical dashed lines for each object representing their existence over time.

Step 4: Represent Messages

 Horizontal arrows showing interactions over time, labeled with message names.

Step 5: Return Messages

 Use dashed arrows for responses to indicate the flow of control back to the calling object.
RESULT:
 RAILWAY TICKET RESERVATION SYSTEM

Ex No :
Date :

AIM

ALGORITHM

USE CASE DIAGRAM

Step 1: Identify Actors

 Passenger: Books and cancels tickets, views train details and fares.
 Administrator: Updates train details and manages other system functionalities.

Step 2: Identify Use Cases

 Passenger Use Cases:

o Reserve Ticket
o Cancel Ticket
o View Ticket Fare
o View Train Details
 Administrator Use Cases:
o Update Train Details

Step 3: Define Relationships

 Passenger interacts with:

o Reserve Ticket
o Cancel Ticket
o View Ticket Fare
o View Train Details
 Administrator interacts with:
o Update Train Details

Step 4: Draw the Diagram

 Place Passenger and Administrator on the diagram as actors.

 Use ellipses for each use case and connect actors to the appropriate use cases.
Step 5: Refine and Add Details

 Use «include» if needed for overlapping functionalities, such as ticket reservation

depending on fare viewing.
 You can also use «extend» to show optional interactions like adding extra services to a
ticket reservation.

CLASS DIAGRAM

Step 1: Identify Key Classes

 Passenger
 Administrator
 Train
 Ticket
 Fare

Step 2: Define Class Attributes and Methods

 Passenger:
o Attributes: passengerID, name, email, contactNumber
o Methods: reserveTicket(), cancelTicket(), viewFare(), viewTrainDetails()
 Administrator:
o Attributes: adminID, name
o Methods: updateTrainDetails()
 Train:
o Attributes: trainID, trainName, source, destination, availableSeats
o Methods: updateTrainDetails(), getTrainDetails()
 Ticket:
o Attributes: ticketID, passengerID, trainID, fare, reservationStatus
o Methods: reserve(), cancel()
 Fare:
o Attributes: fareID, trainID, amount
o Methods: calculateFare()

Step 3: Determine Relationships

 Passenger is associated with Ticket.

 Administrator is associated with Train.
 Ticket and Fare are associated with Train.

Step 4: Draw the Diagram

 Represent each class as a box containing attributes and methods.

 Show associations between Passenger, Administrator, Train, Ticket, and Fare.

Step 5: Refine with Multiplicity and Associations

 Example: One Passenger can reserve multiple Tickets, and one Ticket corresponds to
one Train. 
ACTIVITY DIAGRAM

Step 1: Choose a Process

 Passenger Reserves a Ticket

Step 2: Define Key Activities 

 Passenger enters journey details, selects train, views fare, confirms booking, and makes
payment.
 System reserves the seat and generates the ticket.

Step 3: Sequence the Activities

 Passenger:
1. Log in
2. Select Journey Details (Source & Destination)
3. View Available Trains
4. View Fare
5. Reserve Ticket
6. Make Payment
7. Receive Confirmation

Step 4: Draw the Diagram

 Use action nodes for each activity, connecting them with arrows showing flow from
start to end.

Step 5: Add Decision Points and End

 Add a decision point between selecting journey details and confirming reservation
based on seat availability.

SEQUENCE DIAGRAM

Step 1: Pick a Scenario

 Passenger Cancels a Reserved Ticket

Step 2: Identify Objects

 Passenger, Reservation System, Payment System, Train, Ticket

Step 3: Define Message Flow

 Passenger -> Reservation System: cancelTicket()

 Reservation System -> Ticket: verifyTicket()
 Reservation System -> Payment System: processRefund()
 Payment System -> Reservation System: refundConfirmation()
 Reservation System -> Passenger: cancelConfirmation()

Step 4: Draw Lifelines and Messages

 Draw vertical lifelines for each object, and use arrows to represent the message flow
between them.

Step 5: Add Activation Bars

 Activation bars show when objects are processing the message, such as the reservation
system verifying the ticket or the payment system processing the refund.
RESULT:
 PLACEMENT REGISTRATION SYSTEM

Ex No:
Date:

AIM

ALGORITHM

USE CASE DIAGRAM

Step 1: Identify Actors

 Applicant
 HR

Step 2: Identify Use Cases

 Register
 Know Status
 Admin Panel
 Send Response
 Delete Application

Step 3: Create System Boundary

 Draw a rectangle to represent the system, labeling it "Placement Registration System".

Step 4: Place Actors Outside the System

 Position the Applicant on the left side and HR on the right side of the rectangle.

Step 5: Connect Actors to Use Cases

 Draw ovals inside the rectangle for each use case.

 Connect Applicant to:
o Register
o Know Status
 Connect HR to:
o Admin Panel
o Send Response
o Delete Application
CLASS DIAGRAM

Step 1: Identify Classes

 Applicant
 Application
 HR
 Status

Step 2: Define Attributes and Methods

 Applicant:
o Attributes: name, rollNumber, email, phone, course, year, cgpa
o Methods: register(), checkStatus()
 Application:
o Attributes: applicationID, applicant, status
o Methods: updateStatus(), delete()
 HR:
o Attributes: hrID, password
o Methods: login(), sendResponse(), deleteApplication()
 Status:
o Attributes: applicationID, currentStatus
o Methods: notifyApplicant()

Step 3: Draw Relationships

 Connect Applicant to Application (1-to-many).

 Connect Application to Status (1-to-1).
 Connect HR to Application (1-to-many).

Step 4: Layout Classes

 Arrange the classes logically, indicating their relationships clearly.

Step 5: Add Visibility Modifiers

 Indicate access modifiers for attributes and methods (public +, private -, protected #).

ACTIVITY DIAGRAM

Step 1: Start Node

 Begin with a filled circle representing the start of the process.

Step 2: Define Activities

 For Register:
o Fill out registration form
o Submit application
o Confirmation received
  For Know Status:
o Enter email
o Retrieve application status
 For Admin Panel:
o HR logs in
o View applications
 For Send Response:
o HR selects application
o Update status
o Notify applicant
 For Delete Application:
o HR selects application
o Confirm deletion

Step 3: Control Flows

 Draw arrows to indicate the flow from one activity to the next.

Step 4: End Node

 Connect activities to an end node (represented by a circle with a ring).

Step 5: Parallel Activities (if applicable)

 Use a fork node to show activities that can occur simultaneously.

SEQUENCE DIAGRAM

Step 1: Identify Objects

 Applicant
 Application System
 HR

Step 2: Determine Sequence of Messages

 For Register:
o Applicant → Application System: register()
o Application System → Applicant: confirmation()
 For Know Status:
o Applicant → Application System: checkStatus()
o Application System → Applicant: statusResult()
 For Send Response:
o HR → Application System: sendResponse()
o Application System → Applicant: notifyStatus()
 For Delete Application:
o HR → Application System: deleteApplication()
o Application System → HR: confirmation()
Step 3: Draw Lifelines

 Vertical dashed lines for each object representing their existence over time.

Step 4: Represent Messages

 Horizontal arrows showing interactions over time, labeled with message names.

Step 5: Return Messages

 Use dashed arrows for responses to indicate the flow of control back to the calling
object.
RESULT:
 EXAM REGISTRATION SYSTEM

Ex.No :
Date :

AIM

ALGORITHM

USE CASE DIAGRAM

Step 1: Identify Actors

 Student: Submits details, proof, and fees for exam registration.

 Education Officer: Verifies proof and issues hall tickets.

Step 2: Identify Use Cases

 Student Use Cases:

o Enter Student Details
o Upload Student Photo
o Verify Student Proof
o Pay Exam Fees
o Download Hall Ticket
 Education Officer Use Cases:
o Issue Hall Ticket
o Submit Student Proof

Step 3: Define Relationships

 Student interacts with:

o Enter Student Details
o Upload Student Photo
o Verify Student Proof
o Pay Exam Fees
o Download Hall Ticket
 Education Officer interacts with:
o Submit Student Proof
o Issue Hall Ticket

Step 4: Draw the Diagram

 Place Student and Education Officer on the diagram as actors.

 Use ellipses for each use case and connect actors to the appropriate use cases.
Step 5: Refine and Add Details

 Use «extend» for the dependency of "Download Hall Ticket" on "Pay Exam Fees".

Use «include» for related tasks like "Submit Student Proof" and "Verify Student Proof"

CLASS DIAGRAM

Step 1: Identify Key Classes

 Student
 Education Officer
 Proof
 Payment
 Hall Ticket

Step 2: Define Class Attributes and Methods

 Student:
o Attributes: studentID, name, photo, proof, feesPaid
o Methods: enterDetails(), uploadPhoto(), submitProof(), payFees(),
downloadHallTicket()
 Education Officer:
o Attributes: officerID, name
o Methods: verifyProof(), issueHallTicket()
 Proof:
o Attributes: proofID, proofType, proofStatus
o Methods: submitProof(), verifyProof()
 Payment:
o Attributes: paymentID, amount, paymentStatus
o Methods: makePayment()
 HallTicket:
o Attributes: ticketID, studentID, issueDate
o Methods: generateTicket()

Step 3: Determine Relationships

 Student is associated with Proof and Payment.

 Education Officer verifies Proof and issues HallTicket.
 Student downloads HallTicket after payment is completed.

Step 4: Draw the Diagram

 Represent each class as a box containing attributes and methods.

 Show associations between Student, Proof, Payment, Education Officer, and
HallTicket.
Step 5: Refine with Multiplicity and Associations

 Example: One Student can submit multiple Proofs, but each Proof is verified by one
Education Officer.

ACTIVITY DIAGRAM

Step 1: Choose a Process

 Student Submits Exam Registration

Step 2: Define Key Activities

 Student enters details, uploads photo, submits proof, pays fees, and downloads hall
ticket.
 Education Officer verifies the proof and issues the hall ticket.

Step 3: Sequence the Activities

 Student:
1. Log in
2. Enter Student Details
3. Upload Photo
4. Submit Proof
5. Pay Fees
6. Download Hall Ticket
 Education Officer:
1. Verify Proof
2. Issue Hall Ticket

Step 4: Draw the Diagram

 Use action nodes for each activity, connecting them with arrows showing flow from
start to end.

Step 5: Add Decision Points and End

 Add a decision point between proof submission and verification. If the proof is valid,
proceed to fees payment; otherwise, request re-submission of proof.

SEQUENCE DIAGRAM

Step 1: Pick a Scenario

 Student Requests Hall Ticket after Payment

Step 2: Identify Objects

 Student, Education System, Payment System, Education Officer, Hall Ticket System

Step 3: Define Message Flow

 Student -> Education System: requestHallTicket()

 Education System -> Payment System: verifyPayment()
 Payment System -> Education System: paymentVerified()
 Education System -> Education Officer: verifyProof()
 Education Officer -> Education System: issueHallTicket()
 Education System -> Student: provideHallTicket()

Step 4: Draw Lifelines and Messages

 Draw vertical lifelines for each object, and use arrows to represent the message flow
between them.

Step 5: Add Activation Bars

 Activation bars show when objects are processing the message, e.g., when the system
verifies payment and when the officer verifies proof.
RESULT: