The engineering require to complete the software system (e.g. "Railway Ticket Reservation System") is System Modeling & Architecture Design. For those who want to see sample that what are the steps to complete a software.

1. Railway Ticket Reservation System
System Modeling
&
Architecture Design
Group # 6
Arsalan Ali Daim BSCS14068
Hafiz M. Abdul Wajid BSCS14054
Azhar Ali BSCS14058
Danish Javed BSCS14028

2. Requirement Elicitation Techniques
We are using Use-cases technique for requirement elicitation. The reason is that as we are using incremental
approach so with the use of this technique we can easily find out working functionality of different modules
one by one. On the other hand, required input and expected output can also be easily illustrated by use-
cases. Other than that, we will also be using ethnography to observe already implemented system of railway
reservation. This will help a lot to find out actual requirements for our system. For this purpose, we visit
the railway website where the system to be replaced has been deployed and explore our relevant sections.
Long story short, these two techniques have proved very useful so far.
Other than that, we will also be using ethnography to observe already implemented system of railway
reservation. This will help a lot to find out actual requirements for our system. For this purpose, we visit
the railway website where the system to be replaced has been deployed and explore our relevant sections.
Long story short, these two techniques have proved very useful so far.
System Modeling
We are using two main system models to meet the requirements of our project. There system models are as
follows
▪ Interaction Modeling
▪ Structural Modeling
Interaction Modeling:
Interaction model is very useful Railway Reservation System. The reason is that the sub-model techniques
like use-case diagrams, sequential diagrams are very suitable for our software. The software is fully based
on different use cases, which will be mention later. When a person come to the railway station and ask for
his requirement then there are some actions done by the operator/Admin that will define our uses
cases.Listing down those use cases contains:
When a passenger come to station and can ask for:
1. Admin Asks destination and searches if train is avaialable
2. Inquirey for available seat
3. View time schedule
4. Gives information to admin for booking and admin enters his information to System
5. Admin asks for destination and system tells fare amount by entering starting and ending point
6. Passenger makes payment
7. Admin marks in software that amount has received
8. Ticket issued
9. Print ticket
In case of cancelation of ticket, the use cases could be:
1. Asks passenger’s information and search if he is registered
2. If record found then cancel the ticket
3. Seat will be automatically set as available
4. Refund amount
Also, the use-cases have been mentioned diagrammatically. With the help of this diagram we are able to
see that what are the services our system provides and what kind of function it will perform. The reasons

3. behind the use of use case modeling in our project are, as mentioned in use-cases when passengers come to
the railway station for ticket reservation according to their destination, available train, and desired seat in
the different coaches of the train, all of these cases vary for each individual passenger. Now not all
passengers come to the stations to reserve a ticket, but some of them come there to cancel their reserved
tickets and then they get the given amount for the seat in return (refunding amount). Therefore, we used
Interaction Modeling to see all the use-cases that will cover all of the different scenarios.
Fig. 1: Use-Case Diagram for Booking and Cancelling tickets
Similarly, the interaction model also defined by the sequence diagram which tells the life of each system
components with a specific time duration. The time has been divided into the request being interchanging
between the user and system. For our system, the sequence diagram below explains that how the passenger
come to the operator and how the information goes to the database and then in case of seats availability, the
admin collects the fare amount which is being told by the system. Then, admin enters the amount accepted
and system of railway reservation save the information to the database and issued the ticket. Here you can

4. see that the ‘sequential diagrams’ is easily demonstrating the detailed communication between different
modules of our project. This is also showing almost complete workflow of our required system.
Fig. 2: Sequence Diagram for Booking Ticket.
Structural model:
As our software is fully related to the object-oriented programming so we are using the structural modeling.
With the help of this we are able to see structure of our whole software modules. We have made different
classes and their interaction using the concept of OOP. Well a project with the implementation of fully
object-oriented model consists of class diagrams. So, we made classes and then made class diagrams. These
class diagrams and their attributes are shown in a particular manner. And these classes have somewhat
association (relationship) with each other according to basic functionality of our system. Another major
aspect/part of Structural model is Generalization. In our case, we generalized some attributes to reduce
redundancy but this is on very small scale in our project.

5. Fig. 3: Classes for Railway Ticket Reservation System.
Above classes has relations with each other. Because of object orientation in our project classes have
relation of associativity and aggregation. These relation specifications produce simplicity for us to manage
and understand the software development process.
Now, by using these classes we have made class diagrams in which all the relations are mentioned with the
help of their representing symbols. See below the class diagram for above classes.

6. Fig. 4: Class Diagram showing the relation between all the classes.
System Architecture Design
Pipe and Filter architecture:
As our model is sequential. So, we are using pipe and filter architecture for our system. In railway
reservation system, at every step there is a condition needed. If something occurs then do next step.
Similarly, if train is available and seat is available then passenger ask for entry. When he has been asked
for his information for booking then he has to pay fare for ticket issuing. If he pays for it then system issued
the ticket.
Pros:
▪ Very understandable transformation of functional requirements.
▪ We can easily see how our transactions are transferring from one end to another.
▪ Input and Output workflow can easily be analyzed in our case.
Cons:
▪ For displaying info at screen, we have to follow some specific format which will increase the time
required for development.

7. ▪ For communication between different functional components, we have to keep check on input types
being received so that there is no problem because there are large number of conversions e.g. int to str
or vice versa and etc. Therefore, parsing is required for this purpose.
Fig. 5: Pipe and Filter Architecture for Railway Reservation System
Layered Architecture:
This architecture is properly fits in our system. As there are divisions in this architecture, similarly our
model is also having divisions. Showing the model by picture we can get more understanding about it.
Pros:
It is perfectly fitting in our case as we are dealing with different layer. Some of major pros are as follows:
▪ It fulfills our nonfunctional requirement (Security) as authentication and authorization on each level is
required in our case for each transaction.
▪ It enhances and supports incremental approach as we can add another layer for the new requirements.
▪ Its hierarchical structure made us easy to write code according to OOP.
Cons:
▪ Performance can be compromised because of multiple levels of interpretation of a service request as it
is processed at each layer. So, there is probability that transaction time will increase here.
▪ Dependency issues will increase as layers are communicating with each other so single failure or one
corrupt layer can crash our system instantly.

8. Fig. 6: Layered Architecture of Railway Reservation System.
Client - Server Architecture:
This architecture is properly fits in our system. As there are divisions in this architecture, similarly our
model is also having divisions. Showing the model by picture we can get more understanding about it.
Pros:
▪ easy to manage
▪ security
Cons:
▪ Server may not be able to handle too much requests that may cause server to down.
▪ Since its centralized if a critical server fails, client requests are not accomplished.

9. Fig. 7: Client Server Architecture of Railway Reservation System
Repository architecture
This is architecture will not be implemented in our case the reason is that we are dealing
with a system that is working on only in one place, in short, we don’t have to share large
data from one system to another system according to our requirements. That is why
repository architecture is not useful for us.
Model view Controller:
Similarly, this architecture model is also not fitting in our project. Because we can’t make
a separate view and controller so that we can view and then update our software. Reason
is very simple, we are using incremental approach so we will go module by module and if
something goes wrong or some up gradations are required then we simple go to source
code and change them, so there is no role of controller here.