c# program by keith zimunya
TRANSCRIPT
1
Department Of Business Information Systems
BIS 3642: IS Project
MOBILE STORE MANAGEMENT SYSTEM
For
MOBI AFRICA STORES
By
ZIMUNYA Z. KEITH
STUDENT NUMBER 11625739
Supervised by Mr. T.Chibonda
YEAR 2014
2
Mobile Store Management System
Welcome to Mobi-Africa
Connecting tomorrow’s future generation…
3
Abstract
Point of Sale Management Systems are systems designed to produce customer details, sales,
details, suppliers details when needed and in aiding users in maintaining excess inventory to
allow the efficient operation and to meet excess demand in time. The main purpose of the
proposed Point of Sale Management Systems are used to provide a computerized system that
can be used to keep track of customers, sales, suppliers ,keep track of levels of stock, and
recording transactions.
4
Acknowledgement
I would like to thank the BIS Department staff for their tireless efforts and sacrificing the
time they spent namely Mr. Tutani, Mr. Madzamuse, Mr. Munyoka, Mr. Manzira and the
project supervisor Mr. Chibonda.
To my friends Courage, Tendai, Faith, Hlayisani and Thandolwenkosi. I would like to thank
them for the support throughout the course and the project.
Lastly I would like to thank R Zimunya.
5
TABLE OF CONTENTS
Chapter 1: The problem or need of the project ................................................................................. 8
1.) Introduction ................................................................................................................... 8
1.1.) Statement of problem............................................................................................................ 8
1.2.) Project Objectives ................................................................................................................. 9
1.2.1.) Aims .................................................................................................................................. 10
1.3.) Limitations and delimitations ............................................................................................ 10
1.4.) Significance of the project .......................................................................................... 11
1.5 Structure of the project ................................................................................................................ 11
Chapter 2 Review of the literature .................................................................................................... 13
2.) Introduction ......................................................................................................................... 13
2.1.) System #1 ..................................................................................................................... 14
2.2.) System #2 ..................................................................................................................... 15
2.3 System #3 .................................................................................................................................... 17
Inventory Track ............................................................................................................................... 17
2.4 PROJECT FEASIBILITY........................................................................................................... 18
2.4.1) Mitigation ..................................................................................................................... 18
2.4.2.) Risk management ........................................................................................................ 18
2.4.3.) Economic Feasibility ................................................................................................... 19
Tangible benefits .............................................................................................................................. 19
Development costs and its benefit .................................................................................................. 20
Intangible Benefits ........................................................................................................................... 20
2.4.4.) Organisational and Cultural Feasibility ............................................................................ 20
2.4.5.) Technical Feasibility ................................................................................................... 20
2.4.6.) Schedule Feasibility..................................................................................................... 20
2.4.7.) Resource Feasibility .................................................................................................... 21
2.4.8.) Conclusions and Discussions ............................................................................................ 21
Work Break down Structure ......................................................................................................... 22
3.) Chapter 3: Description Design and Implementation ........................................................... 23
3.3.1.) Use case diagram:............................................................................................................ 28
3.3.3.) Data flow diagram ....................................................................................................... 30
3.4.2.) Story board .................................................................................................................. 32
3.4.3.) UML DIAGRAM FOR MOBI AFRICA MOBILE STORE .................................. 33
6
3.4.4.) PROTOTYPE OFWINDOWS FORMS DESIGN ................................................... 34
3.5.) System interface .................................................................................................................. 37
3.5.5.) Design layout of report 1 ............................................................................................ 39
The figure 14 is an illustration of the reports that we intend to generate in the system. The
report shown is a summary of the products list. ........................................................................... 39
3.5.5.1.) Design layout of report 2 ............................................................................................ 40
3.6.3.) Design class diagram ................................................................................................... 44
3.6.4.) Database scripts........................................................................................................... 44
3.6.5.) Design of data access class .......................................................................................... 44
3.7.1.) Input integrity control ................................................................................................ 45
3.7.2.) Describe database integrity ........................................................................................ 45
3.7.6.) Security access to the system ...................................................................................... 47
3.7.7.) Data security ................................................................................................................ 47
3.8.) Implementation and prototyping ....................................................................................... 48
3.8.5.) Detailed data validation .............................................................................................. 48
3.9.) Reports ................................................................................................................................. 51
Figure 3.9.1.1 REPORT FOR CUSTOMERS ............................................................................... 52
3.10.) Backup and Recovery. ................................................................................................ 52
3.10.1.) Backup full script ........................................................................................................ 52
3.11.) Security login and password ...................................................................................... 53
3.11.) Security login and password ...................................................................................... 53
4.) CHAPTER 4: PROJECT TESTING AND EVALUATION ............................................... 53
4.2. Testing Manual ......................................................................................................................... 53
4.3.4.) Acceptance Testing ..................................................................................................... 58
4.4.) Conclusions .................................................................................................................. 58
5.) Chapter 5 Summary, conclusions and recommendations ..................................................... 60
5.2.1) Recommendations ....................................................................................................... 60
5.2.2) Developer ..................................................................................................................... 61
5.3.) Conclusions .................................................................................................................. 61
C.) Appendix C .................................................................................................................. 62
D.) Bibliography ................................................................................................................ 74
7
TABLE OF FIGURES Figure 1 WORK BREAKDOWN STRUCTURE ........................................................................................... 22
Figure 2 : NETWORK DIAGRAM ............................................................................................................. 25
Figure 3 APPLICATION DESIGN .............................................................................................................. 26
Figure 4 USE CASE DIAGRAM ................................................................................................................ 28
Figure 5 DATA FLOW DIAGRAM ............................................................................................................ 30
Figure 6 OVERALL MENU STRUCTURE .................................................................................................. 31
Figure 7 STORY BOARD ......................................................................................................................... 32
Figure 8 UML CLASS DIAGRAM ............................................................................................................. 33
Figure 9 LOGIN FORM ........................................................................................................................... 34
Figure 10 PROTOTYPE MENU FORM ..................................................................................................... 35
Figure 11 CATEGORY FORM .................................................................................................................. 35
Figure 12 LIST OF INPUT AND OUTPUT DEVICES .................................................................................. 37
Figure 13 SCHEMA AND DESIGN OF DATABASE ................................................................................... 38
Figure 14 DESIGN OF PRODUCT REPORT .............................................................................................. 39
Figure 15 DESIGN OF SUPPLIER REPORT ............................................................................................... 40
Figure 16 DATABASE SCHEMA .............................................................................................................. 41
Figure 17 DATABASE ARCHITECTURE .................................................................................................... 42
Figure 18 CLASS DIAGRAM .................................................................................................................... 44
Figure 19 BACKUP AND RECOVERY ....................................................................................................... 46
Figure 20 DESIGN FORM FOR PRODUCTS ............................................................................................. 51
Figure 21 DESIGN FOR SUPPLIERS ......................................................................................................... 51
Figure 22 report for customer .............................................................................................................. 52
Figure 23 TESTING PLAN ....................................................................................................................... 54
Figure 24 LOGIN FORM ......................................................................................................................... 55
Figure 25 LOGIN FORM SUCCESSFUL .................................................................................................... 56
Figure 26 TABLE CUSTOMER ................................................................................................................. 57
8
Chapter 1: The problem or need of the project
1.) Introduction
Inventory can be described as excess store of goods. Oftenly businesses often keep and
maintain excess inventory to allow the efficient operation and to meet excess demand in time.
The main purpose of the proposed Mobile Store Management System is to provide
computerized system that can be used to keep track of daily inventory, documenting
inventory going in and out, searching stocks and recording sales.
Although the concepts of the Mobile Store Management System have been in existence for
some time it is still merely at the stages of design. Originally most management and
transactional billing systems were run by employers using the phased out ledger based filing
systems. This of course presented a lot of problems as such data required a lot of time to
prepare, secondly no form of security or authentication as to who is allowed to view such
data. Such an application would be designed for small and medium stores who would seek to
move from the traditional pen and paper filing system to a computerized Mobile Store
Management System.
An existing cellular company Mobi Africa currently keeps their records of day to day
activities in pen format which has resulted in the business being exposed to numerous
problems and risks. Mobi Africa has been in existence for almost 5 years and for the past 2 –
3 years Mobi Africa has an experienced a large surge in sales resulting in more stock needed
and a failure to monitor stock levels and details.
1.1.) Statement of problem
Although the current system is able to cater for needs of the people the store oftenly finds it
difficult to manage sales, stock, and keep tracks of various stake holders e.g. suppliers,
employee details.
To solve the problem the owner of m store wants us to make use of a more digitalized
approach to maintain data. There is no form of backup in the event of the loss of records
because all the records pertaining to all the stock items is recorded in a counter book and this
counter book contains all the annual records on stock usage. In order to create a fully
9
functional system. We hope to store, update, and delete all data and information to ease
problems experienced by the store.
The current paper and pen approach does not offer any provisional back up structures or
methods for the stock inventory system. There is no backup in the event of the loss of records
because all the records pertaining to all the stock items is recorded in the book. An additional
problem to the current system is that the current pen and paper system has no method to
authenticate users who have access to the records. Users can easily alter data and because the
ledgers book are accessible to anyone.
The current system does not provide reports to relevant users and when needed and it lacks
the necessary feedback on the proceeds as far as distribution is concerned.
The system involves too much paperwork, which compromises its reliability due to instances
of loss or getting older and unclear.
1.2.) Project Objectives
To solve the numerous problems experienced by the system should have
I. Administration functions
II. Sales personnel functions
III. Inventory managers functions
I. Administrative functions
Login to the system and change user passwords
The ability to add new user details, alter existing and delete current user.
The ability to be able to delete inventory categories and alter prices to suit the
requirements of the business.
To be able to view the status of the inventory and enable the ability to search for an
object e.g., product or category using Product ID or Category ID
To enter the items purchased by a customer and declaring proof of payment to
customer.
To verify and check availability of stock.
To search for supplier details
10
Ability to backup database and restore it.
II. Sales personnel functions
To be able to sign in and login to the system.
To be able to view the status of the inventory and enable the ability to search for an
object e.g., product or category using Product ID or Category ID
To enter the items purchased by a customer and declaring proof of payment to
customer.
To verify and check availability of stock.
To search for supplier details
To search for customer details
III. Sales Manager functions
To be able to login into the system.
To be able to check on stock levels.
To generate reports of sales, purchases, suppliers etc.
To be able to compare stock against sales done.
Check on how the registered invoices with physical stock,
Generate sales trends and details.
1.2.1.) Aims
By computerizing the new system I hope to change the manual system
To be able to account for sales made and find products at ease.
To be able to categorize products.
Eliminating the time used to add products to the system.
Provide backup for the data that has been stored and restore function.
1.3.) Limitations and delimitations
The system might require constant updates and maintenance checks.
A lack of time required in order to conduct necessary tests and evaluations for the project.
A lack of adequate application development skills.
11
Lack of sufficient funds to be in regular contact with the users of the systems.
1.4.) Significance of the project
The proposed system will provide users with a more friendly user interface that is
less tedious, more appealing and offers users the ability to correct errors.
The proposed system will offer users the ability to save time compared to going
through numerous documents using the old filing system.
The new system compared to the old system will have less paper work because of
how centralised the data is through the use of a computerized database that will offer
the use queries and produce data report.
The pen and paper manual system will change into computerized system that will
provide users with the ability to check and verify history of transactions and monitor
inventory levels
The new system should allow information to be presented in formatted data
according to user specifications.
The proposed system should allow users to quickly reference and find information
relevant to users demand.
1.5 Structure of the project
The chapters in the documentation provided will be structured in sequential order and the
chapters will be as follows:
Chapter 1: The need for the Project
Chapter 1 will be a brief introduction to give a background of the topical area. Included in
Chapter 1 will be the aims and the objectives, statement of the problem the significance of the
topic area and limitations and delimitations upon completion.
Chapter 2: Literature Review
Chapter 2 will be based on the literature review. Literature reviews entails a thorough
examination of the body of literature pointing towards identifying the need and feasibility of
12
the proposed project. A brief description will also be include on what the proposed project is
about. Furthermore literature review will also evaluate possible systems and come up with
the most appropriate one which can identify a solution to the existing problem.
Chapter 3: Description of the project
Chapter 3 will be based on the proposed project design therefore outlining the different steps
to be taken to complete the system. Secondly Chapter 3 will provide a framework of how the
final proposed system will look like upon completion.
Chapter 4: Project Testing and Evaluation
Chapter 4 of the documentation will aim at explaining and determining effectiveness of the
entire project. It will require how the testing will be done to ensure the consistency of the
designed system.
Chapter 5: Summary, conclusion and recommendations
Chapter 5 will give an overview of the project and a summary of the procedures followed in
designing the project. Conclusions will be prepared basing on the evaluation of the project.
Recommendations will be made centering on the overall project.
13
Chapter 2 Review of the literature
2.) Introduction
A more Modern Mobile Management System should have the ability to monitor and keep
track of sales, suppliers and inventory going in and out. Such an inventory system should
have the ability to keep a record of employee activities and relevant records.
One of the main areas of concern was the inability to keep track of inventory and the time
taken by personnel to enter and extract such data. Quite oftenly mobile store owners or
employees had to search amongst their vasts amount of paper work (paper filing system) to
retrieve sales data. This presented a huge problem as so much time was taken pursuing such
work.
In order to obtain a better understanding of the processes involved in it was very important
to interview a number of stake holders involved in the whole process.
Firstly an interview was carried out with existing employees of Mobi Africa who were
employed under the sales personnel department chosen at random. Sales personnel were
mainly responsible for the point of sale transactions which mainly involved entering any sales
details of items purchased by a customer by a customer and declaring proof of payment to a
customer and searching for supplier details and previous transaction history to date.
Respondents for the interview were based according to the current sales personnel working at
Mobi Africa.
The following questions were asked:
Sales personnel
i. Define Job description?
They were responsible for the recording of customer details and also searching for any
transaction made recording any purchases made.
ii. Describe the tasks performed on a daily basis?
They dealt with point of sale and sales orders. They were also responsible for recording
of any sales details and purchases in the inventory and sales books respectively
14
Sales manager:
i. Define the Job description?
Sales managers were responsible for the sales personnel at Mobi Africa. Sales personnel were
responsible for the allocation of tasks and collection of any orders from the clients sending
them to the retailers. Sales managers were also in charge or making reports of most ordered
goods at all time and ordering of stock.
ii. Describe the current system currently used to monitor and maintain inventory
levels?
Although the current system can be described as faster from one point of view (during point
of sale transactions because of fewer product details required) the paper and pen format can
be given limited credit.
Managers found it difficult to verify the history of previous transactions and
monitoring of stock levels.
Secondly current sales complained of the current system of being outdated. If a fire
were to break out or books were stolen there is no back up for such data which could
present future problem for the business.
Thirdly the current system makes it difficult to authenticate any transactions. Any
individual can alter any data in the current books just by acquiring them.
Fourthly data is not presented in a formatted way and is oftenly very difficult to locate
supplier and client details on time.
2.1.) System #1
The following systems were reviewed
Manual inventory system: Cellular Web Stores
Inventory systems at Cellular Web Stores make use of the basic manual systems used around
most dealer ships in Thohoyandou. It involves the movement of inventory, whether the
15
purchasing or issuing out of such inventory. It is seen as a quicker means and easier means of
stock inventory control among businesses.
Advantages
Very simple and easier to use.
Cheaper to use and maintain as a form of inventory control.
The pen and paper format means that systems don’t require any maintenance or
training that might disrupt any operations at work.
When comparing Mobile Store Management System to the proposed system the proposed
system should be:
Be easy to use.
Should be easier to keep a track of inventory.
Should offer some sort of authentication assigning roles and privileges according to
the role.
Should be cheaper to make.
By making use of the current system users should be able to
Disadvantages
The manual system doesn’t offer any security making records accessible to everyone
The current manual system does not offer any means of reports and projections.
Users of such systems turn to be bored resulting in low morale and productivity.
2.2.) System #2
1 Book Barn Book Bar code inventory system
Book Barn Book Stores makes use of Bar code technology. A point of sale inventory
management system that is used to record inventory as it goes in and out of the bookshop.
The essential parts of the barcode system include the reader, labels, label printer finally the
1 www.BookBarnBook.org.uk
16
software to manage it. This swift management system updates inventory by reading the
product barcode using the barcode reader automatically deducting inventory as it goes in and
out. My proposed system
Advantages of the Bar code system
Availability of a user friendly interface that is quicker to adapt to.
A quicker method of updating standards by running barcode information of products is
displayed on screen.
Bar code scanner reduce the chances of human error. Data is scanned instead of the
user entering the data.
Bar code scanners reduce employee training time used in trying to train employees to
master the different buttons on the interface.
Barcode inventory systems can be used for multiple means because barcodes contain
information about a product that can be used for even inventory tracking.
Bar codes inventory systems will turn to improve decision making due to the face that
data obtained is more precisely and forecasts can be predicted.
Disadvantages of the Bar Code Systems
The costs that are involved in implementing inventory management systems that use bar
code scanners make it really difficult to implement such technology for small SME’S.
Any systems incurred within the system can result in the database being inconsistent
and cause problems.
Any scratched barcode on the products can cause problems in the data being read.
When comparing it to the Mobile management system to the proposed system the proposed
system should be:
Be easy to use.
Should be easier to keep a track of inventory.
Should offer some sort of authentication assigning roles and privileges according to
the role.
Should be cheaper to make.
17
By making use of the current system users should be able to
2.3 System #3
Inventory Track
InvetoryTrack makes asset tracking an easy option making use of barcode, RFID and
wireless technologies. Data collection is done through scanning a barcode. Inventory can
simply be tracked using a handheld computer. It basically helps in the management of
inventory or assets with reports.
Advantages
It has good interface boosting user participation.
It can be described as having strong security authentications measurements and
offering the facility of backing up ensure data integrity.
It makes use of report generation capabilities.
It is an aid in accuracy during data capturing.
Disadvantages
It can be described as to being a very complex and a system that requires high levels
of training.
A system that has high maintenance costs.
Can be said to be very expensive to acquire and implement.
When comparing inventory system to the proposed system the proposed system should be:
Be easy to use.
Should be easier to keep a track of inventory.
Should offer some sort of authentication assigning roles and privileges according to
the role.
Should be cheaper to make.
18
2.4 PROJECT FEASIBILITY
To reduce the risk of failure and loss of money, they should go through the different aspects
of running their business in discussions with friends and advisers before they commit funds
or try to obtain a loan. Wikipedia describes feasibility study as an evaluation and analysis of
the great potential of the proposed system based on investigation and research to support
process of decision making2. Feasibility study is an analysis and exploitation of a proposed
idea uncovering the strengths and weaknesses.
To analyse the viability of the Mobile Store Management System (MSMS), a feasibility
analysis will be carried in various sections:
Economic feasibility
Organisational and cultural feasibility
Technical feasibility
Schedule feasibility
Resource risk management
Risk feasibility
2.4.1) Mitigation
It is very important to make use of multiple security controls, username and passwords,
including the use of roles. Any backup and recovery methods should be identified to avoid
data loss.
2.4.2.) Risk management
Risk management is a very important aspect of system development process .It is very
important to identify any risks that might affect the system and identify ways to avoid them.
2 :www.wikipedia.org/wiki/Feasibility study
19
The following risks were identified and should be avoided:
Risk: If administrator passwords were to leak the entire project risks being at risk of
being tempered with. This might put the project in jeopardy leaving data and the
system vulnerable to exploitation.
Solution: Better methods of authentication and security protocols should be put in
place to avoid the project being exploited. Make use of schema, passwords etc.
Risk: Theft of hardware can interfere with the entire with the successful completion of
the project, resulting in time delays and extra costs being incurred.
Solution: Hardware used be put in a secure place and secured.
2.4.3.) Economic Feasibility
An area in the project implementation study that’s is holds the key to the success of the project.
Economic feasibility determines the cost and benefits of the proposed system. Any liable costs
incurred in the project should not surpass the benefits. We will make use of methods such as
the cost/benefit analysis which can be said to be a method used to determine the benefits that
are expected from the proposed system .The multiple costs identified include hardware,
software development and implementation.
Something identified as not economically feasible can be described as any benefits that are
found to be more than costs incurred. Feasibility study can be both tangible and intangible
benefits Tangible benefits include an increase in productivity, a low operating cost while
intangible benefits are increased employee morale or an improvement in the quality of service
provided.
Tangible benefits
Operational cost benefits
Faster data processing can result in the reduction in the time it takes to complete task.
Offering security protocols and security levels the application and the infrastructure
will reduce the risk of the system being vulnerable to any threats,
Producing a system that is easier to audit and trace.
20
Development costs and its benefit
Development costs can be described as those costs are incurred during the acquisition of the
proposed system. Costs included can be obtaining the necessary hardware and software that
can be used in the development process including any labour costs.
Intangible Benefits
Benefits can be are enjoyed by the organization as it uses the system such as:
Less omitting, duplication.
Can be used to increase the efficiency among employees and boost morale
2.4.4.) Organisational and Cultural Feasibility
Can be described as an element of feasibility analysis that determines whether the proposed
project will be accepted by people or not. It examines the probability of the project being
accepted by the sector directly affected by the change in system.
2.4.5.) Technical Feasibility
It is necessary to identify out whether acquiring the system is technically feasible. A series of
questions below is helpful in making decisions of the technical requirements of the new
System:
Are any resources available and are they of the correct quality when for maximum
system functionality?
Are the maintenance costs affordable?
Are we able to find relevant information and expertise to ensure that the system is
maintained on a regular basis?
Will the cost of the resources be satisfactory?
2.4.6.) Schedule Feasibility
Schedule feasibility can be described as the chances of the project being completed prior to due
date. The schedule feasibility will show the estimated time to complete the project. This can
change if proper measures are not taken to eliminate the risks
21
2.4.7.) Resource Feasibility
An element of feasibility analysis that determines whether the resources will enough. Question
such as:
I. What resources will be required to complete task?
II. What facilities will be required for the project to be labelled as complete?
III. Resource aspect of this system can be passed as feasible.
2.4.8.) Conclusions and Discussions
After analyzing the systems it can be concluded that the system that the proposed design should be
needs to be affordable to Small Medium Enterprise’s, easy to use, and finally uncomplicated. Thirdly
the system also has to include report generation mechanisms and has within it inherent features which
will prevent errors when using the system.
Fourthly the proposed system should provide a method of backing up the date to an external source.
The proposed system should include a user friendly interface that looks pleasing, allowing easier
navigation by users and new users should easily adopt to such a system without much training. The
proposed system should offer easier troubleshooting methods that will assist the user. Furthermore the
proposed system should be easy to maintain in order to cut down on any future maintenance costs.
Lastly security measures should also to be implemented within the system, making use of different
authentication methods in order to promote accountability and improve the control and monitoring of
inventory.
22
MOBILE STORE MANEGEMENT
SYSTEM
REQUIREMENTS
SPECIFICATION
DEVELOPMENT OF PROJECT
PLAN
REQUIREMENTS DEFINITION
DEFINE USER REQUIREMENT
S
USER REQUIREMENT
S
DEFINE SYSTEM
REQUIRMENTS
SYSTEM DESIGN
APPLICATION DESIGN
IMAGES CONTROLS
DESKTOP
APPLICATION
HOME PAGE DESIGN
CODING TESTING
TEST MANUAL
SYSTEM TESTING
UNIT TESTING
USER ACCEPTANCE
Figure 1 WORK BREAKDOWN STRUCTURE
Work Break down Structure
Work Break down Structure
In Fig 1.)
Figure 1 is an illustration of the work break down structure.
23
3.) Chapter 3: Description Design and Implementation Implementation
3.1.) Introduction
The following chapter will focus on the design aspect of the inventory management system.
The chapter will focus on the various tools and diagrams which will be used during the
design and implementation. I intend to make use of case, sequence diagrams among other
diagrammatical methods that can be used to describe the logical design and implementation
of the system. I intend to use tools such as SQL SERVER 2008 and Microsoft Visual studio
2010. The software that will run on the client side is the Microsoft Visio 2010, on this client
side users will have the ability to interact with the system based on their username and roles
in the system.
The SQL language comprise of three main parts. The first part is known as the Data
Definition Language which can allow the user to create or to modify, and update the current
database .The second part is Data Control Language, which will be responsible for the
maintenance of security of the database. It can be said to provide security feature to the
database. The third component is the Data Manipulation Language that will allow the user
with priviledges administrative priviledges to add, update, delete data and furthermore to
retrieve data in the database3. (Codd, 1970)
Furthermore I intend to make use if the SQL SERVER 2008 which will run on the database
will contain the tables that will be used together with stored procedures to communicate with
the system as a whole.
3
24
Network Design
Network requirements
The system will comprise of interconnecting computers connected to each other using Wi-Fi
and other network cables and we shall also enable internet connectivity to allow the use of
emails to be sent to suppliers and any other stakeholder.
Routers
Switches can be described as devices that are used to connect systems within a single
network while router will be used to connect to the internet and reroute the signal.
Firewalls
Are a necessity if the system is to be connected to the Internet. Firewalls can be described as
the stand point between the untrusted and trusted networks. Firewall will be situated
between the router and application servers and can be configured to filter and block
undesired services and sites that might reduce work rate or seem disruptive.
Internet connectivity
The proposed system will need access to internet connectivity to allow the company to send
emails and product updates to the customers and suppliers.
25
3.2.2.) Network diagram
The network diagram is show below in fig 2)
Figure 2 : NETWORK DIAGRAM
Figure 2 is an illustration of the Network architecture that we intend to use. It is a diagram
showing the outline of the network.
26
3.3.) Application design
The application design describes the network architecture that will be used for the current
system diagrammatically. In the application design in figure 3we will make use of the 3 tier
architecture.
Figure 3 APPLICATION DESIGN
27
The three tier architecture consists of the presentation, application logic and the .data
resource layer. The current middle layer contains the application or business logic which can
be described as a layer that provides the link to serve the client side with a user interface to
the user and the data and resource layer to request and send data back. A vast system of
architectures are used in different systems to provide the flexibility and a user friendly
atmosphere to allow the easier interaction.
Presentation layers are able to generate e data to the end user that can be used by the end user
on the end user device. The middle layer described in this system as the application and
business logic layer can be described as the layer that contains the presentation and data
resource rules containing messages of transactions. This layer is independent from the
presentation and data layers. This layer is responsible for the creation and management of the
database. At same time it is also responsible for sending required data to the presentation tier.
The third layer the data layer stores the information and contains object and relational
databases.
28
3.3.1.) Use case diagram:
The diagram below Fig 4) depicts the user and their roles in the database. The use case
diagram consists of three main users namely the sales agent the admin and the manager.
Figure 4 USE CASE DIAGRAM
29
3.3.2.) Sequence Diagrams
The sequence diagram in Figure 3.3.2 below shows an illustration of the stages that are
involved in the proposed system. It is an illustration of the different activities shown. The
diagram is an illustration of the activities between sales agent and the customer. It starts of by
the employee logging into the system and ends with the customer receiving the product...
Figure 3.3.2 SEQUENCE DIAGRAM OF THE SYSTEM.
30
3.3.3.) Data flow diagram
The Data flow diagram in Figure 5 below shows an illustration of the stages that are involved
in the proposed system. It is an illustration of the different activities shown. The diagram is
an illustration of the processes and entities when a customer wants to buy a products and ends
with the customer receiving the product.
DATA FLOW DIAGRAM
Figure 5 DATA FLOW DIAGRAM
31
3.4.1) Overall structure
Shows the overall structure of the menu hierarchy in the system.
SIGN IN
HOME
SALES MENUMANAGER
MENUBACKUP
CREATE
RESTORE
ABOUT US
INFO
VIEW
CATEGORY
CUSTOMER
EMPLOYEE
PRODUCT
SUPPLIER
ORDERS
ORDER DETAIL
PAYMENT
REPORTS
CUSTOMER
REPORT
SUPPLIER
REPORT
ORDERS
REPORT
PAYMENT
REPORT
PRODUCT
REPORT
SALES REPORT
PURCHASES REPORT
INVENTORY REPORT
SEARCH
CUSTOMER
SUPPLIERS
DETAILS
PRODUCTS
DETAILS
PAYMENTS
DETAILS
EMPLOYEES
DETAILS
ORDER
DETAILS
Figure 6 OVERALL MENU STRUCTURE
32
3.4.2.) Story board
The diagram below figure 3.4.2) is an illustration of a story board showing the events
and processes involved in users acquiring their products.
Figure 7 STORY BOARD
33
3.4.3.) UML DIAGRAM FOR MOBI AFRICA MOBILE STORE
Figure 8 UML CLASS DIAGRAM
THE DIAGRAM ABOVE FIGURE 8 IS AN ILLUSTRATION OF THE UML CLASS
DIAGRAM SHOWING THE DIFFERENT CLASSES
34
3.4.4.) PROTOTYPE OFWINDOWS FORMS DESIGN
Login form
The diagram below figure 9 depicts a prototype of the proposed system. The form below is
the login form that users will use to access the system.
Figure 9 LOGIN FORM
35
Main Menu
This Figure 10 is a Prototype of menu form is the main menu and users can navigate to the
selected view.
This Figure 11 is a Prototype of category form users can navigate to the selected view.
3.4.5.) Functionality of the user interface
Figure 3.4.3.1 Is a Prototype of Category form
Figure 10 PROTOTYPE MENU FORM
Figure 11 CATGORY FORM
36
In most cases poor user interface design is associated with low morale among users and also
results in the limited usage of such software due to its limited functionality. To gain a better
reviews from users, developers now aim at improving features concerned with the interface.
Interfaces are now made in such a way that they should be more user friendly other than
fulfilling the full functionality of the intended purpose of the system. It is therefore very
important to firstly to find out the requirements of the targeted users and try to fulfill these
requirements.
In this particular software I included multiple links and a variation of colors were used to
offer easier access and to make the system as a whole more appealing for the intended users.
On this particular system I made use of a menu tabs and buttons that offer platforms in which
the users can easily navigate through multiple pages.
By clicking the View button on the Main Menu page each form on the View button allows
users to easily search for a particular information from that category. For example the
Customers Form can also allow users to search for customer details using Customer Name or
CID. Due to the fact that such data is displayed in textboxes such data can easily be found,
edited and updated according to user priviledges of course.
Each form also offered users a quick log out button to easily navigate out of the various
forms ensuring that users avoid living such data vulnerable to external users.
37
3.5.) System interface
3.5.1) Input and output devices
The figure 3.5 is a list of input and out devices to be used in the proposed system.
Mainframe
OUTPUT
INPUT
OUTPUT
INPUT/OUTPUT
INPUT/OUTPUT DEVICE
INPUT/OUPUT
Mainframes
ROUTERDATABASE SERVER
KEYBOARD \ SCREEN PRINTER
Figure 12 LIST OF INPUT AND OUTPUT DEVICES
38
3.5.2.) Schema and Design:
Figure 13 SCHEMA AND DESIGN OF DATABASE
The diagram above fig 13 is an illustration of the schema and design that I intend to use.
39
3.5.3.) Defining data types
The table below shows the attributes used in the system
3.5.4.) Define all outputs
3.5.5.) Design layout of report 1
The figure 14 is an illustration of the reports that we intend to generate in the system. The
report shown is a summary of the products list.
Figure 14 DESIGN OF PRODUCT REPORT
Column Data type Format
Cat_id Int Nvarchar (10)
Cat_name Varchar Nvarchar
Email Nvarchar Must contain @ symbol
CID Int auto generated
O_Date Date Get date()
40
3.5.5.1.) Design layout of report 2
The Diagram figure 15 is an illustration of the supplier report listing the suppliers and the
products.
Figure 15 DESIGN OF SUPPLIER REPORT
41
3.6.) Database
3.6.1.) Database schema
The figure 3.6 illustrated below is the schema that we intend to use. I decide to
implement this schema for its easier understanding.
DATABASE SCHEMA
Figure 16 DATABASE SCHEMA
42
Database design can be described as the process of producing a model of a database we can
therefore describe it as a logical model that can storage parameters that are needed to
generate a design in a Data Definition Language .The diagram below shows the database
architecture.
External Layer- the view from the user of the database will be customized to according to
the roles in a bid to promote and improve security.
Conceptual layer - Layer describes the data that is stored in the database and the
relationships among the created data.
Internal Layer- this layer describes how data will be stored in the database.
MANAGER
GER
INTERNAL LAYER
CONCEPTUAL LAYER
ADMIN AGENT
DATABASE
Figure 17 DATABASE ARCHITECTURE
43
3.6.2.) Data types and fields
The table below is an illustration of some of the fields used in the database
Column Data type Format
Cat_id Int Nvarchar (10)
Cat_name Varchar Nvarchar
Email Nvarchar Must contain @ symbol
CID Int auto generated
O_Date Date Get date()
TABLE 3.6.2. DATA TYPES TABLE
44
3.6.3.) Design class diagram
An illustration of the class diagram showing the different classes and relations.
Figure 18 CLASS DIAGRAM
3.6.4.) Database scripts
A summary of the database scripts is shown at the end of the document in the appendix
section
3.6.5.) Design of data access class
Summary is shown in the appendix
45
3.7.1.) Input integrity control
Can be described as a set of controls put in place to ensure that the right and correct data is
recorded and can be processed accordingly.
Examples of input integrity controls include:
Email Verification: @ symbol can be used to verify users submitting email addresses. If an
employee fails to add the @ symbol when adding the customers email an error should appear
indicating the missing @ value.
Secondly the system has been configured with users, roles and passwords. Different users
have access to different roles. A good example is that of Sales employee. The sales employee
does not have access to reports that have to deal with employees. Such information is only
accessible to the manager. Such provisions are put in place to monitor the flow of data.
Furthermore upon logging in, the system itself will require login details. Failure to add such
details will result in the user failing to login.
3.7.2.) Describe database integrity
Database integrity refers to the safeguarding and meeting the required standards of
completeness, accuracy and consistency the database. This is achieved by making use of
backups, restores and the use of passwords. We see this in the current system in which input
from the user is encrypted as data of the user in entered .By doing we reduce the chances of
the database being exploited or misused leading to database inconsistency. The backup for
current system has been set to run automatically daily in case of any loss of data. Physical
backups and restores can be carried out by the administrator. Furthermore the database
administrator is in charge of adding new users and allocating roles and access to the rest of
the database.
46
3.7.3.) Backup and recovery
The figure 19 is an illustration of the backup procedure namely the Backup and restore
function that is to be supported by the system
Figure 19 BACKUP AND RECOVERY
3.7.4.) Output integrity Controls
These can be described as the controls that are used by the system to ensure that output will
get to the proper destination. Controls such as stored procedures are being used by the current
system to make sure output will make its way to the system. I have to decide to make use of
stored procedures as a method to verify output integrity. Stored procedure such as search for
supplier ID are put in place to specifically search and display the supplier ID.
3.7.5.) Integrity controls to reduce fraud
47
These can be described as those conditions that are put in place to prevent or reduce fraud in
the system. Such measures are used to prevent data from being altered or deleted without
approval for the wrong purpose.
Some of the measures put in place within the current system are the physical security
measures. This includes the different levels of security that I have assigned and put in places
by the use of assigning users and roles with passwords. These users have access to the
database but it’s restricted to a numbers of views by the level of the user.
Secondly an Audit trail has been set to monitor and trace some of the changes that take place
within the database.
3.7.6.) Security access to the system
Can be described as those measures taken to reduce any alterations or the loss of data. Due to
it being tempered without approval. In the current system the users that have been assigned
are the Manager, Administrator and Sales Personnel. Upon logging in users only have access
to the views that have been assigned by the Administrator. The user requires a password and
username to log in to the current system. Users gain access via the c# interface to login in and
access data that in also stored in the SQL Server database.
Failure in providing the right username and password will result in the failure to login.
3.7.7.) Data security
Can be described as those measures that have been set to prevent the alteration of data or
measures that are taken in case the data is altered or lost. I have made use of adding and
setting functions such as the automatic Back up that is set to back up the database at the end
of each day. Such Backups have been put in place to prevent the entire loss of data. Secondly
I have made use of multiple validation tools that the system will use in case the wrong type of
character perhaps in entered into the system. Thirdly upon logging on into the system the use
of encrypting the passwords prevents users from viewing the password each time the e user
logs in to the system. By virtue of a user logging into the system he or she is assigned
different roles that have access to different views of the database.
48
3.8.) Implementation and prototyping
3.8.) Source Code
3.8.1) Stored procedures
A summary of the source code is summarized in the appendix section at the end of the
document.
3.8.2.) Scripts to create database
Syntax used to create database and schema
CREATE DATABASE SONETAFRICA
CREATE SCHEMA SONETSTOCKS
A summary of the source code is summarized in the appendix section at the end of the
document.
3.8.5.) Detailed data validation
3.8.5.1.) Email Validation
a) When the user tries to add characters other than “@” , “.org” or “.com “ to the
system will reject this and prompt the user to resign. A message will be displayed
in the error provider.
private void richTextBoxEMAIL_Validating(object sender, CancelEventArgs e) { try { if (richTextBoxEMAIL.Text.Contains(".com")) { if (richTextBoxEMAIL.Text.Contains("@")) { } else { MessageBox.Show("An Invalid E-mail Address Has Been Found ", "Error", MessageBoxButtons.RetryCancel); }
49
} else if (richTextBoxEMAIL.Text.Contains(".org")) { if (richTextBoxEMAIL.Text.Contains("@")) { } else { MessageBox.Show("An Invalid E-mail Address Has Been Found", "Error", MessageBoxButtons.RetryCancel); } } else if (richTextBoxEMAIL.Text.Contains(".co.za")) { if (richTextBoxEMAIL.Text.Contains("@")) { } else { MessageBox.Show("An Invalid E-mail Address Has Been Found", "Error", MessageBoxButtons.RetryCancel); } } else { MessageBox.Show("Invalid E-mail Address", "Error", MessageBoxButtons.RetryCancel); } } catch (Exception ee) { MessageBox.Show(ee.Message); } }
b) How to Validate combo box to make them read-only: private void comboBoxSEARCHCID_KeyPress(object sender, KeyPressEventArgs e) { e.Handled = true; }
c) How to validate passwords:
When the user tries to add letters to the password the system will reject this and prompt
the user to reassign the password. A message will be displayed in the error provider.
private void textBoxPASSWORD_Validating(object sender, CancelEventArgs e) { if (!(textBoxPASSWORD.Text.Trim().Contains(textBoxPASSWORD.Text))) { errorProvider1.SetError(textBoxPASSWORD, "Please re-enter password"); } else { errorProvider1.SetError(textBoxPASSWORD, String.Empty);
50
} }
d) How to validate username:
When the user tries to add digits to the username the system will reject this and prompt the
user to reassign letters only. A message will be displayed in the error provider.
private void textBoxusername_KeyPress(object sender, KeyPressEventArgs e) { if (!(char.IsLetter(e.KeyChar) || char.IsControl(e.KeyChar))) { errorProvider1.SetError(textBoxusername, " Please enter username in letters only "); textBoxusername.Clear(); } else { errorProvider1.SetError(textBoxusername, String.Empty); } }
Error message Entry
51
3.9.) Reports
3.9.1.) Design
Figure 20.21 is a design report showing the product details. And fig 21 an illustration of the
summarized design for reports with details of the supplier.
Figure 20 DESIGN FORM FOR PRODUCTS
Figure 21 DESIGN FOR SUPPLIERS
52
Design of report customers
Figure 22 is an illustration of a detailed report of customer details below.
Figure 22 report for customer
Figure 3.9.1.1 REPORT FOR CUSTOMERS
3.10.) Backup and Recovery.
3.10.1.) Backup full script
An illustration of the backup full and the restore is situated in the appendix section C at the
end of the document.
3.10.2.) Backup restore script
An illustration of the backup full and the restore is situated in the appendix section C at the
end of the document
53
3.11.) Security login and password These are currently three users in the database.
Username Password Role
Admink 12345 Admin
Managers 13579 Managers
Sales employee 11111 Employee
3.11.) Security login and password
4.) CHAPTER 4: PROJECT TESTING AND
EVALUATION 4.1 Introduction
From the previous chapter, the design of the project was carried out and the interface of the
Mobile Store Management system was illustrated to show a description of how the system
works.
The current chapter is based on the testing and evaluation of the system as to make sure it
meets the requirements of the users and fulfils its sole purpose described under the aims and
objectives it meets its aims and objectives as set in the first two chapters. Furth more this
chapter will focus on determining and finding methods and ways of improving and modifying
the system.
To test and evaluate the system we look at functions of the system such as its effectiveness.
Important questions such as, “How best can we improve and maintain the effectiveness of the
system?” To ensure that the system is effective we need the system need to fulfil its sole
purpose and that can only be achieved by capturing the right data into the system to maintain
data consistency and integrity.
4.2. Testing Manual
54
The figure is an illustration too show the different steps taken when testing the products
Registered Users will be able to add their credentials and log into the system .Test plan for
user sign is displayed below
Table showing the testing plan and the input and output expected.
Table 4.2.3.1: TESTING PLAN
Input Expected Output System Output Comments
Username
Password
System will allow
user to login to into
System.
After successful
login, A message
will be displayed
informing the user
of a successful login
the user will access
the main form.
User will be logged
in
Unit testing
Integration testing
• Steps For Testing manual
Usability
Acceptance
Figure 23 TESTING PLAN
55
Failed login
Until all the
requirements are met
the User will not be
able to login.
Message will be
displayed.
Until all the
requirements are met
the User will not be
able to login
Incorrect Details in
the required fields
Until all the
requirements are met
the User will not be
able to login.
Message will be
displayed
Until all the
requirements are met
the User will not be
able to login.
Table 1
Figure 24 LOGIN FORM
56
Login form
Figure 25 LOGIN FORM SUCCESSFUL
The interface above figure 25 shows a successful login.
Test plan
Table showing test plan.
Input Expected Output System Output Comments
All fields filled in
with customer
information data
need to be filled
Customer can
registered to the
system database.
A message to show
successful registration
of customer will be
displayed.
Customer registration
completed
successfully.
Missing details on
registration
Customer registration
will not be successful.
Messages to show that
there are missing
fields.
Customer will not be
registered until the
required fields are all
filled
57
Figure 26 Testing plan Screenshot, Failure to add all require fields will result in a
message being displaced.
Failure to add all require fields will result in a message being displaced.
4.3.) Testing
4.3.1.) Unit
System testing can be described as the process of running the program to see if the system
will meet the user requirements. A series of tests was carried out to ensure that the system ran
smoothly and did not crush during the process. In order to carry out thorough testing at all
levels needs to be carried out. This involved testing the system at the conceptual level and
lower levels.
Figure 4.3 Testing screen shot Figure 26 TABLE CUSTOMER
58
Unit testing
During unit testing parts of the system were tested independently from the other units of the
system. As a system developer I was tasked with identifying any flaws within the system.
This involved tests on each command button on the current forms.
The system I used to test the system was a Dell Latitude e5500 with 4GB RAM and 500GB
Hard Drive (HDD) memory acting as the server. The test was carried out to verify the process
and the flow of data in the system. When the user logs into in the system, the system will
verify the username, password. The user will then navigate to the destined menu. The sales
personnel will verify customer details. If the details are correct the input should be accepted
and the customer should be registered.
4.3.3 Usability Testing
Usability can be described as a measure to show how the adaptable the system is. Random
user should be able to use the system at ease and it should meet specifications of the users.
Usability measures include performance and adaptability and preference. Can also be
described as a method of checking quality to assess how easy it is to adopt to the controls.
Methods of testing for usability
Adaptability: How easy is it for users to complete first hand tasks?
Desirability: How pleasant is the current design?
The use of images and links makes the design preferable and adaptable offering easier
navigation.
4.3.4.) Acceptance Testing
Can be described as a method used to identify any errors or omissions. It carried out to find
whether it meets user’s needs.
Acceptance testing will mark be the final stage for testing.
4.4.) Conclusions
The Mobile Store Management System was tested and evaluated successfully. This was done
to ensure that the system was precise and correct and error free. Reports were tested to ensure
59
that they fully fulfilled their objectives. Reports were implemented to make the system
informative and effective in producing the results that were seeked at the begging of the
proposal. Any further problems arising from the system not functioning well can be identified
and revised in the following version.
60
5.) Chapter 5 Summary, conclusions and recommendations
5.1.) Summary
During the project, data requirements and functional requirements were identified.The
Mobile Store and Management System was designed to fulfil the requirements Identified at
the beginning of the documentation and that was to ensure an error free smooth and
accountable system that is able is making managing the various activities of the company.
Furthermore the system allows the creation of reports and accountability of stock and sales by
employees and offering better security to safeguard information. The logical data model that
has been produced during the project is fully capable of defining the data requirements of the
enterprise
The system also made use of data and logical data to produce a logical model. .Furthermore
data flow diagrams which are starting point for the physical database design and
implementation were also derived.
The document produced from enterprise requirements collection and analysis is very useful
and important for the application development.
5.2.1) Recommendations
The following recommendations were made
The Mobile Store and Management System should allow the use of credit card facility to
offer better flexibility and options in terms of payments for products. This will ensure that the
system is tailor made to fit the ever changing environment and the technological changes
taking place.
Secondly acquisition of new technology should be used for the full benefit of the company
and should be used as an advantage to have greater accountability and offer a strategic
advantage over fellow mobile store owners.
Thirdly recommendations were also made that the company should invest in a server room to
allow the mirroring of data in case of a disaster.
Lastly the use of Bar code scanners. Using bar code scanner could assist us in minimizing the
manual data entry, and decrease the amount of time it takes to enter data. But at the same
time it will increase the cost of implementation.
61
5.2.2) Developer
The Mobile Store and Management System should allow the use of credit card facility to
offer better flexibility and options in terms of payments for products. The developer should
identify means of improving the system.
5.3.) Conclusions
The new Mobile Store and Management System has the ability to update, delete,
store and retrieve data. This will assist the company in minimizing the amount of
paperwork needed and automation process will assist the company in retrieving
data and the use of high security in the system will help safeguard data and offer
high efficiency.
The objectives were achieved therefore concluding the overall system and
working conditions to most objectives.
62
C.) Appendix C
3.6.4.) Database scripts
DATABASE SCRIPT FOR TABLE CATEGORY
CREATE TABLE [SONETSTOCKS].[CATEGORY](
[CAT_ID] [int] NOT NULL,
[CAT_NAME] [nvarchar](10) NOT NULL,
[DESCRIPTIONS] [nvarcar](50) NULL
CONSTRAINT PK_CATEGORY PRIMARY KEY( CAT_ID)
)
CREATE TABLE [SONETSTOCKS].[CUSTOMERS](
[CID] [int] IDENTITY(1,1) NOT NULL,
[FIRSTNAME] [varchar](20) NULL,
[LASTNAME] [varchar](20) NULL,
[ADDRESSs] [varchar](30) NULL,
[PHONE] [int] NULL,
[EMAIL] [nvarchar](30) NULL,
[EMP_ID] [int] NULL,
CONSTRAINT PK_CUSTOMER PRIMARY KEY( CID ),
CONSTRAINT FK_EMPLOYEES FOREIGN KEY (EMP_ID )REFERENCES
SONETSTOCKS.EMPLOYEE(EMP_ID)
ON UPDATE CASCADE
ON DELETE CASCADE
)
DATABASE SCRIPT FOR TABLE E_ROLE
CREATE TABLE [SONETSTOCKS].[E_ROLE](
[E_ROLE] [varchar](15) NULL,
[E_ROLE_ID] [nvarchar](15) NOT NULL,
[ROLENAME] [varchar](20) NULL,
[DESCRIPTIONS] [varchar](20) NULL,
CONSTRAINT PK_E_ROLES PRIMARY KEY( E_ROLE_ID),
)
DATABASE SCRIPT FOR TABLE EMPLOYEE
CREATE TABLE [SONETSTOCKS].[EMPLOYEE](
[EMP_ID] [int] IDENTITY(10000,1) NOT NULL,
[FIRSTNAME] [varchar](20) NULL,
[LASTNAME] [varchar](20) NULL,
63
[DOB] [date] NULL,
[SEX] [char](1) NULL,
[ADDRESSS] [varchar](30) NULL,
[PHONE] [int] NULL,
[Username] [varchar](15) NULL,
[PASSWORDS] [varchar](20) NULL,
[E_ROLE_ID] [nvarchar](15) NULL,
[EMAIL] [varchar](20) NULL,
CONSTRAINT PK_EMP_ID PRIMARY KEY ( EMP_ID),
CONSTRAINT FK_EMPLOYEE FOREIGN KEY (E_ROLE_ID)
REFERENCES SONETSTOCKS.E_ROLE(E_ROLE_ID)
ON UPDATE CASCADE
ON DELETE CASCADE
)
DATABASE SCRIPT FOR TABLE: ORDER_DETAILS
CREATE TABLE [SONETSTOCKS].[ORDER_DETAILS](
[ORDER_ID] [int] IDENTITY(10,1) NOT NULL,
[INVOICE_NUM] [int] NOT NULL,
[O_DETAILS] [varchar](30) NOT NULL,
[PRODUCT_ID] [int] NOT NULL,
[U_PER_PRICE] [int] NOT NULL,
[SIZE] [varchar](3) NOT NULL,
[ORD_QUANTITY] [int] NOT NULL,
[DEL_QUANTITY] [int] NOT NULL,
[DESCRPTION] [nvarchar](30) NOT NULL,
[DISCOUNT] [int] NULL,
[TOTAL] [int] NULL,
[ORDER_DATE] [date] NULL,
ONSTRAINT PK_ORDER_DETAILS PRIMARY KEY( ORDER_ID ),
CONSTRAINT FK_PAYMENT_ORDER_DETAILS FOREIGN KEY (INVOICE_NUM ) REFERENCES
SONETSTOCKS.PAYMENTS(INVOICE_NUM),
CONSTRAINT FK_ORDERS_ORDER_DETAILS FOREIGN KEY (ORDER_ID) REFERENCES
SONETSTOCKS.ORDERS(ORDER_ID),
CONSTRAINT FK_PRODUCTS_ORDER_DETAILSS FOREIGN KEY (PRODUCT_ID) REFERENCES
SONETSTOCKS.PRODUCTS(PRODUCT_ID)
ON UPDATE CASCADE
ON DELETE CASCADE
)
64
DATABASE SCRIPT FOR TABLE ORDERS
CREATE TABLE [SONETSTOCKS].[ORDERS](
[ORDER_ID] [int] IDENTITY(1,1) NOT NULL,
[EMP_ID] [int] NOT NULL,
[CID] [int] NOT NULL,
[ODATE] [date] NULL,
[ERRORMESSAGE] [varchar](50) NULL,
CONSTRAINT PK_ORDERS PRIMARY KEY( ORDER_ID ),
CONSTRAINT FK_EMPLOYEES_ORDERS FOREIGN KEY (EMP_ID ) REFERENCES
SONETSTOCKS.EMPLOYEE(EMP_ID),
CONSTRAINT FK_CUSTOMERS_ORDERS FOREIGN KEY (CID ) REFERENCES
SONETSTOCKS.CUSTOMERS(CID)
ON UPDATE CASCADE
ON DELETE CASCADE
)
CREATE TABLE [SONETSTOCKS].[PRODUCTS](
[PRODUCT_ID] [int] NOT NULL,
[P_NAME] [nvarchar](20) NULL,
[P_DESCR] [nvarchar](50) NOT NULL,
[CAT_ID] [int] NULL,
[SUPPLIER_ID] [int] NULL,
[Q_PER_UNIT] [int] NULL,
[U_PER_SPRICE] [int] NULL,
[U_WEIGHT] [int] NULL,
[U_SIZE] [nvarchar](10) NULL,
[DISCOUNT] [int] NULL,
[U_INT_STOCK] [int] NULL,
[U_In_Order] [int] NULL,
[RE_ORD_Level] [int] NULL,
CONSTRAINT PK_PRODUCTS PRIMARY KEY(PRODUCT_ID),
CONSTRAINT FK_SUPPLIERS_PRODUCTS FOREIGN KEY (SUPPLIER_ID ) REFERENCES
SONETSTOCKS.SUPPLIERS( SUPPLIER_ID),
CONSTRAINT FK_CAT_ID_PRODUCTS FOREIGN KEY (CAT_ID) REFERENCES
SONETSTOCKS.CATEGORY(CAT_ID)
ON UPDATE CASCADE
ON DELETE CASCADE
)
DATABASE SCRIPT FOR TABLE PAYMENTS
CREATE TABLE [SONETSTOCKS].[PAYMENTS](
[INVOICE_NUM] [int] IDENTITY(5000,1) NOT NULL,
[ORDER_ID] [int] NULL,
[ID_NO] [int] NULL,
[BANKNAME] [varchar](15) NULL,
[BANK_ACC_NO] [nvarchar](25) NULL,
[PAYMENT_TYPE] [nvarchar](15) NULL,
[AMOUNT] [int] NULL,
[PAY_DATE] [date] NULL,
[WARRANTY_END] [date] null,
[BALANCE] [int] NOT NULL,
CONSTRAINT PK_PAYMENTS_ORDER_DETAILS PRIMARY KEY( INVOICE_NUM )
65
)
3.8.1.) Stored procedures
STORED PROCEDURE ADD SUPPLIERS
CREATE PROCEDURE [SONETSTOCKS].[AADDSUPPLIERS]
(
@COMP_NAME VARCHAR (20) ,
@CONTACT_FNAME VARCHAR (20) ,
@CONTACT_LNAME VARCHAR (20) ,
@ADDDRESS NVARCHAR (30) ,
@PHONE INT ,
@EMAIL NVARCHAR (20) ,
@PAY_METHOD VARCHAR (10)
)
AS
BEGIN
INSERT INTO SONETSTOCKS.SUPPLIERS(COMP_NAME ,CONTACT_FNAME,
CONTACT_LNAME,ADDDRESS,PHONE,EMAIL,PAY_METHOD)
VALUES(@COMP_NAME ,@CONTACT_FNAME,
@CONTACT_LNAME,@ADDDRESS,@PHONE,@EMAIL,@PAY_METHOD)
END
CREATE PROCEDURE [SONETSTOCKS].[ADDCATEGORY](
@CAT_ID INT ,
@CAT_NAME NVARCHAR (10) ,
@DESCRIPTIONS NVARCHAR (50)
)
AS
BEGIN
INSERT INTO SONETSTOCKS.CATEGORY(CAT_ID,CAT_NAME,DESCRIPTIONS)
VALUES(@CAT_ID,@CAT_NAME,@DESCRIPTIONS )
END
STORED PROCEDURE DELETE CUSTOMER
CREATE PROCEDURE [SONETSTOCKS].[DELETE_CUSTOMER]
(
@CID INT ,
@StatmentType NVARCHAR (20)
)AS
BEGIN
66
IF @StatmentType = 'DELETE'
DELETE FROM SONETSTOCKS.CUSTOMERS WHERE CID = @CID
END
GO
STORED PROCEDURE JOIN PRODUCTS AND SUPPLIERS
CREATE PROCEDURE [SONETSTOCKS].[JOINNNNSSUPPLIERS AND PRODUCTS]
(
@COMP_NAME varchar(20)
)
AS
BEGIN
SELECT
PRODUCT_ID,
P_NAME ,
P_DESCR ,
U_PER_SPRICE,
COMP_NAME,
ADDDRESS,
PHONE ,
FROM SONETSTOCKS.PRODUCTS JOIN SONETSTOCKS.SUPPLIERS
ON PRODUCTS.SUPPLIER_ID =SUPPLIERS.SUPPLIER_ID
END
STORED PROCEDURE UPDATE CUSTOMER
CREATE PROCEDURE [SONETSTOCKS].[UPDATECUSTOMER]
(
@CID INT,
@EMP_ID int ,
@FIRSTNAME VARCHAR (20) ,
@LASTNAME VARCHAR (20) ,
@ADDRESSs VARCHAR (30) ,
@PHONE INT ,
@EMAIL NVARCHAR (30),
@StatmentType NVARCHAR (20)
)
AS
BEGIN
IF @StatmentType = 'UPDATE'
UPDATE CUSTOMERS SET
EMP_ID = @EMP_ID,
FIRSTNAME = @FIRSTNAME ,
LASTNAME = @LASTNAME ,
ADDRESSs = @ADDRESSs ,
PHONE = @PHONE ,
67
EMAIL = @EMAIL
WHERE CID = @CID
END
GO
ALTER PROCEDURE [SONETSTOCKS].[DELETE_CUSTOMER]
(
@CID INT ,
@StatmentType NVARCHAR (20)
)AS
BEGIN
IF @StatmentType = 'DELETE'
DELETE FROM SONETSTOCKS.CUSTOMERS WHERE CID = @CID
END
CREATE PROCEDURE [SONETSTOCKS].[SEARCHFOR_SUPPLIER_COMPANYNAME]
(
@COMP_NAME varchar(20)
)
AS
BEGIN
SELECT DISTINCT
SUPPLIER_ID,
COMP_NAME,
CONTACT_FNAME,
CONTACT_LNAME,
ADDDRESS,
PHONE,
EMAIL,
PAY_METHOD
FROM SONETSTOCKS.SUPPLIERS
WHERE COMP_NAME = @COMP_NAME
END
CREATE VIEW [SONETSTOCKS].[CUSTOMER_LISTWITHORDERS]
AS
SELECT
CUSTOMERS.CID AS CID,
68
CUSTOMERS.FIRSTNAME AS FIRSTNAME,
CUSTOMERS.LASTNAME AS LASTNAME,
CUSTOMERS.ADDRESSs AS ADDRESS ,
CUSTOMERS.PHONE AS PHONE,
CUSTOMERS.EMAIL AS EMAIL ,
ORDERS.ODATE AS ORDDATE ,
ORDERS.ERRORMESSAGE AS MESSAGE
FROM SONETSTOCKS.CUSTOMERS INNER JOIN SONETSTOCKS.ORDERS
ON CUSTOMERS.CID =ORDERS.CID
CREATE VIEW [SONETSTOCKS].[SUPPLIERS_AND_PRODUCTS]
AS
SELECT
SUPPLIERS.SUPPLIER_ID AS SUPPLIERID,
SUPPLIERS.COMP_NAME AS COMPANYNAME,
PRODUCTS.P_NAME AS PRODUCTNAME,
PRODUCTS.PRODUCT_ID AS PRODUCTID,
PRODUCTS.P_DESCR AS PDESCRIPTION,
PRODUCTS.CAT_ID AS CATID,
PRODUCTS.U_PER_SPRICE AS PRICE
FROM SONETSTOCKS.SUPPLIERS RIGHT JOIN SONETSTOCKS.PRODUCTS
ON SUPPLIERS.SUPPLIER_ID =PRODUCTS.SUPPLIER_ID
CREATE DATABASE SONETAFRICA
CREATE SCHEMA SONETSTOCKS
DATABASE SCRIPT FOR TABLE CATEGORY
CREATE TABLE [SONETSTOCKS].[CATEGORY](
[CAT_ID] [int] NOT NULL,
[CAT_NAME] [nvarchar](10) NOT NULL,
[DESCRIPTIONS] [nvarchar](50) NULL,
CONSTRAINT PK_CATEGORY PRIMARY KEY( CAT_ID )
)
DATABASE SCRIPT FOR TABLE : CUSTOMERS
CREATE TABLE [SONETSTOCKS].[CUSTOMERS](
69
[CID] [int] IDENTITY(1,1) NOT NULL,
[FIRSTNAME] [varchar](20) NULL,
[LASTNAME] [varchar](20) NULL,
[ADDRESSs] [varchar](30) NULL,
[PHONE] [int] NULL,
[EMAIL] [nvarchar](30) NULL,
[EMP_ID] [int] NULL,
CONSTRAINT PK_CUSTOMER PRIMARY KEY( CID ),
CONSTRAINT FK_EMPLOYEES FOREIGN KEY (EMP_ID )REFERENCES
SONETSTOCKS.EMPLOYEE(EMP_ID)
ON UPDATE CASCADE
ON DELETE CASCADE
)
DATABASE SCRIPT FOR TABLE E_ROLE
CREATE TABLE [SONETSTOCKS].[E_ROLE](
[E_ROLE] [varchar](15) NULL,
[E_ROLE_ID] [nvarchar](15) NOT NULL,
[ROLENAME] [varchar](20) NULL,
[DESCRIPTIONS] [varchar](20) NULL,
CONSTRAINT PK_E_ROLES PRIMARY KEY( E_ROLE_ID),
)
DATABASE SCRIPT FOR TABLE EMPLOYEE
CREATE TABLE [SONETSTOCKS].[EMPLOYEE](
[EMP_ID] [int] IDENTITY(10000,1) NOT NULL,
[FIRSTNAME] [varchar](20) NULL,
[LASTNAME] [varchar](20) NULL,
[DOB] [date] NULL,
[SEX] [char](1) NULL,
[ADDRESSS] [varchar](30) NULL,
[PHONE] [int] NULL,
[Username] [varchar](15) NULL,
[PASSWORDS] [varchar](20) NULL,
[E_ROLE_ID] [nvarchar](15) NULL,
[EMAIL] [varchar](20) NULL,
CONSTRAINT PK_EMP_ID PRIMARY KEY ( EMP_ID),
CONSTRAINT FK_EMPLOYEE FOREIGN KEY (E_ROLE_ID)
REFERENCES SONETSTOCKS.E_ROLE(E_ROLE_ID)
ON UPDATE CASCADE
ON DELETE CASCADE
)
70
CREATE TABLE [SONETSTOCKS].[ORDER_DETAILS](
[ODETAIL_ID,] [int] IDENTITY(10,1) NOT NULL,
[INVOICE_NUM] [int] NOT NULL,
[O_DETAILS] [varchar](30) NOT NULL,
[PRODUCT_ID] [int] NOT NULL,
[U_PER_PRICE] [int] NOT NULL,
[SIZE] [varchar](3) NOT NULL,
[ORD_QUANTITY] [int] NOT NULL,
[DEL_QUANTITY] [int] NOT NULL,
[DESCRPTION] [nvarchar](30) NOT NULL,
[DISCOUNT] [int] NULL,
[TOTAL] [int] NULL,
[ORDER_DATE] [date] NULL,
ONSTRAINT PK_ORDER_DETAILS PRIMARY KEY( ORDER_ID, PRODUCT_ID ),
CONSTRAINT FK_PAYMENT_ORDER_DETAILS FOREIGN KEY (INVOICE_NUM ) REFERENCES
SONETSTOCKS.PAYMENTS(INVOICE_NUM),
CONSTRAINT FK_ORDERS_ORDER_DETAILS FOREIGN KEY (ORDER_ID) REFERENCES
SONETSTOCKS.ORDERS(ORDER_ID),
CONSTRAINT FK_PRODUCTS_ORDER_DETAILSS FOREIGN KEY (PRODUCT_ID) REFERENCES
SONETSTOCKS.PRODUCTS(PRODUCT_ID)
ON UPDATE CASCADE
ON DELETE CASCADE
)
DATABASE SCRIPT FOR TABLE ORDERS
CREATE TABLE [SONETSTOCKS].[ORDERS](
[ORDER_ID] [int] IDENTITY(1,1) NOT NULL,
[EMP_ID] [int] NOT NULL,
[CID] [int] NOT NULL,
[ODATE] [date] NULL,
[ERRORMESSAGE] [varchar](50) NULL,
CONSTRAINT PK_ORDERS PRIMARY KEY( ORDER_ID ),
CONSTRAINT FK_EMPLOYEES_ORDERS FOREIGN KEY (EMP_ID ) REFERENCES
SONETSTOCKS.EMPLOYEE(EMP_ID),
CONSTRAINT FK_CUSTOMERS_ORDERS FOREIGN KEY (CID ) REFERENCES
SONETSTOCKS.CUSTOMERS(CID)
ON UPDATE CASCADE
ON DELETE CASCADE
)
71
CREATE TABLE [SONETSTOCKS].[PRODUCTS](
[PRODUCT_ID] [int] NOT NULL,
[P_NAME] [nvarchar](20) NULL,
[P_DESCR] [nvarchar](50) NOT NULL,
[CAT_ID] [int] NULL,
[SUPPLIER_ID] [int] NULL,
[Q_PER_UNIT] [int] NULL,
[U_PER_SPRICE] [int] NULL,
[U_WEIGHT] [int] NULL,
[U_SIZE] [nvarchar](10) NULL,
[DISCOUNT] [int] NULL,
[U_INT_STOCK] [int] NULL,
[U_In_Order] [int] NULL,
[RE_ORD_Level] [int] NULL,
CONSTRAINT PK_PRODUCTS PRIMARY KEY(PRODUCT_ID),
CONSTRAINT FK_SUPPLIERS_PRODUCTS FOREIGN KEY (SUPPLIER_ID ) REFERENCES
SONETSTOCKS.SUPPLIERS( SUPPLIER_ID),
CONSTRAINT FK_CAT_ID_PRODUCTS FOREIGN KEY (CAT_ID) REFERENCES
SONETSTOCKS.CATEGORY(CAT_ID)
ON UPDATE CASCADE
ON DELETE CASCADE
)
DATABASE SCRIPT FOR TABLE PAYMENTS
CREATE TABLE [SONETSTOCKS].[PAYMENTS](
[INVOICE_NUM] [int] IDENTITY(5000,1) NOT NULL,
[ORDER_ID] [int] NULL,
[ID_NO] [int] NULL,
[BANKNAME] [varchar](15) NULL,
[BANK_ACC_NO] [nvarchar](25) NULL,
[PAYMENT_TYPE] [nvarchar](15) NULL,
[AMOUNT] [int] NULL,
[PAY_DATE] [date] NULL,
[WARRANTY_END] [date] null,
[BALANCE] [int] NOT NULL,
CONSTRAINT PK_PAYMENTS_ORDER_DETAILS PRIMARY KEY( INVOICE_NUM )
)
3.10.1) Backup and recovery
Script code for full back up
CREATE proc [SONETSTOCKS].[FULLBACKUPDATABASE]
as
begin
BACKUP database SONETAFRICA
TO DISK = 'E:\PROJECTBACKUP.bak'
END
Script code for restoring database
72
CREATE proc [SONETSTOCKS].[FULLRESTOREBACKUPDATABASE]
as
begin
RESTORE database SONETAFRICA
FROM DISK = 'E:\PROJECTBACKUP.bak'
END
DESIGN CLASS PRODUCTS
using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Data.SqlClient; using System.Data; namespace WindowsFormsApplication8 { class products { public static string P_NAME = ""; public static string P_DESCR = ""; public static int CAT_ID ; public static int SUPPLIER_ID ; public static int Q_PER_UNIT ; public static int U_PER_SPRICE ; public static int U_WEIGHT; public static string U_SIZE ; public static int DISCOUNT; public static int U_INT_STOCK; public static int U_In_Order; public static int RE_ORD_Level; public static bool GetProduct(string P_NAME) { bool taken = false; SqlConnection con = new SqlConnection(@"Data Source=.;Initial Catalog=SONETAFRICA;Integrated Security=True"); con.Open(); SqlCommand cmd = new SqlCommand("SONETSTOCKS.GRIDSEARCHFOR_PRODUCTNAME", con); cmd.Connection=con; cmd.CommandType = CommandType.StoredProcedure; cmd.Parameters.AddWithValue("@P_NAME", P_NAME); SqlDataReader rd = cmd.ExecuteReader();
73
if (rd.Read()) { P_NAME = rd[1].ToString(); P_DESCR = rd[2].ToString(); CAT_ID = int.Parse(rd[3].ToString()); SUPPLIER_ID = int.Parse(rd[4].ToString()); Q_PER_UNIT = int.Parse(rd[5].ToString()); U_PER_SPRICE = int.Parse(rd[6].ToString()); U_WEIGHT = int.Parse(rd[7].ToString()); U_SIZE =(rd[8].ToString()); DISCOUNT =int.Parse(rd[9].ToString()); U_INT_STOCK = int.Parse(rd[10].ToString()); U_In_Order =int.Parse(rd[11].ToString()); RE_ORD_Level =int.Parse(rd[12].ToString()); taken = true; } return taken ; } } }
74
D.) Bibliography
Codd, E. F. (1970, June). " A Relational model of data for large Shared date banks.". Retrieved from
Communications od the ACM 13: en.m.wikipedia.org/wiki/sql
Feasibility studies. (2012, Jan 21). Retrieved from wikipedia: em.wikipedia.org/wiki/Feasibility_study
Norman, M. (2003). Database Design Manual: using MySQL for Windows (Springer Professional
Computing). 4th Edition. London: Springer-Verlag.
Elmasri, R. and Navathe, S. (2011), Fundamentals of Database System. 6th Edition, USA: Pearson
Education Limited