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
