Brief about IRCTC Proposed System - OOAD

Topic: IRCTC
Subject: OOAD
Task: Assignment
Subject: Object Oriented Analysis and Design
Prepared by: Srinivas

REQUIREMENT ANALYSIS

Objective and scope of the Project:
   
The objective of the Project
In order to overcome the drawback of the current IRCTC website, we have tried to offer passenger a growing facility for booking tickets which is not provided by IRCTC.

The scope of the Project

• To understand the current system and implement the software with the current system.
• To execute the software without any problems or error without creating any complications.
• Automating the set.

PROPOSED SYSTEM

• The proposed system is fully computerized, making ticket booking easier and cheaper.
• It provides the user with more options for traveling.
• According to the user's trust, you can book tickets between the source and the destination by breaking the journey in two half.
• The price is calculated on the basis of the end to end distance rather than calculating for two different transaction.
• The second part of the journey should start within 48 hours of the first part of the journey. The ticket for the second part of the trip is invalid without the first part of the trip.
• A senior citizen is provided with discount only if they have valid ID proof of their age. 
• The ticket can be printed and downloaded in pdf format.

 UML DIAGRAM:

USE CASE DIAGRAMS:

CLASS DIAGRAMS:

SEQUENCE DIAGRAM:

For Registration:

For the invalid user:

For the Valid user:

For Reservation:

For Cancellation:

ACTIVITY DIAGRAM

For Registration:

For Login:

For Reservation:

For Cancellation:

GRASP PATTERN 

• GRASP defines General Responsibility Assignment Software Patterns.
• A collection of general objected‐oriented design patterns related to assigning defining objects.
• There are nine GRASP patterns, maybe some are already recognizable and some not:

1. Creator 
2. Information Expert (or just Expert) 
3. Low Coupling 
4. Controller 
5. High Cohesion 
6. Polymorphism 
7. Pure Fabrication
8. Indirection 
9. Protected Variations.

CREATOR
•    This pattern generally avoids adding the coupling to a design.
•    When creation is a complex process or varies depending upon an input, often you’ll want to create using a different class implementing the GoF pattern Concrete Factory or Abstract Factory.

INFORMATION EXPERT
•    This is a general principle and probably the most used of any GRASP pattern.
•    This generally is key to loose coupling and high cohesion, but not always so. – Imagine a case where it is better to do better handheld data to preserve a large functional segmentation and support consolidation.
•    We're fully talking about the information organized by software objects, but if there are no relevant software classes, try the domain model.

LOW COUPLING
•    The higher coupling can lead to:
– More difficulty in understanding
– Changes propagating excessively
– More obstacles to code reuse
•    Less coupling often goes into the hands with a high cohesion
•    Consider this principle with every design decision.

•   The more unbalanced the class joined to, the more concerning the connection – Example. consider a language’s ordinary library vs. a class a colleague just defined a couple days ago.

CONTROLLER

•   A controller tries to organize the work without doing too much of it itself

•   A simple example of this is that UI substances shouldn’t execute business logic; there are further classes for that.

•    The controller in the Model‐View‐Controller (MVC) architecture is effectively the same thing. – This, or its variation Model‐View‐Presenter, is frequently used in web applications

HIGH COHESION
•    Very similar to Low Coupling
– Often related (but not always)
– Should be considered in every design decision.
•    Lower cohesion almost always means:
•    Low cohesion suggests that more delegation should be used.

POLYMORPHISM
•    With respect to implementation, this usually means the use of a super (parent) class or interface – Coding to an interface is generally preferred and avoids committing to a particular class hierarchy.

PURE FABRICATION
•    In other words, getting class concepts from a good domain model or real‐life objects won’t always work out well!

•   An example of a possible pure construction class: Determined Storage – May very well not be in the domain model, May very well not map to an actual‐lifetime object – But it might be the answer to attain our goals of low coupling / high cohesion while still taking a clear accountability

INDIRECTION

•   Frequently an indirection intermediary is also a pure construction. – The Determined Storage example could very well be an indirection between a Sale class and the database

•    Goff Pattern Adapter, Bridge, Facade, Observer, and Arbitrator all accomplish it.
•    The main benefit is lower coupling.

PROTECTED VARIATIONS
•    The solution "interface" is in the general sense; But to implement the solution you often want to build an interface programming (in Java, for example)!
•    Benefits: – Easy to extend functionality at PV points – Lower coupling – Implementations can be updated without affecting clients – Reduces the impact of change
•   Similar to the concealment of open-ended theory or information (not to hide data)
•    “Novice developers tend to brittle designs, intermediate developers point to highly fancy and flexible, generalized (which is never used in any way). Expert designers choose with insights."”

Note: The above-proposed system/Assignment for OOAD has been prepared by Srinivas which I have posted here. Give your blessings to him whoever find helpful for them :)