1 OOA of Railway Ticket System Assume that domain analysis is complete and DAD is ready for reference. The analyst also has a fair knowledge of the system and the system environment. For the sake of convenience and to reduce complexity at this stage in OOA, we are ignoring certain conditions, constraints and features that the real system may have. For example, we are not considering cancellation of tickets as a requirement. We assume all passengers irrespective of their type (senior citizen, military personnel, special category passengers etc.) are the same, and therefore are charged with the same fare. We begin with the statement of requirement of the system. ü System Requirement l The passenger has a prior knowledge of the reservation and ticketing system. The passenger arrives at the railway ticket counter and interacts with the counter clerk first through an enquiry and then follows the process of form filling, tendering, payment and collecting the tickets. l accepts the ticket or leaves the counter. l seeks information on fare, train timings and availability of tickets. l can have single ticket or multiple tickets. l Journey begins on a day and will be over with one break in between. l is identified by name, age, sex and address. l Trains are identified by name and number. l No receipt is issued for money transacted. l Output of the system is ticket(s) with details. l The process is triggered through a form filled by the passenger detailing the requirements of tickets, train, date, etc. l A form is used for each train. If the journey requires use of multiple trains, separate forms are used for each train. ü Identify the Actors The actors in the system are the passenger, the counter clerk and the reservation system consisting of form processing, reservation, fare computation, ticket processing, ticket printing, collection of fare amount and posting as sub-systems. The passenger is a passive user actor who initiates the process and obtains the ticket(s), a goal of measurable value. The counter clerk is an active user actor, who triggers the system and has the role of issuing the tickets with the responsibility of collecting the correct fare amount from the passenger, which is a measurable value. Predesigned and deployed ticket reservation system at the back end is a system actor user to ensure that ticket processing is done correctly and different system statuses are updated on issuing of tickets. This actor has an active role and responsibility at the back end. ü Develop Business Process Model and Issue of Based on the system observation by the analyst, a high-level activity diagram is drawn modeling the process of reservation and issue of tickets to the passenger. The activity diagram brings everybody concerned with the system on the ground to a common understanding of the system as it functions.
2 Object Oriented Analysis (OOA) 449 Chapter 15 We use this activity diagram of the process to develop use cases, which together achieves the goal of issuing the ticket. Fig Activity Diagram of and Issue of Comes to the Counter Collects the Form & Writes Details Submits form to the Counter Clerk Clerk Enters Form Details on the Screen Validates, Verifies Availability Triggers Ticket Printing Process Prints the Form Modified Not Not Issues *We do not see this as possibility in real world. may walk out of the system Not * Triggers Fare Process, Arrives at the Fare Amount Confirms with the Collects Fare Amount Triggers Update Process Attends To Next ü Identify and Develop Use Cases In the ticket reservation systems, users are the passenger, the counter clerk and the and Ticketing System (R&T System). Take each user and identify the roles played, which would lead us to identify the roles played, which, in turn, would lead us to an identification of use case. Table 15.1 shows the result of the process of identifying the use cases. The system has three users, eight roles and eleven use cases. To illustrate the process of identifying the use cases, let us take the passenger (a user of the system). A passenger as a user may play one or more of three roles. The roles are 1. Enquiring about the availability of tickets on particular dates to a destination and the fare per ticket. The role is enquiring.
3 450 Table 15.1 Users Roles Use Cases. User Role Use case l l Enquiry l Enquire ticket availability and other details. l and ticketing l Reserve seats and berths, tickets l Cancellation l Cancel tickets l Counter clerk l Form data entry l Enter Requisition Form l Requisition processor l Process requisition for booking l Ticket processor l Process ticket to print l Data manager l Submits ticket data for updation l and l System server l Process reservation data, process ticketing system ticketing process cancellation l Update the status by date, train, etc. 2. Reserving the ticket(s) on a particular train on particular date for a destination by requisitioning through a reservation form The role is reserving and booking tickets. 3. Cancelling the tickets after issuing and payment The role is cancelling. As explained in the case of passenger, the roles are use cases. Similarly, one can probe into the roles and use cases for counter clerk and reservation and ticketing system. ü Draw Interaction Diagrams Interaction diagrams are used to show the interactions between user/actor and the system. Use case is a scenario that develops through interaction. Let us model different scenarios through interaction diagrams: l Use Case: enquiring on ticket availability 1. submits information about the date and train, and requirement of tickets to the counter clerk 2. Clerk checks the availability of tickets on the date and train. 3. Communicates the availability status to the passenger. 4. If, the passenger proceeds to book the ticket through a requisition form. 5. If not, the passenger changes the date or train and requests availability. 6. Steps 2 to 4 are repeated. Figure 15.4 shows the steps in the activity diagrams of use case enquiry to issue of.
4 Object Oriented Analysis (OOA) 451 Chapter 15 Fig Enquiry to Issue of Tells Date Train and Data Entered into R&T System R&T Checks Availability Not Available Puts New Date and Train Exits Available Fills Requisition Form R&T Processes the Form Prints Issued and Fare Amount Collected Let us draw use case scenarios in use case diagrams for actor passenger. l Use Case enquiry: Fig Here use case goal is to convey the ticket availability status to the passenger on the requested date and train. If the status is available, the passenger proceeds to book the ticket or may leave the counter. If the status is not available, the passenger may leave the counter or seek availability for a new date or new train.
5 452 Fig Use Case Enquiry Enquiries on Availability Enters Requested Data in R&T System Counter Clerk R&T System to Check Informs the Status on Availability l Use Case: reservation and ticketing: Fig Fig Use Case: and Ticketing Writes Requisition Form & Submits Form Data Entered Form Processed for & Ticketing R&T System Counter Clerk Triggers Ticket Printing Collects Fare Amount and Issues Ticket Updates R&T Ticket Status Steps involved in this use case are: 1. writes reservation requisition form. 2. Submits to the counter clerk. 3. Counter clerk calls Form screen. 4. Counter clerk enters form data. 5. Triggers R and T processing. 6. On processing, triggers ticket printing. 7. Issues ticket to passenger. 8. Update the system status. So far we have completed two of the most common and frequently used use cases, i.e. enquiry and reservation and ticketing. The following use cases can be modeled on similar lines. l Cancellation l Process reservation data
7 454 reduced number of tickets and so on. Amongst five recommended processes of analysis, use case driven analysis for ascertaining system requirement is considered best as it considers users perspective of the system. When the system is modeled into different case scenarios it not only goes down to the level of function and features, but also reveals relationships and behaviours amongst different system components. Each use case scenario is an instance in the system that has clarity regarding goals and how they are to be achieved. The system can be decomposed from major use case at higher level going down to lowest level. This means that lower level use case scenarios together build the major scenario. In use case driven analysis, so far we have only understood in addition to domain knowledge. l System scope (enquiry, reservation, ticketing and cancellation) l System players (users, actors) l Major functions and processes based as use case scenarios. l Some idea on packaging system components for deployment. l System requirements at functional and process level. In short, so far in OOA, we have reached to some extent a situation in which the requirement analysis made so far can be put into a formal RDD document. We still have not reached the specifications level. This is possible when we go further, identifying classes, their relationship, attributes and methods. Use case driven analysis, displayed in use case models, is a basis for moving into the step of identifying classes and designing classes.
FDD Process #1: Develop an Overall Model A initial project-wide activity with domain and development members under the guidance of an experienced object modeller in the role of Chief Architect. A high-level
BPMN by example Bizagi Suite Recruitment and Selection 1 Table of Contents Scope... 2 BPMN 2.0 Business Process Modeling Notation... 2 Why Is It Important To Model With Bpmn?... 2 Introduction to BPMN...
Microsoft Axapta Inventory Closing White Paper Microsoft Axapta 3.0 and Service Packs Version: Second edition Published: May, 2005 CONFIDENTIAL DRAFT INTERNAL USE ONLY Contents Introduction...1 Inventory
Transforming software and systems delivery White paper May 2008 Tips for writing good use cases. James Heumann, Requirements Evangelist, IBM Rational Software Page 2 Contents 2 Introduction 2 Understanding
ETSO Modelling Methodology for the Automation of Data Interchange of Business Processes (EMM) Version : 1 Release : 4 Version 1 Release 4 04 December 2003 Page 1/19 Revision History Version Release Date
CODE OF PRACTICE On Safety Management Occupational Safety and Health Branch Labour Department CODE OF PRACTICE ON SAFETY MANAGEMENT 1 This Code of Practice is prepared by the Occupational Safety and Health
Function Points Analysis Training Course Instructor: David Longstreet David@SoftwareMetrics.Com www.softwaremetrics.com 816.739.4058 Page 1 www.softwaremetrics.com Longstreet Consulting Inc Table of Contents
Audit Manual PART TWO SYSTEM BASED AUDIT Table of content 1. Introduction...3 2. Systems based audit...4 2.1. Preparing for & planning the audit assignment...5 2.2. Ascertaining and recording the system...7
Revenue Management Second Edition A Technology Primer Developed by the American Hotel & Lodging Association s Technology and E-Business Committee Funded by the American Hotel & Lodging Educational Foundation
MPA_C08.qxd 07/01/2009 03:51PM Page 140 CHAPTER 08 L Customer Order Management ogistics in manufacturing companies is primarily concerned with controlling the flow of materials and the consumption of resources
HP Performance Engineering Best Practices Series for Performance Engineers and Managers Performance Monitoring Best Practices Document Release Date: 201 Software Release Date: 2014 Legal Notices Warranty
Table of Contents THE MASTERY LEARNING MANUAL CHAPTER 1 INTRODUCTION TO MASTERY LEARNING Introduction by Carla Ford 1 Perspective on Training: Mastery Learning in the Elementary School 2 CHAPTER 2 AN OVERVIEW
Greenshades Garnishments Product Guide and FAQ Greenshades Software Support Team email@example.com 1-888-255-3815 1 Table of Contents Table of Contents... 2 General Overview... 3 About this Guide...
SECTION 1: DEVELOPMENT POCESSES 1.1 PEFOMANCE MEASUEMENT POCESS 1.1 Performance Measurement Process Introduction Performance measures are recognized as an important element of all Total Quality Management
A GUIDE TO WRITING YOUR MASTERS DISSERTATION School of Management & Languages i Table of Contents 1. Introduction... 1 2. The Dissertation in Outline.... 2 2.1. Aims of the Dissertation... 2 2.2. Dissertation
Process Modeling Notations and Workflow Patterns Stephen A. White, IBM Corp., United States ABSTRACT The research work of Wil van der Aalst, Arthur ter Hofstede, Bartek Kiepuszewski, and Alistair Barros
Guvnor User Guide For users and administrators of Guvnor Version 5.4.0.Final by The JBoss Drools team [http://www.jboss.org/drools/team.html] 1. Introduction... 1 1.1. What is a Business Rules Manager?...
Requirements Eng (2001) 6:97 115 ß 2001 Springer-Verlag London Limited Requirements Engineering A Framework for Integrating Non-Functional Requirements into Conceptual Models Luiz Marcio Cysneiros, Julio
Joint UNECE/Eurostat/OECD Work Session on Statistical Metadata (METIS) Generic Statistical Business Process Model Version 4.0 April 2009 Prepared by the UNECE Secretariat 1 I. Background 1. The Joint UNECE
Page 1 Software Requirements Specification I. Table of Contents I. TABLE OF CONTENTS... 1 II. GRAPHICAL NOTATIONS USED... 2 1.1 GOALS AND OBJECTIVES... 3 1.2 SYSTEM STATEMENT OF SCOPE... 3 1.2.1 General
1 Australian Government Information Management Office AGAF guide to authorisation and access management Contents 1 Summary... 4 Implementing layered permissions enforcement... 4 Addressing varying user