8/2/2019 Documentation Final1
1/56
THESPEED CASHSYSTEM
1. INTRODUCTION
1.1 OVERVIEW
The Speed Cash System is used to transfer money from one place to another within a
day. This is basically used to speed up the money transfer. The necessary information for the
money transfer from the source bank to the destination bank is sent in the form of file on
daily basis. This file contains the information like remitter details, beneficiary details and DD
(Demand Draft) details, etc.
Basically the remitter is a person who sends the money and the beneficiary is the
person who receives the money. If the remitter has already an account with the bank, the
deduction at the back end should happen instead of cash dealings. Once the file is received, it
is processed and the data is put into the database. Then it is again processed and DD is
printed. The printed DD will be handed over to the concerned person.
3. ANALYSYS
3.1 SYSTEM REQUIREMENT SPECIFICATION
3.1.1 INTRODUCTION
This Project is to create an e-News and Metrics generation tool for Marketing Programs
Team. This system generates and sends a newsletter to the target groups for technicalawareness, new products, services, updates and security patches provided by ABC Company.
The system should also generate analysis reports to improve their marketing strategies.
The project has been planned to be having the view of distributed architecture, with
centralized storage of the database. The application for the storage of the data has been
1
8/2/2019 Documentation Final1
2/56
planned. Using the constructs of MS-SQL Server and all the user interfaces have been
designed using the ASP.Net technologies. The database connectivity is planned using the
SQL Connection methodology. The standards of security and data protective mechanism
have been given a big choice for proper usage. The application takes care of different
modules and their associated reports which are produced as per the applicable strategies and
standards that are put forwarded by the administrative staff.
3.1.2 EXISTING SYSTEM
Problem Definition
It is time consuming process as the user has to type the dbase commands. He has to
remember all the commands which are difficult.
It is limited to a single system.
A user who wants only to have some information has to contact the administrator
every time.
Using the MS-Access they are able to store only 2500 records only.
Project Objective
Cyber security Division undertakes the auditing of the web sites prior to hosting on the
production server. It has to perform application vulnerability assessment for the applications
on the various web sites. These audits were performed for the requests submitted by various
user groups / departments. The objective of the system is to automate the audit application
Status Monitoring Process to speed up the workflow. Application Audit Status Monitoring
System will keep track of all the websites submitted by the user group(s) and assign the audit
levels to the concerned auditors to audit the site vulnerabilities. Reminders will be sent to the
concerned user groups to take necessary actions on the paused audits waiting for the
response.
2
8/2/2019 Documentation Final1
3/56
For self assessed sites/applications state web coordinator can upload report and certificate
itself, if coordination finds sites without vulnerabilities he/she can allow site clear for hosting
otherwise assignment life cycles follows.
Authentication and session management includes all aspects of handling user authentication
and managing active sessions. Authentication is a critical aspect of this process so, allow only
strong password, change password after some time and not allow old passwords. Various
groups to keep track of the current status of the audited application software websites
basically will use the information.
3.1.3 PROPOSED SYSTEM
The development of the new system contains the following activities, which try to automate
the entire process keeping in view of the database integration approach.
1. User friendliness is provided in the application with various controls.
2. The system makes the overall project management much easier and flexible.
3. It can be accessed over the Internet.
4. Vast amount of data can be stored.
5. There is no risk of data mismanagement at any level while the project development is
under process.
3.1.4 SCOPE
This Document plays a vital role in the development life cycle (SDLC) as it describes the
complete requirement of the system. It is meant for use by the developers and will be the
basic during testing phase. Any changes made to the requirements in the future will have to
go through formal change approval process.
The developer is responsible for:
3
8/2/2019 Documentation Final1
4/56
1) Developing the system, which meets the SRS and solving all the requirements of the
system?
2) Demonstrating the system and installing the system at client's location after the acceptance
testing is successful.
3) Submitting the required user manual describing the system interfaces to work on it and
also the documents of the system.
4) Conducting any user training that might be needed for using the system.
5) Maintaining the system for a period of one year after installation.
3.2 SOFTWARE / HARDWARE REQUIREMENTS
3.2.1 SOFTWARE REQUIREMENTS:
WINDOWS NT 4 | 2000 | 9.X | ME
Visual Studio .Net 2002 Enterprise Edition
Internet Information Server 5.0
Visual Studio .Net Framework (Minimal for Deployment)
4
8/2/2019 Documentation Final1
5/56
SQL Server 2000 Enterprise Edition
3.2.2 HARDWARE SPECIFICATIONS
PIII 500MHZ or above
128MB RAM
100MB Free Hard disk space
STD Color Monitor
Network interface card or Modem (For Remote Sources)
3.3 MODULES
The system after careful analysis has been identified to be presented with the
following modules:
The modules involved are:
1. Administration
2. Accountholder
3. Reports
5
8/2/2019 Documentation Final1
6/56
4. Authentication
3.3.1 ADMINISTRATOR
In this module the Administrator has the privileges to add information about the Bank,
Branch, transaction type , Payment Mode, Country, State, City, Location. He can search all
the info about the Accountholder, Bank etc...
3.3.2 ACCOUNTHOLDER
This is the person who is having his account in the particular bank. After entering his user
name and password he can successfully enter in his page and see his account info, personal
detail, information about the different type of transaction made by him. He can also modify
his detail and can change his password.
3.3.3 REPORTS
This module contains all the information about the reports generated by the admin based on
the particular Account holder, all request made by Account Holder.
3.3.4 AUTHENTICATION
This module contains all the information about the authenticated user. User without his
username and password cant enter into the login if he is only the authenticated user then he
can enter to his login and he can see the quotation and give the quotation for the particular
products.
3.3.5 INPUTS & OUTPUTS:
The main inputs, outputs and major functions of the system are as follows
6
8/2/2019 Documentation Final1
7/56
Inputs:
Head operator enters his or her user id and password.
Operators enter his or her user id and password.
Technicians enter his or her user id and password.
Sub technicians enter his or her user id and password.
User requests the reports.
User requests the search.
Head operator can edits the personal details and so on.
Outputs:
Head operator receives personal details. Operator receives the personal details.
Technicians receive personal and technical details.
Users receive requested reports.
Displays search result.
ACCESS CONTROL FOR DATA WHICH REQUIRE USER AUTHENTICATION
The following commands specify access control identifiers and they are typically
used to authorize and authenticate the user (command codes are shown in parentheses)
USER NAME (USER)
The user identification is that which is required by the server for access to its
file system. This command will normally be the first command transmitted by the user after
the control connections are made (some servers may require this).
PASSWORD (PASS)
7
8/2/2019 Documentation Final1
8/56
This command must be immediately preceded by the user name command, and, for
some sites, completes the user's identification for access control. Since password information is
quite sensitive, it is desirable in general to "mask" it or suppress type out.
3.3.6 GUIs
In the flexibility of the uses the interface has been developed a graphics concept in
mind, associated through a browser interface. The GUIS at the top level have been
categorized as
1. Administrative user interface
2. The operational or generic user interface
The administrative user interface concentrates on the consistent information that is
practically, part of the organizational activities and which needs proper authentication for the
data collection. The interfaces help the administrations with all the transactional states like
Data insertion, Data deletion and Date updating along with the extensive data search
capabilities.
The operational or generic user interface helps the users upon the system in
transactions through the existing data and required services. The operational user interface
also helps the ordinary users in managing their own information helps the ordinary users in
managing their own information in a customized manner as per the assisted flexibilities.
Project Instructions:
Based on the solution requirements, conceptualize the Solution Architecture.
Depict the various architectural components, show interactions and connectedness and show
internal and external elements. Discuss suitability of typical architectural types like Pipes,
Filters, Event Handlers, and Layers etc.
Identify the significant class entities and carry out class modeling.
8
8/2/2019 Documentation Final1
9/56
Carry out Detailed design of Classes, Database objects and other solution
components.
Distribute work specifications and carry out coding and testing.
3.4 FUNCTIONAL REQUIREMENTS
3.4.1 OUTPUT DESIGN
Outputs from computer systems are required primarily to communicate the results of
processing to users. They are also used to provide a permanent copy of the results for later
consultation. The various types of outputs in general are:
External Outputs, whose destination is outside the organization,.
Internal Outputs whose destination is within organization and they are the
Users main interface with the computer.
The outputs should be defined in terms of the following points:
9
8/2/2019 Documentation Final1
10/56
operational outputs whose use is purely within the computer department.
Interface outputs, which involve the user in communicating directly with
3.4.2 OUTPUT DEFINITION
Type of the output
Content of the output
Format of the output
Location of the output
Frequency of the output
Volume of the output
Sequence of the output
It is not always desirable to print or display data as it is held on a computer. It should
be decided as which form of the output is the most suitable.
For Example:
Will decimal points need to be inserted
Should leading zeros be suppressed.
Input Media:
In the next stage it is to be decided that which medium is the most appropriate for the
output. The main considerations when deciding about the output media are:
The suitability for the device to the particular application.
The need for a hard copy.
10
8/2/2019 Documentation Final1
11/56
The response time required.
The location of the users
The software and hardware available.
Keeping in view the above description the project is to have outputs mainly coming
under the category of internal outputs. The main outputs desired according to the requirement
specification are:
The outputs were needed to be generated as a hot copy and as well as queries to be
viewed on the screen. Keeping in view these outputs, the format for the output is taken from
the outputs, which are currently beeing obtained after manual processing. The standard
printer is to be used as output media for hard copies.
3.4.3 INPUT DESIGN
Input design is a part of overall system design. The main objective during the input design is
as given below:
To produce a cost-effective method of input.
To achive the highest possible level of accuracy.
To ensure that the input is acceptable and understood by the user.
INPUT STAGES:
The main input stages can be listed as below:
11
8/2/2019 Documentation Final1
12/56
Data recording
Data transcription
Data conversion
Data verification
Data control
Data transmission
Data validation
Data correction
INPUT TYPES:
It is necessary to determine the various types of inputs. Inputs can be categorized as
follows:
External inputs, which are prime inputs for the system.
Internal inputs, which are user communications with the system.
Operational, which are computer departments communications to the system?
Interactive, which are inputs entered during a dialogue.
INPUT MEDIA:
12
8/2/2019 Documentation Final1
13/56
At this stage choice has to be made about the input media. To conclude about the
input media consideration has to be given to;
Type of input
Flexibility of format
Speed
Accuracy
Verification methods
Rejection rates
Ease of correction
Storage and handling requirements
Security
Easy to use
Portability
Keeping in view the above description of the input types and input media, it can be
said that most of the inputs are of the form of internal and interactive. As
Input data is to be the directly keyed in by the user, the keyboard can be considered to be the
most suitable input device.
ERROR AVOIDANCE
At this stage care is to be taken to ensure that input data remains accurate form the
stage at which it is recorded up to the stage in which the data is accepted by the system. This
can be achieved only by means of careful control each time the data is handled.
ERROR DETECTION
13
8/2/2019 Documentation Final1
14/56
Even though every effort is make to avoid the occurrence of errors, still a small
proportion of errors is always likely to occur, these types of errors can be discovered by
using validations to check the input data.
DATA VALIDATION
Procedures are designed to detect errors in data at a lower level of detail. Data
validations have been included in the system in almost every area where there is a possibllity
for the user to commit errors. The system will not accept invalid data. Whenever an invalid
data is keyed in, the system immediately prompts the user and the user has to again key in the
data and the system will accept the data only if the data is correct. Validations have been
included where necessary.
The system is designed to be a user friendly one. In other words the system has been
designed to communicate effectively with the user. The system has been designed with pop
up menus.
USERINTERGFACE DESIGN
It is essential to consult the system users and discuss their needs while designing the
user interface:
USER INTERFACE SYSTEMS CAN BE BROADLY CLASIFIED AS:
1. User initiated interface the user is in charge, controlling the progress of the
user/computer dialogue. In the computer-initiated interface, the computer selects the next
stage in the interaction.
2. Computer initiated interfaces
In the computer initiated interfaces the computer guides the progress of the
user/computer dialogue. Information is displayed and the user response of the computer
takes action or displays further information.
USER_INITIATED INTERGFACES
User initiated interfaces fall into tow approximate classes:
14
8/2/2019 Documentation Final1
15/56
1. Command driven interfaces: In this type of interface the user inputs
commands or queries which are interpreted by the computer.
2. Forms oriented interface: The user calls up an image of the form to his/her
screen and fills in the form. The forms oriented interface is chosen because it is the best
choice.
COMPUTER-INITIATED INTERFACES
The following computer initiated interfaces were used:
1. The menu system for the user is presented with a list of alternatives and the
user chooses one; of alternatives.
2. Questions answer type dialog system where the computer asks question
and takes action based on the basis of the users reply.
Right from the start the system is going to be menu driven, the opening menu
displays the available options. Choosing one option gives another popup menu with more
options. In this way every option leads the users to data entry form where the user can key in
the data.
ERROR MESSAGE DESIGN:
The design of error messages is an important part of the user interface design. As user
is bound to commit some errors or other while designing a system the system should be
designed to be helpful by providing the user with information regarding the error he/she has
committed.
This application must be able to produce output at different modules for different
inputs.
3.5 FEASIBILITY STUDY
15
8/2/2019 Documentation Final1
16/56
Feasibility is an important phase in the software development process it enables
the developers to have an assessment of the product being developed. It refers to the
feasibility study of the product in terms of outcomes of the product, operational use and
technical support required for implementing it. Feasibility study should be performed on the
basis of various criteria and parameters. The various feasibility studies are:
Economic Feasibility
Technical Feasibility
Operational Feasibility
3.5.1 ECONOMIC FEASIBILITY
It refers to the benefits or outcomes we are deriving from the product as compared to
the total cost we are spending for developing the product. If the benefits are more or less the
same as the older system then it is not feasible to develop the product.
The product is economical feasible. The scs provides the following benefits to
mandamusOrg Name
Reduces the processing time.
Reduces the work load.
3.5.2 TECHNICAL FEASIBILITY
The system is self-explanting and does not need any entire sophisticated training. A
system has been built by concentrating on the graphical uses interface concepts, the
application can also be handled very easily with a novice uses. The overall time that a userneeds to get trained is less than 15 minutes.
The system has been added with features of menu device and button interaction
methods, which makes him the master as he starts working through the environment. As the
16
8/2/2019 Documentation Final1
17/56
software that were used as developing this application are very economical and are readily
available is the market the only time that is lost by the customer is just installation time.
3.5.3 OPERATIONAL FEASIBILITY
It refers to the feasibility of the product to be operational. Some products may work
very well at the design and implementation but many fail in the real time environment. It
introduces the study of human resources required and their technical expertise.
This product is operationally feasible as it is designed specifically for scs project
name. This provides consistent and integrated data management.
It also provides information at all levels of people.
4. DESIGN
4.1 GENERAL DEVELOPMENT METHODOLOGY
SDLC Waterfall Model
The Software Development Life Cycle is a logical systematic process used to develop
software and information systems through planning, analysis, design, implementation and support.
Through these five steps softwares are built that both satisfy a user's needs and meet a company's
expectations.
The five traditional steps to the Software Development Life Cycle are:
Planning
17
8/2/2019 Documentation Final1
18/56
This initial phase starts by defining the need. The purpose of the planning phase is to
identify clearly the nature and scope of the business opportunity or problem by performing a
preliminary investigation.
Analysis
In the analysis phase we get further information about what the users want and build more
in-depth models of what they can expect to achieve with their new system.
Design
This is when the project really starts to take form. Engineers plan out all the inputs, outputs,
interfaces, processes for the project and create the system design specification from this data.
Implementation
The implementation phase is the phase in which the customer gets to see more than just
documents describing their system. The engineers and designers construct the new system and
begin testing it and documenting it.. Then after everyone is satisfied that the system is ready they
will install the product and convert the customers existing format over to the new version. And the
customer does a final evaluation to determine if the system is working as they expected and if that
the costs and benefits are as they had planned.
Support
In this, the final phase, the team maintains the system and updates it as necessary to
keep up to date with its environment. The staff will also fix minor flaws in the program that
were not caught in the other phases. Sometime after the project reaches the support phase the
customer will decide that it is time for another upgrade of their system, which restarts the
process again.
18
8/2/2019 Documentation Final1
19/56
Fig 4.1.a. SDLC Life Cycle Model
The relationship of each stage to the others can be roughly described as a waterfall, where the
outputs from a specific stage serve as the initial inputs for the following stage.
Fig4.1.b. Waterfall Model
4.2 SYSTEM DESIGN
19
8/2/2019 Documentation Final1
20/56
Systems design is the process of defining the architecture, components, modules, interfaces, and
data for a system to satisfy specified requirements
4.2.1 DATA FLOW DIAGRAMS
A data flow diagram is graphical tool used to describe and analyze movement of data
through a system. These are the central tool and the basis from which the other components
are developed. The transformation of data from input to output, through processed, may be
described logically and independently of physical components associated with the system.
These are known as the logical data flow diagrams. The physical data flow diagrams show
the actual implements and movement of data between people, departments and workstations.
A full description of a system actually consists of a set of data flow diagrams. Using two
familiar notations Yourdon, Gane and Sarson notation develops the data flow diagrams. Each
component in a DFD is labeled with a descriptive name. Process is further identified with a
number that will be used for identification purpose. The development of DFDs is done in
several levels. Each process in lower level diagrams can be broken down into a more
detailed DFD in the next level. The lop-level diagram is often called context diagram. It
consists a single process bit, which plays vital role in studying the current system. The
process in the context level diagram is exploded into other process at the first level DFD.
The idea behind the explosion of a process into more process is that understanding at
one level of detail is exploded into greater detail at the next level. This is done until further
explosion is necessary and an adequate amount of detail is described for analyst to
understand the process.
Larry Constantine first developed the DFD as a way of expressing system
requirements in a graphical from, this lead to the modular design.
A DFD is also known as a bubble Chart has the purpose of clarifying system
requirements and identifying major transformations that will become programs in system
design. So it is the starting point of the design to the lowest level of detail. A DFD consists
of a series of bubbles joined by data flows in the system.
20
8/2/2019 Documentation Final1
21/56
DFD SYMBOLS
In the DFD, there are four symbols
1. A square defines a source (originator) or destination of system data
2. An arrow identifies data flow. It is the pipeline through which the information flows
3. A circle or a bubble represents a process that transforms incoming data flow into outgoing
data flows.
4. An open rectangle is a data store, data at rest or a temporary repository of data
Process that transforms data flow.
Source or Destination of data
Data flow
Data Store
21
8/2/2019 Documentation Final1
22/56
CONSTRUCTING A DFD
Several rules of thumb are used in drawing DFDs:
1. Process should be named and numbered for an easy reference. Each name should be
representative of the process.
2. The direction of flow is from top to bottom and from left to right. Data Traditionally flow
from source to the destination although they may flow back to the source. One way to
indicate this is to draw long flow line back to a source. An alternative way is to repeat the
source symbol as a destination. Since it is used more than once in the DFD it is marked with
a short diagonal.
3. When a process is exploded into lower level details, they are numbered.
4. The names of data stores and destinations are written in capital letters. Process and
dataflow names have the first letter of each work capitalized
A DFD typically shows the minimum contents of data store. Each data store should contain
all the data elements that flow in and out.
Questionnaires should contain all the data elements that flow in and out. Missing interfaces
redundancies and like is then accounted for often through interviews.
SAILENT FEATURES OF DFDs
1. The DFD shows flow of data, not of control loops and decision are controlled
considerations do not appear on a DFD.
2. The DFD does not indicate the time factor involved in any process whether the
dataflows take place daily, weekly, monthly or yearly.
3. The sequence of events is not brought out on the DFD.
TYPES OF DATA FLOW DIAGRAMS
1. Current Physical
22
8/2/2019 Documentation Final1
23/56
2. Current Logical
3. New Logical
4. New Physical
CURRENT PHYSICAL
In Current Physical DFD process label include the name of people or their positions or
the names of computer systems that might provide some of the overall system-processing
label includes an identification of the technology used to process the data. Similarly data
flows and data stores are often labels with the names of the actual physical media on which
data are stored such as file folders, computer files, business forms or computer tapes.
CURRENT LOGICAL
The physical aspects at the system are removed as mush as possible so that the current
system is reduced to its essence to the data and the processors that transform them regardless
of actual physical form.
NEW LOGICAL
This is exactly like a current logical model if the user were completely happy with he
user were completely happy with the functionality of the current system but had problems
with how it was implemented typically through the new logical model will differ from
current logical model while having additional functions, absolute function removal and
inefficient flows recognized.
NEW PHYSICAL
The new physical represents only the physical implementation of the new system.
RULES GOVERNING THE DFDS
PROCESS
1) No process can have only outputs.
23
8/2/2019 Documentation Final1
24/56
2) No process can have only inputs. If an object has only inputs than it must be a
sink.
3) A process has a verb phrase label.
DATA STORE
1) Data cannot move directly from one data store to another data store, a process
must move data.
2) Data cannot move directly from an outside source to a data store, a process, which
receives, must move data from the source and place the data into data store
3) A data store has a noun phrase label.
SOURCE OR SINK
The origin and /or destination of data.
1) Data cannot move direly from a source to sink it must be moved by a process
2) A source and /or sink has a noun phrase land
DATA FLOW
1) A Data Flow has only one direction of flow between symbol. It may flow in both
directions between a process and a data store to show a read before an update. The later is
usually indicated however by two separate arrows since these happen at different type.
2) A join in DFD means that exactly the same data comes from any of two or more
different processes data store or sink to a common location.
3) A data flow cannot go directly back to the same process it leads. There must be at
least one other process that handles the data flow produce some other data flow returns the
original data into the beginning process.
4) A Data flow to a data store means update (delete or change).
5) A data Flow from a data store means retrieve or use.
24
8/2/2019 Documentation Final1
25/56
A data flow has a noun phrase label more than one data flow noun phrase can appear
on a single arrow as long as all of the flows on the same arrow move together as one
package.
Login DFD
Open Login
form
Enter User
Name and
Password
Check User
Validates
Data
Login Master
User Home
PageYes Yes
No
Admin Functionalities
25
8/2/2019 Documentation Final1
26/56
Manage
Customers
1.0.2
Login Account
Details
Enter Login
Details
1.0.1
Validates
Data
Manage Bankand
Transactions1.0.3
Customers
Details
Bank D etails
Log out
Op en Fo rm()
1.0.0
Verifies
Data
ManageEmployees
1.0.4
Employee
Details
Customer Registration
Manage Customers
1.2.1
Enter Customer Id
and Name
1.2.2
Enter Bank Id
1.2.3
Enter Address
1.2.4
Validates
DataValidates
Data
Validates
Data
Enter Account Type
1.2.5
Enter User Name and
Password
1.2.5
Enter Email Id
1.2.6
Enter Min Balance
1.2.7
Customer
Details
Submit
Bank DetailsAccount
Types
Admin Employee Registration
26
8/2/2019 Documentation Final1
27/56
Manage Employees
1.4.1
Enter Emp Id andName
1.4.2
Enter Branch Id
1.4.3
Enter Address
1.4.4
Validates
DataValidates
Data
Validates
Data
Enter Date of Joining
1.4.5
Enter User Name and
Password
1.4.5
Enter Email Id
1.4.6
Enter DOB
1.4.7
Employee
Details
Submit
Bank Details
4.2.2 USE CASE DIAGRAMS
27
8/2/2019 Documentation Final1
28/56
The unified modeling language allows the software engineer to express an analysis model
using the modeling notation that is governed by a set of syntactic semantic and pragmatic
rules.
A UML system is represented using five different views that describe the system from
distinctly different perspective. Each view is defined by a set of diagram, which is as follows.
User Model View
i. This view represents the system from the users perspective.
ii. The analysis representation describes a usage scenario from the end-
users perspective.
Structural model view
In this model the data and functionality are arrived from inside the system.
This model view models the static structures.
Behavioral Model View
It represents the dynamic of behavioral as parts of the system, depicting the interactions
of collection between various structural elements described in the user model and structuralmodel view.
Implementation Model View
In this the structural and behavioral as parts of the system are represented as they are to
be built.
Environmental Model View
28
8/2/2019 Documentation Final1
29/56
In this the structural and behavioral aspects of the environment in which the system is to
be implemented are represented.
UML is specifically constructed through two different domains they are
UML Analysis modeling, which focuses on the user model and structural model views
of the system?
UML design modeling, which focuses on the behavioral modeling, implementation
modeling and environmental model views.
Use case Model
USE CASE FOR ADMIN ACTIVITIES
29
SYSTEM NAME
Use case 1
Use case 2
Use case n
ActorActor
8/2/2019 Documentation Final1
30/56
Admnstrator
Logn
Regster Customers
Manage Customers
Transactions
Reports
Search
Manage BanksLog Out
CUSTOMER ACTIVITIES
Customer
Regster
Logn
Update Profiles
Transactions
Status
Search
RequestsLog Out
30
8/2/2019 Documentation Final1
31/56
4.2.3 CLASS DIAGRAMS
31
8/2/2019 Documentation Final1
32/56
4.2.4 SEQUENCE DIAGRAMS
Sequence Diagrams Represent the objects participating the interaction horizontally and time
vertically.
SEQUENCE FOR USER LOGIN
leader : Account Holder theCheck : Check bank : Bank
giveRelaventInfo (Username , Password )
Information
validateUser ()
ConfirmYes / No
If Yes () Give Confirmation
Goes to Page with Message
If No () Give Confirmation
Give Message
SEQUENCE FOR GETTING BALANCE INFORMATION
32
8/2/2019 Documentation Final1
33/56
their : Bank leader : Account Holder account : CheckingAccount Balance Lookup : Real
Retrive Account (accountno.)
Account
getbalance ()
balance
setValue ()
balance
SEQUENCE FOR INSERTING TRANSACTION
bank : Bank theCheck : Check account : CheckingAccount
Cash Check (theCheck )
getAmount ()
amount
getBalance ()
balance
addDDTransaction (Number , Amount )
addChequeTransaction (Number , Amount )
Transaction Added
Transaction Added
Cash Information
4.2.5 COLLABORATION DIAGRAMS33
8/2/2019 Documentation Final1
34/56
User Login
User
Login
Validate
Data Base Home
1 : Login()
2 : Validate Data()
3 : Invalid()
4 : Get Back()
5 : Request()
6 : Response()
7 : Home()
34
8/2/2019 Documentation Final1
35/56
Administrator Register Customers
Administrator
Customer
Validate
Data Base
1 : Register()
2 : Validate Data()
3 : Invalid()
4 : Get Back()
5 : Storage()
Customer Transactions
35
8/2/2019 Documentation Final1
36/56
Customer
File
Account InfoData Base
Validate
1 : Send Transaction()
2 : Set the Details()
3 : Validate Account()
4 : Invalid()
5 : Invalid Account Details()
6 : Storage()
36
8/2/2019 Documentation Final1
37/56
4.2.6 ACTIVITY DIAGRAMS
ACTIVITY FOR USER LOGIN
User Enters Username and Password
User Interact with System
System Displays Error Message
Accepted
Rejected
37
8/2/2019 Documentation Final1
38/56
ACTIVITY FOR ADDING ACCOUNT HOLDER
User views all Account Holder Info
User give all the relavent Info
Click on Add Account Holder
Click on Submit and Stored in Database
ACTIVITY FOR UPDATE ACCOUNT HOLDER INFO
38
8/2/2019 Documentation Final1
39/56
User Select Account Holder ID
User Modify Required F ields
System Display Entire Account Holder Info
Click on Submit and Record is Updated in Database
ACTIVITY FOR DELETING ACCOUNT HOLDER INFO
39
8/2/2019 Documentation Final1
40/56
User Select Account Holder ID
User Delete the Required Record
System Display Entire Account Holder Info
Record is Deleted from Database
ACTIVITY FOR SEARCHING ACCOUNT HOLDER INFO
40
8/2/2019 Documentation Final1
41/56
User Select Account Holder ID
Click on Search Button for the Record
Display Relavent Data in the GridView
System Display Message
Data Retrived
Data Not Retrived
ACTIVITY FOR ADDING DD INFORMATION ON ACCOUNT HOLDER
41
8/2/2019 Documentation Final1
42/56
User views all DD Info
User give all the relavent Info for DD Transaction
Select Account Holder ID
Click on Submit and Stored in Database
Click on Add DD Info
ACTIVITY FOR ADDING CHEQUE INFORMATION ON ACCOUNT HOLDER
42
8/2/2019 Documentation Final1
43/56
User views all Cheque Info
User give all the relavent Info for Cheque Transaction
Select Account Holder ID
Click on Submit and Stored in Database
Click on Add Cheque Info
4.2.7 E-R DIAGRAMS
43
8/2/2019 Documentation Final1
44/56
The relation upon the system is structure through a conceptual ER-Diagram,
which not only specifics the existential entities but also the standard relations through which
the system exists and the cardinalities that are necessary for the system state to continue.
The entity Relationship Diagram (ERD) depicts the relationship between the data objects.
The ERD is the notation that is used to conduct the date modeling activity the attributes of
each data object noted is the ERD can be described resign a data object descriptions.
The set of primary components that are identified by the ERD are
Data object
Relationships
Attributes
Various types of indicators.
The primary purpose of the ERD is to represent data objects and their relationships.
44
8/2/2019 Documentation Final1
45/56
45
8/2/2019 Documentation Final1
46/56
4.2.8 CONTEXT DIAGRAM
4.2.9 DATA DICTIONARY:
46
Speed Cash System
Authentication
Administrator
Search
Report
Account Holder
Database
8/2/2019 Documentation Final1
47/56
Data Dictionary is a catalog a repository of elements in the system. These elements
center on data and the way they are structured to meet requirements and organizational need.
Analysis use data dictionaries for the following reasons:
To manage details of large system.
To communicate a common meaning for all system elements.
To document the features of the system.
Speed Cash System
City Details
Country Details
Location
47
8/2/2019 Documentation Final1
48/56
State Detail
Account Status Master
Account Type
Admin Login
48
8/2/2019 Documentation Final1
49/56
Bank Branch
Bank Detail
Beneficiary Detail
Branch wise Service
Credit Card
49
8/2/2019 Documentation Final1
50/56
Cust Account Detail
Login History
Logout History
50
8/2/2019 Documentation Final1
51/56
Customer Detail
Customer Security Detail
Customer Detail
Debit Card Detail
51
8/2/2019 Documentation Final1
52/56
Demand Draft
Designation Detail
Emp Master
Feed Back
52
8/2/2019 Documentation Final1
53/56
File Process
Fund Transfer Detail
Remitter
Role Master
53
8/2/2019 Documentation Final1
54/56
Service Type Detail
Trans Type Details
User Login
7. CONCLUSION
54
8/2/2019 Documentation Final1
55/56
The project has been appreciated by all the users in the organization.
It is easy to use, since it uses the GUI provided in the user dialog.
User friendly screens are provided.
The usage of software increases the efficiency, decreases the effort.
It has been efficiently employed as a Site management mechanism.
It has been thoroughly tested and implemented.
8. FUTURE SCOPE OF THE PROJECT
55
8/2/2019 Documentation Final1
56/56
As the system is scalable, more modules can be added as and when required
The database that is used in the system can be connected to the patient information
system.
It can be browser independent so that the site can be opened in any browser.
The system contents can be modified to accept new attributes for any criterion.