sds
DESCRIPTION
Software designTRANSCRIPT
E-GAS SEWASoftware Design SpecificationVersion: 1.2Date Created: 2003.10.24SignaturesDateRevisionApproved By
List of Contributors
NameInitialsOrganizationE-Mail
Nikhil BandodkarNBSeminole [email protected]
Jidong LongJLSeminole [email protected]
Chuck WeddleCWSeminole [email protected]
Change History
RevisionDateDescription
1.02003.10.24Initial Revision
1.12003.10.30Second Revision
1.22003.11.07Third Revision
Preface
This document presents the Software Design Specification for the E-gas Sewa project. The major sections of the document address the system decomposition by module, concurrent process, and data entity. The system dependencies are also described.Section 2, Decomposition Description, gives a view of the whole system design including concurrent processes and data entities that are common amongst all system modules.This discussion includes a UML Class Diagram that depicts the entire system.
Section 4, Interface Description, goes into detail about the user interface for each module of the E-Gas Sewa software. This is followed by an important discussion of the processes implemented in logic for each module of the system.
Section 5, Detailed Design, extends the design discussion found in Section 2 and describes the design for each system module in more detail. A UML Class diagram is included for each module design discussion. This is followed by a description of the data requirements for each module and the design of those data elements.
Table of Contents11Introduction
11.1Purpose
11.2Scope
11.3Definitions and Acronyms
11.4References
22Decomposition Description
22.1Module Decomposition
22.2Concurrent Process Decomposition
22.3Data Decomposition
43Dependency Description
43.1Inter-module Dependencies
43.1.1Independent Modules
43.1.2Dependent Modules
43.2Inter-process Dependencies
43.3Data Dependencies
64Interface Description
64.1Module Interface
64.1.1E-Gas Booking Module Description
74.1.2E-Gas Authentication Module Description
84.1.3E-Gas Registration Module Description
104.1.4E-Gas Payment Module Description
104.1.5E-Gas Management Module Description
114.2Process Interface
114.2. E-Gas Booking Process Description
114.2.2 E-Gas Registration Process Description
114.2.3 E-Gas Authentication Process Description
124.2.4 E-Gas Payment Process Description
124.2.5 E-Gas Management Process Description
145Detailed Design
145.1Module Detailed Design
145.1.1E-Gas Provider
155.1.2E-Gas Booking Module Detailed Design
155.1.3E-Gas Registration Module Detailed Design
165.1.4E-Gas Authentication Module Detailed Design
175.1.5E-Gas Payment Module Detailed Design
185.1.6E-Gas Management Module Detailed Design
20Appendix A E-Gas Class Diagram
List of Figures5Figure 1, Data Flow Diagram
6Figure 2, Booking Module, E-Gas Config Menu
6Figure 3, Booking Module, E-Gas Vendor Name
7Figure 4, Booking Module, E-Gas Vendor Information
7Figure 5, Booking Module, E-Gas Sender Information
8Figure 6, Vendor Module, Contacting Vendor
8Figure 7, Vendor Module, Stamp Purchase Success
8Figure 8, Manager Module, Manager Menu
9Figure 9, Manager Module, Sending Booking
9Figure 10, Manager Module, Receiving Booking
10Figure 11, Sending E-Mail Module, E-Gas Menu
10Figure 12, Receiving E-Mail, E-Mail with E-Gass Indicator
11Figure 13, Receiving E-Mail, E-Gas Options
14Figure 14, E-Gas Provider Class Diagram
15Figure 15, E-Gas Booking Module Class Diagram
15Figure 16, E-Gas Vendor Module Class Diagram
16Figure 17, E-Gas Authentication Module Class Diagram
17Figure 18, E-Gas Manager Module Class Diagram
18Figure 19, E-Gas Sending E-Mail Module Class Diagram
19Figure 20, E-Gas Receiving E-Mail Module Class Diagram
List of Tables
1Table of Definitions, Acronyms, and Abbreviations
1Table of References
1 Introduction1.1 PurposeThe purpose of the Software Design Specification is to describe the specific design of the E-Gas software by Seminole Software. The design specification includes an overview of the design along with software module decomposition.
This document provides a detailed description of each software modules design. For each module, a user interface design and detailed design is given. As well, a process description is described for each module. It is in the process description that the details of what logic will need to be implemented are given.
1.2 ScopeIt is within the scope of the Software Design Specification to describe the specific system design of the E-Gas project. This would include user interface design, object-oriented class design, process design, and data design. Any specific detail that is needed about the standards or technology used to design the software are within the scope of this document.
1.3 Definitions and Acronyms
Table of Definitions, Acronyms, and Abbreviations
Definition, Acronym, or AbbreviationDescription
SDSSoftware Design Specification.
1.4 References
Table of References
ReferencesDescription
Software Development PlanThe Software Development Plan from the E-Gas project was referenced.
Software Requirements SpecificationThe Software Requirements Specification from the E-Gas project was referenced.
2 Decomposition Description
2.1 Module Decomposition
The E-Gas Sewa Software has been decomposed into the following modules.
E-Gas Booking Module: This module collects data from the user to be used for establishing communication with the vendor.
E-Gas Authentication Module: This module authenticates the information received by the E-gas client.
E-Gas Management Module: This module collects information (data) regarding the various operations involved in the booking and cancellation of gas.
E-Gas Registration: This module enables the user to register in the E-Gas sewa software. E-Gas Payment: This module deals with the cash transactions involved in the whole process.
2.2 Concurrent Process Decomposition
The E-Gas Project consists of two major components, the E-Gas Client and the Vendor. This team shall design the E-Gas Client. The design of the vendor software is out of the scope of the current teams task.
A complete view of the project suggests that there are two processes, the vendor process and the E-Gas client process. The E-Mail client process communicates with the vendor process to obtain the required results. These two processes run concurrently and only exchange information when the E-Gas client processes a request.
2.3 Data Decomposition
The following are the major data components involved :E-Gas booking Information: This is a database that contains the following data items;
Customer details and the Quantity of the gas required Customer Details: This refers to the various details that are associated with the various users of the E-Gas Sewa software. Quantity: This refers to the quantity of the gas that is to be booked.
3 Dependency Description
3.1 Inter-module Dependencies
3.1.1 Independent ModulesThe following modules are independent and do not rely on any other modules to initiate them or to provide data. E-Gas Booking Module. E-Gas Management Module.
3.1.2 Dependent Modules
The following modules are dependent on one another for their functioning.
E-Gas Registration Module: This is the module that allows a new user to register into the system.It interacts with the authentication module when required E-Gas Authentication Module: This module is executed when the various details provided by the user needs to get verified.
E-Gas Payment module: This module depends on the E-Gas Booking module for its successful completion.
3.2 Inter-process Dependencies
As described earlier the two main processes are the E-Gas client process and the Vendor process. The gas client process depends on the vendor process only for obtaining gas. This is the only dependency between the two processes. Please reference Appendix A for a full class diagram of the E-Gas classes.3.3 Data Dependencies
The following Data Flow Diagram shows the data dependencies between the various entities and modules.
Figure 1, Data Flow Diagram
4 Interface Description
4.1 Module Interface
4.1.1 E-Gas Login Module Description4.1.1.1 User Interface Design
4.1.2 E-Gas Module Description
4.1.2.1 User Interface Design4.1.2.2 Description
The following figures show the user interfaces for this module. The interfaces are non interactive and only show the status of the stamp purchase process from the vendor.
4.1.3 E-Gas Manager Module Description
4.1.3.1 User Interface Design
4.1.3.2 Description
The User Interfaces allow the user to define actions to be performed by the software to automate the various transactions involved with booking and cancellation of gas. The user interface asks for actions to be performed by the system. This UI provides the user with various options. Based on the option selected by the user the system performs the various operations as and when required.
4.1.4 E-Gas Sending E-Mail Module Description
4.1.4.1 User Interface Design
Figure 11, Sending E-Mail Module, E-Gas Menu
4.1.4.2 Description
If the user has not already configured the E-Gas Manager, the circled area will allow the user to select various stamp options. Alternatively it also allows the user to send unstamped email if a stamp is not already available. However if the E-Gas Manager has been configured then the circled list box will highlight the default options.
4.1.5 E-Gas Receiving E-Mail Module Description4.1.5.1 User Interface Design
Figure 12, Receiving E-Mail, E-Mail with E-Gass Indicator
Figure 13, Receiving E-Mail, E-Gas Options
4.1.5.2 Description
The UI for this module is limited to allow the user to reject the stamp or add it to his stamp book as shown in figure 13. By default the stamp will be added to the stamp book.
4.2 Process Interface
4.2.1 E-Gas Booking Process Description
In Booking module their four major functions which include booking of gas or accessories, cancellation of gas or accessories and status confirmation about the gas or accessories by the dealer. In Booking module there is only one major function provided to dealer that is of status confirmation.
The customer has to options whether to cancel an already made booking or make a new booking. Whichever choice customer makes it is saved in the data store so as know that how many bookings and cancelations have been made in total by that particular customer and a grand total of both by adding no.of bookings and subtracting no.of cancellations made are told to the dealer so that he/she can keep a track on the bookings made under him. Once a customer chooses an option they enter the quantity which is required by them which is further deducted from the data storage of accessories and gas so keep track on no.of gas cylinders and accessories left with the dealer.
The dealer confirms the bookings and cancellations made under him/her and updates the data store of status so that customer can know about confirmation in future.
In Booking module major details required are the customer details and the quantity required by customer so as to make a booking and deliver the made booking to correct customer at correct address.
Booking module is an important module required in E-Gas-Sewa along with the rest of the modules.
4.2.2 E-Gas Registration/Authentication Process Description
Registration and Authentication is another key module. .Authentication is for those customers and dealers who have already given their details. Registration is for the new customer and dealers who have not given their details like adhaar card no. , address, mobile no. In Authentication the email-id and password from the user is taken and then system will verify that the password is correct or not .If the password and email id is correct then the user is allowed to proceed further otherwise user will have to re-enter the email-id and password .In registration there is signup option for new user where-in the user gets to fill all the details in the form that is required.The system will check whether all the details in the form is valid or not .If all the filled details are correct then form will be submitted and user can proceed further and can do Booking, management cancelling the booking and other features. If the form details are not correct then users have to check the given details and correct the mistake he/she has done to fill the form. It makes the delivery easier and for booking the user need not stand in office for hours for booking.4.2.3 E-Gas Payment Process Description
With the customers providing in their details while the time of registration they are provided with a number of options such as COD or net banking or paying through the account linked while booking in of the gas .Since the activity involves taking in the credentials of a user the payment process online is usually very secure by the services provided through many security providers. This encourages users to pay money online without any hesitation.
Therefore after completing all the preliminary actions and thereby becoming authenticated users of the site E-gas Sewa portal allows the users to pay money either through cash i.e. at the time of the delivery or through E-cash i.e. credit cards debit cards etc.
Our segment of subsidised and non-subsidised cylinders helps in setting up of the final price for the cylinder to be brought in by the user.
After completing the payment process the procedure of booking a gas cylinder is complete thereby giving the customers the satisfaction of having them receive their cylinders as soon as possible.4.2.4 E-Gas Management Process Description
The primary objective of the E-Gas Management module is to collect information to automate the process of E-Gas procedure without persistent user interaction.It deals with the various managerial tasks that is involved in the whole process of E-Gas and the various actions that are taken as and when required.5 Detailed Design5.1 Module Detailed Design
5.1.1 E-Gas Sewa5.1.1.1 Design
Figure 14, E-Gas Sewa Class Diagram
5.1.1.2 Design Description
The EStampProvider class deserves special attention because it is the central class to all of the other EStamp classes. As shown in the UML in the figure above, the Pooka class, which contains the main() method that is immediately called on Pooka application startup, instantiates the one and only EStampProvider class used in the system.
The EStampProvider class has a containment relationship with three other important EStamp Classes; VendorBooking, EStampAuthenticator, and EStampManger. A description of each one of these classes follows. Singleton instances of these three classes make up the most important attributes to the EStampProvider class. Please notice that these are shown as attributes in the EStampProvider UML class definition in the figure above.
One particular public method exposed on EStampProvider that needs explanation is getAvailableVendor(). This method is used to return to the caller an EStampVendor, which is described below, that will use the VendorBooking object to either get the vendor that the user has specified as a default or possibly a vendor of a specific name.5.1.2 E-Gas Booking Module Detailed Design5.1.2.1 Design
Figure 15, E-Gas Booking module design5.1.2.2 Design DescriptionThe EStampProvider constructor will instantiate one instance of the VendorBooking class. The VendorBooking class is a manager of EStampVendor objects. Internally, VendorBooking handles persisting EStampVendors and retrieving already configured EStampVendors in persistent storage.
Some of the more important methods exposed by VendorBooking are getDefaultVendor() and addVendor(). The method getDefaultVendor() will return to the caller an EStampVendor that is the default vendor specified by the user in the EStamp Config UI dialog. addVendor() takes as an argument a new EStampVendor that is to be persisted. The main caller of addVendor() is the EStamp Config UI dialog but it just as easily be called from any other part of the system if other ways to configure vendors became available.
5.1.3 E-Gas Authentication/Registration Module Detailed Design5.1.3.1 Design
Figure 16, E-Gas Authentication/Registration Module Design5.1.3.2 Design Description
The EStampVendor class is instantiated when needed. As mention in the section above, the VendorBooking class handles the processing of the EStampVendor objects during system runtime.
The EStampVendor contains the vendor name, URL, and PW as private attributes as well as the sender email and credit card information. With this information, a vendor can be uniquely identified and used for purchasing a stamp. The methods exposed by this class do not warrant explanation, for they are all simply mutators and accessors for the private attributes.
5.1.4 E-Gas Payment Module Detailed Design
5.1.4.1 Design
Figure 17, E-Gas Payment Module Design5.1.4.2 Design Description
The EStampProvider constructor will instantiate one instance of the EStampAuthenticator class. The EStampAuthenticator class authenticates EStamps as the name implies. Internally, EStampAuthenticator handles the decrypting the EStamp with the vendors public key.
Some of the more important method exposed by EStampAuthenticator is authenticate(). Again, as the name implies, this method with authenticate the EStamp passed in as a method parameter. The caller will examine the Boolean result returned from authenticate() as to whether this EStamp was valid or not.Appendix A EStamp Class Diagram