EXPERIMENT NO.
AIM: To draw a sample Activity Diagram for a real system – the Railway Reservation System.
REQUIREMENTS:
Hardware Requirements:
• Minimum: Intel Core i3 processor, 4GB RAM
• Recommended: Intel Core i5 or higher, 8GB RAM or more for better performance
• Input Devices: Standard keyboard and mouse
• Display: Colored monitor with at least 800x600 resolution
Software Requirements:
• Operating System: Windows 10/11, Linux, or macOS.
• UML Modeling Tool: Rational Rose or any compatible UML software.
THEORY:
UML 2 Activity Diagrams are essential for modeling dynamic workflows and decision-driven
processes. In the context of a Railway Reservation System, these diagrams are used to visualize ticket
bookings, cancellations, seat allocations, and payment verifications. The diagrams help identify the
sequence of operations and actor responsibilities including those of Passengers, the Reservation
System, and Railway Staff.
Activity diagrams offer a clear visual language that outlines system behavior in various scenarios and
can support design, documentation, and analysis.
Basic Notations in the Railway Reservation System Context:
• Initial Node: Indicates the start of the process (e.g., "User Login").
• Activity: Rounded rectangles indicating steps like "Search Train", "Select Seat", or "Make
Payment".
• Decision: Diamond shapes used for decision points such as [Train Available?], [Payment
Successful?].
• Merge: Merges multiple incoming flows into one.
• Fork: Represents the beginning of parallel actions like "Send SMS" and "Update Database".
• Join: Merges concurrent paths into one before continuing.
• Condition (Guard): Square brackets like [Valid ID] or [Refund Eligible].
• Partition (Swimlane): Divides the diagram into vertical zones by actor (Passenger, System,
Staff).
• Sub-activity Indicator: Represents a subprocess like "Payment Gateway".
• Flow Final: Ends a specific process branch, e.g., when payment fails.
GUIDELINES FOR DRAWING AN ACTIVITY DIAGRAM:
1. General Guidelines
Always begin the diagram with an initial node and end with an activity final node. If the process
becomes too complex, divide it into simpler sub-processes. This improves understanding and
maintainability.
2. Activities
Ensure each activity is specific and well-connected. Avoid "black hole" activities with only incoming
flows or "miracle" activities with only outgoing ones, as they indicate missing steps.
3. Decision Points
Use decisions after critical actions requiring validation, such as "Check Seat Availability" or
"Payment Success?". Apply guard conditions to clearly define each possible outcome.
4. Guards
Every outgoing transition from a decision must have a unique guard condition to prevent ambiguity.
Use [Otherwise] for default paths when applicable.
5. Parallel Activities
Use forks to split into parallel processes like "Notify User" and "Update DB" post-booking. Each fork
should be paired with a join to ensure proper synchronization.
6. Swimlane Guidelines
Actors such as Passenger, Reservation System, and Railway Staff should each have their own
swimlane. Keep the number of lanes minimal for readability and logical flow.
7. Action-Object Guidelines
"Booked" → "Cancelled"), this should be reflected in the diagram. Keep object usage minimal and
Place shared action-objects along swimlane borders. If objects like tickets change states (e.g.,
meaningful.
ACTIVITY DIAGRAM FOR RAILWAY RESERVATION SYSTEM:
Core System Architecture:
A three-tier interaction model defines actor roles and system responsibilities:
• Client (Passenger): Initiates ticket booking, cancellation, or inquiries.
• Reservation System: Core system that handles logic for checking availability, processing
payments, and managing confirmations.
• Railway Staff: Verifies identity, confirms high-value bookings, or manually processes
cancellations.
Use Case: Ticket Booking Workflow
1. Initial Interaction Phase
• User logs in or signs up.
• User enters travel details and searches for trains.
• System displays available trains and class options.
2. Selection and Verification Phase
• Passenger selects train, class, and seat.
• System verifies seat availability.
• Passenger enters traveler details and ID proof.
3. Payment and Confirmation
• System redirects to a secure payment gateway.
• If [Payment Successful], ticket is generated.
• If [Payment Failed], process ends or retries are offered.
4. Parallel Confirmation
• On successful payment: Seats are allocated.
• Notification (SMS/email) is sent.
• Reservation database is updated concurrently.
5. Completion
• System displays ticket with PNR and transaction details.
• Process ends at the activity final node.
Theoretical Principles:
• Segregation of Duties: Roles are clearly separated between passenger, system, and staff.
• Checkpoint Validation: Every decision (like [Seat Available?], [Payment Success?]) acts as a
control gate.
• Sequential Process Integrity: Each step flows logically from login to ticket generation.
• Transaction Finality: Each transaction concludes with ticket confirmation or failure state.
Use Case: Ticket Cancellation Workflow
Flow Summary:
• Passenger logs in and navigates to "My Bookings".
• Selects ticket to cancel.
• System checks refund policy and timing.
• If eligible, refund is processed.
• Booking is updated in the reservation system.
• If not eligible, system exits process.
Sample Activity Diagram Design Logic:
Core System Flow:
• All user actions begin with authentication.
• Transactions are routed based on user-selected operations (book/cancel/inquiry).
• Verification stages are embedded before critical transitions like payment or refund.
Security Features:
• System follows fail-safe principles: invalid entries or failed payments do not disrupt system
flow.
• Guard conditions enforce secure and logical flow transitions.
Parallel Processing Example:
• After booking, SMS and email are sent in parallel while also updating the database.
• This improves efficiency and reduces response time for user feedback.
CONCLUSION:
The Activity Diagram for the Railway Reservation System visually represents the control and data
flow for booking and cancellation scenarios. By incorporating elements like swimlanes, guards, forks,
joins, and conditional decisions, the model offers a comprehensive understanding of responsibilities
and system operations. The design not only enhances clarity but also supports efficient
implementation and future process optimization in real-time systems.
EXPERIMENT NO. 7
AIM: To prepare a State Chart Diagram for the Railway Reservation System.
REQUIREMENTS:
Hardware Requirements:
• Minimum: Intel Core i3 processor, 4GB RAM
• Recommended: Intel Core i5 or higher, 8GB RAM or more for better performance
• Input Devices: Standard keyboard and mouse
• Display: Colored monitor with at least 800x600 resolution
Software Requirements:
• Operating System: Windows 10/11, Linux, or macOS.
• UML Modeling Tool: Rational Rose or any compatible UML software.
THEORY:
A State Chart Diagram (also known as a State Machine Diagram) is used to model the dynamic
behavior of an object in response to external events. It is used to represent the state changes of an
object, based on different events and conditions in the system. In a Railway Reservation System,
the State Chart Diagram can be used to model the lifecycle of an object, such as a Ticket.
This diagram illustrates how the ticket goes through various states such as "Booked,"
"Confirmed," "Cancelled," and "Payment Pending" based on the actions performed by the user or
the system.
State diagrams help visualize the flow of an object through its possible states, making it easier to
understand the system's behavior over time.
Key Notations in a State Chart Diagram:
State: Represents the condition of an object at a specific time (e.g., "Ticket Booked," "Payment
Pending").
Transition: The movement from one state to another, triggered by an event or action (e.g.,
"Payment Success" transitions the ticket from "Payment Pending" to "Ticket Booked").
Event: External or internal occurrence that causes a transition (e.g., "Payment Failure").
Initial State: The state at the beginning of an object's lifecycle (e.g., "Booking Started").
Final State: The state at the end of an object's lifecycle (e.g., "Booking Completed").
Action: The process that occurs during a state change (e.g., "Generate Ticket").
Guard Conditions: Conditions that need to be true for a transition to occur (e.g., [Valid
Payment]).
Fork/Join: Represents parallel processing states, such as updating the database and sending
notifications simultaneously.
State Chart Diagram for Railway Reservation System:
This diagram will represent the lifecycle of a Ticket within the Railway Reservation System.
Core States of the Ticket Lifecycle:
Booking Started
Initial state when the user logs in or initiates the booking process.
Payment Pending
When the user selects a train and enters payment details, the system waits for payment.
Payment Successful
The state after a successful payment. The ticket is marked as "Booked" and confirmation is sent.
Payment Failed
The state after a failed payment. The user is prompted to retry or cancel the booking.
Ticket Booked
The final state after a successful booking and payment. The ticket is confirmed and assigned.
Ticket Cancelled
The state when the user cancels the booking before the journey starts. The system processes
refunds if applicable.
Booking Expired
This state represents the expiration of a booking when the user fails to pay within a certain time
limit.
Booking Completed (Final State)
The final state after the booking process is completed successfully.
State Chart Diagram Workflow (Ticket Lifecycle):
Booking Started → Payment Pending
After the user logs in and selects a train, the system enters the "Payment Pending" state.
Payment Pending → Payment Successful
Once the user completes payment successfully, the system transitions to "Payment Successful"
and the ticket is booked.
Payment Pending → Payment Failed
If the payment fails, the system enters the "Payment Failed" state. The user is asked to retry or
cancel.
Ticket Booked → Ticket Cancelled
The user can cancel the ticket after it is booked, which moves the ticket to the "Ticket Cancelled"
state.
Ticket Booked → Booking Expired
If payment is not received within a certain time period, the booking expires and the state changes
to "Booking Expired."
Ticket Booked → Booking Completed (Final State)
Once the ticket is confirmed and the user boards the train, the system enters the "Booking
Completed" final state.
State Chart Diagram Example:
Here's a textual representation of how the states and transitions could be designed in a State
Chart Diagram:
lua
Copy
Edit
+--------------------+ +------------------+ +-----------------------+
| Booking Started | ----> | Payment Pending | ----> | Payment Successful |
+--------------------+ +------------------+ +-----------------------+
| |
v v
+------------------+ +------------------+
| Payment Failed | <---- | Ticket Booked |
+------------------+ +------------------+
| |
v v
+------------------+ +------------------+
| Ticket Cancelled | | Booking Expired |
+------------------+ +------------------+
|
v
+------------------+
| Booking Completed|
+------------------+
State Chart Transitions:
Booking Started: The system waits for the user to enter the booking details.
Payment Pending: Once details are entered, the system waits for the payment.
Payment Successful: On successful payment, the ticket is confirmed and the booking is
completed.
Payment Failed: On failed payment, the system notifies the user to retry or cancel the booking.
Ticket Booked: The ticket is booked and a confirmation is sent.
Ticket Cancelled: If the user cancels the ticket, the system processes refunds and updates the
status.
Booking Expired: If the booking is not completed within the specified time, it expires.
Booking Completed: The final state of the ticket after all processes are successfully completed.
Key Theoretical Principles:
Event-driven State Transitions: Transitions in the State Chart Diagram occur based on specific
events, such as payment success or failure.
Guard Conditions: For transitions to happen (e.g., from "Payment Pending" to "Payment
Successful"), the conditions must be met (e.g., [Payment Successful]).
State Lifecycle: The diagram effectively models the lifecycle of a ticket, from the booking
initiation to completion or cancellation.
Concurrency Management: In cases like payment confirmation and database update, parallel
processing is used.
CONCLUSION:
The State Chart Diagram for the Railway Reservation System provides a clear visual
representation of how the ticket changes states from Booking Started to Booking Completed. By
illustrating the various states such as Payment Pending, Payment Successful, Ticket Booked, and
others, this diagram helps in understanding the dynamic behavior of the system. It also highlights
the importance of event-driven transitions and guard conditions in managing the state of the
system, ensuring a smooth booking and cancellation process.
