1.

INTRODUCTION

The Mall Management System is a comprehensive module offering flexible management of data in a large shopping mall, which meets the todays demanding requirements for billing and reporting the sales. It also interfaces with other software modules to integrate the accounting system. This mall management system is any activity undertaken to accomplish a specific task. It may include many components such as new areas of scope in the existing system or certain modification for a better or devising a brand new candidate system if the present existing system has fallen into areas.

1.1 PURPOSE :

Before developing the Mall Management System we should know what we are dealing with and what information we need for developing the system. So we should develop the system which contains all the tools and necessary technical support required by any mall or a shop to function in efficient manner.

This software of Mall Management System is designed for the malls and shops where there is the facility of maintaining the information about items, working of the existing system and also for better coordination between its departments.

Mall Management System can be used in malls where there is huge amount of data to be maintained and retrieved.

Mall Management System also contains the information about the customer details who come for shopping at the mall.

Page | 1

Also security is being of utmost importance in any system, so here the security is limited only to the administrator login, so that no one can access the data.

1.2 SCOPE :

Mall Management System may find various scopes because in todays world all the big shopping malls should be computerized because keeping the records in the registers is very hard and requires more manual work.

Mall Management System can be used where there is question arise to maintain records about large amount of items and the maintenance of records.

For example Mall Management System can be used in the big malls like Big Bazaar, etc.

1.3 DEFINITION, ACRONYM AND ABBREVIATION :

1.3.1 Definition : Our project Mall Management System is applicable to the any shopping malls related to keep items record whether it is a large shopping mall selling multiple items under a single roof or a small shop taking records of items. By developing this project the boring tasks of maintaining

Page | 2

the records and updating at regular intervals is being eliminated. Here, by using this mall management system, the administrator or the user of the system i.e., the owner of the shopping mall can view the sale details and also the customer details. And can also maintain the item details as and when required by the shopping mall.

1.3.2 Acronym and Abbreviations :

VB : Microsoft Visual Basic 6.0 is part of application designing for developing and running multitier architecture Visual Basic application based largely on modular software components running on application software.

Oracle 8i : It is a database management system which delivers flexible and cost-effective platform to build robust on business applications.

UML : Unified Modeling Language. It is an effective tool for developing system diagrams.

1.4 REFERENCES :

Black Book of Visual Basic 6.0.

Structured Query Language Ivan Bayross.

Software Engineering Roger S. Pressman.

Page | 3

1.5 TECHNOLOGIES TO BE USED :

VB (Visual Basic) Application Architecture.

Oracle Database Application.

Rational Rose Designing Tool.

1.6 OVERVIEW :

The system developed is entirely divided into following sections :

Overall Description : This describes the overall architecture of the system which is developed, how it is interconnected and external connections.

Tools Used : Here tools used are so user friendly and easy to understand.

Specific Requirements : Describe the function of each actor and their role in system and constraints.

Page | 4

Project Title : -

Mall Management System

Operating System: Hardware Requirements : -

Windows XP, Windows 2000

Pentium IV Processor, 128 MB RAM, 50 MB hard disk space.

Software Requirements : -

Front-end Tool - Microsoft Visual Basic 6.0 Back-end Tool- Oracle 8i

Documentation Tool : -

Microsoft Word

Page | 5

Page | 6

2. UML DIAGRAM DESCRIPTION

The Unified Modeling Language (UML) is a general purpose visual modeling language that is used to specify, visualize, construct, and document the artifacts of a software system. It captures decisions and understanding about systems that must be constructed. The UML also contains organizational constructs for arranging models into packages that permit software teams to partition large systems into workable pieces, to understand and control dependencies among the packages, and to Unified Modeling Language (UML) is a general purpose visual modeling language that is used to specify, visualize, construct, and document the artifacts of a software system. It captures decisions and understanding about systems that must be constructed. The UML also contains organizational constructs for arranging models into packages that permit software teams to partition large systems into workable pieces, to understand and control dependencies among the packages, and to manage the versioning of model units in a complex development environment.

2.1 USE CASE MODEL SURVEY :

The use case view models the functionality of the system as perceived by users, called actors. A use case is coherent unit of functionality expressed as transaction among actors and the system. The purpose of the use case is to list the actors and use cases and show which actors participate in each use case. Use cases can also be described at various levels of detail. They can

Page | 7

be factored and described in terms of other, simpler use cases. A use case is implemented as collaboration in interaction view.

2.2 ACTIVITY MODEL SURVEY :

An activity diagram is a variant of state machine that shows the computational activities in performing of calculation. An activity state represents an activity : a workflow step or the execution of an operation. An activity diagram describes both sequential and concurrent groups of activities. The input and output parameters of an action can be shown using flow relationships connecting the action and an object flow state.

2.3 SEQUENCE MODEL SURVEY :

A sequence diagram shows the set of messages arranged in time sequence. Each classifier role is shown as a lifeline- that is, a vertical line that represents the role over time through the entire interaction. Messages are shown as arrows between lifelines. A sequence diagram can show a scenario- that is, an individual history of a transaction. One use of sequence diagram is to show the behavior sequence of use case. When the behavior is implemented, each message on sequence diagram corresponds to an operation on a class or an event trigger on a transaction in state machine.

2.4 COLLABORATION MODEL SURVEY :

Collaboration models the objects and links that are useful and meaningful within an interaction. The objects and links are meaningful only in the context provided by the interaction. A classifier role describes an object and an association role describes a link within collaboration. A collaboration diagram shows the roles in the interaction as a geometric arrangement. The messages are shows as arrows attached to relationship lines connecting classifier roles. One use a collaboration diagram is to show the implementation of an operation. The collaboration

Page | 8

shows the parameters and local variables of the operation as well as more permanent associations.

2.5 CLASS MODEL SURVEY :

Classes are drawn as rectangles. Lists of attributes and operations are shown in separate compartments. The compartments can be suppressed when full details is not need. A class may appear on several diagrams. Its attributes and operations are often suppressed on all but one diagram. Relationships among classes are drawn as connecting class rectangles. The different kinds of relationships as distinguished by line texture and by adornments on the paths or their ends.

2.6 STATE CHART MODEL SURVEY :

A state chart modes the possible life histories of object of a class. A state chart contains states connected by transition. Each state models a period of time during the life of an object during which it satisfies certain conditions. When an event occurs it may cause the firing of transition that takes the object to a new state. When a transition fires, an action attached to the transition may be executed. State chart may be used to describe user interfaces, device controllers, and other reactive subsystems. They may also be used to describe passive objects that go through several qualitatively distinct phases during their lifetime, each of which has its own special behavior.

Page | 9

MALL MANGEMENT SYSTEM

LOGIN FORM

USERNAME &PASSWORD

2.7 ARCHITECTURE DIAGRAM AND DATABASE DESIGN :

MDI FORM

BILL ITEM DETAILS CUSTOMER DETAILS SALE DETAILS

BILL DATABASE SALES DATABASE DATABASE CUSTOMER DATABASE

REPORTS
ITEM DATABASE

Page | 10

Table Name: Item Description: This table is used to store data about the Items.

Name Item_ID Item_Name Item_Price Item_Brand Item_Category

Type Number Varchar Number Varchar Varchar

Size 6 20 6 20 20 20

Constraint Primary Key

Description Contains Item ID Contains Items Name Contains Items Price Contains Items Brand Contains Items Category Contains Items Date of Production.

Date_of_Production Varchar

Page | 11

Table Name: Customer Description: This table is used to store data about the Customer.

Name Cust_id Cust_name Cust_addr Cust_city Ph_no

Type Number Varchar Varchar Varchar Number

Size 6 20 20 20 6

Constraint Primary Key

Description Contains the Customer ID Contains Customer's name Contains Customer's Address Contains Customer's City Contains Customer's Telephone number.

Table Name: Sale Description: This table is used to store data about the rooms that are under maintenance

Name Sale_No Sale_date Sale_TotPrice Sale_Qty Sale_Cust_ID

Type Number Varchar Varchar Varchar Number

Size 6 20 20 20 6

Constraint Primary Key

Description Contains the sale no Contains the date at which items were purchased Contains the total price of the items purchased Contains the quantity of the items purchased.

Foreign Key

Contains the customer ID of the respective sale.

Table Name: Result Description: This table is used to store data about the results of the Items.

Page | 12

Name Bill_No Bill_Cust_ID Bill_Date Transaction_Typ e Tot_Amt

Type Number Number Varchar Varchar Number

Size 6 20 20 20 6

Constraint Primary Key

Description Contains the Bill No. Contains the Customer ID of the respective Bill. Contains the Bill Date Contains the Transaction type used to pay the bill.

Foreign key

Contains Total amount of all the item's that are purchased.

2.8 ASSUMPTION AND DEPENDENCIES :

While we were deciding to take Mall Management System as our project we thought of some things and surfed some websites that gave some idea regarding what mall management system is and what things are necessary for it. Several assumptions were made before implementation of the project that includes particular item code number that will be link to every detail of the various items. With that it contains details that are necessary for the shopping mall to keep the record of items such as its price, its category, etc. The designed system gives the information of the items along with their other details. Main after all that we have the form that will generate bill of the particular item when it is being sold to the customers. Now taking on the dependencies we talk about that our project depends on the details of customers and their various purchases and their payments. Dependencies of the project are that, it is on the basic calculation of the sale of the items.

Page | 13

The project mainly depends on the generation of bill to the customer and the administrator or the owner of the shopping mall can see the sale.

Page | 14

3. SPECIFIC REQUIREMENTS :

3.1 USE CASE REPORTS :

Page | 15

customer looks & picks up the items

Ask for Bill customer

cashier

calculate bill

Make payment Credit card service

cash

cheque

credit card

Generate Bill

3.2 ACTIVITY DIAGRAM REPORT :

Page | 16

Looks & Picks up the items

Ask for Bill

Calculates the bill

Make payment

Fork

Cash

Cheque

Credit Card

Generate Bill

Page | 17

3.3 SEQUENCE DIAGRAM REPORT :

Customer

Cashier

Credit Card Service

1: customer picks the items 2: Asks for the bill 3: Calculates the bill 4: Makes Payment with cash 5: Makes Payment with Cheque 6: Makes Payment with Credit Card 7: Charge (Card no., cost) 8: Credit Card is Authorized 9: Generates Bill

Page | 18

3.4 COLLABORATION DIAGRAM REPORT :

Page | 19

1: customer picks the items 5: Makes Payment with Cheque 2: Asks for the bill 6: Makes Payment with Credit Card 4: Makes Payment with cash Cashier 3: Calculates the bill 9: Generates Bill 8: Credit Card is Authorized

Custome r

7: Charge (Card no., cost)

Credit Card Service

Page | 20

3.5 CLASS DIAGRAM REPORT :

Item Item ID Item Name Item Price Item Brand * Item Category Date of Production Sale() 1..*

Customer Customer ID Customer Name Customer Address Customer City Customer Phone no. Purchase() 1

1 Sale Sale No. Sale Date Sale total Sale quantity 1 Payment()

1 Bill Bill No. Bill Date Type of Transaction Total Amount Bill generated()

Page | 21

3.6 STATE CHART DIAGRAM REPORT :

Assign to Subscription

Availability of Items

Lock

Purchase by the customer

Buy

Sold

Unlock

Bill

Generate Bill

Page | 22

3.7 SUPPLEMENTARY REQUIREMENTS :

USER INTERFACE REQUIREMENTS :

The interface with user in new system should be good compared to that of existing system. With Visual Basic 6.0 as a front-end tool, the new system should be very user friendly and have good I/p and o/p design compared to the existing system.

Page | 23

FUNCTIONAL REQUIREMENTS :

o The new system should have data security. The users of the system should only be able to access data, which they are concerned. o The new system should maintain its performance when the amount of data stores increases. o The new system should have computerized recording of applicants personal information, requirement information. o The task of match making and report generation should also be done on computer. o The new system should decrease the manual work to the maximum possible extent. o It should decrease the amount of paper work to be maintained for reference. o It should decrease the chances of errors and manipulations to the maximum possible extent.

Page | 24

4. SUPPORTING INFORMATION :

4.1 IMPLEMENTATION ENVIRONMENT :

Visual Basic is used as the Front-End and the Oracle 8i is used as the back-end in this project.

4.2 SECURITY FEATURES :

In this software the facility of user name and password is there. So unauthorized person cannot log into this software and access the software.

Only person knowing correct username and password can access the software.

4.3 CODING STANDARD :

Page | 25

Following coding standards are used while developing the application :

Variables are given understandable names. Function is used whenever it is required, and each function name is related to the task it is performing. Classes have related name as per their task. Also in this software variables are declared in the consistent manner. Variable are also given understandable names according to their task.

4.4 TESTING METHODS :

BLACK BOX TESTING :

o This test is carried out to see whether all the modules in the software are properly inter-related or not. Here, the nodes are represented as circles connected by links that take a number of different forms. o A directed link (represented by an arrow) indicates that the relationship moves in only one direction. o A bi-directional link implies that relationship applies in both directions. o A simple line represents undirected link.

UNIT TESTING :

Page | 26

o Here, we focus verification effort on the smallest unit of our software design-the software component or module. o Using the component level design description as a guide, we test important control paths to uncover errors within the boundary of the module. o Our unit test focuses on the internal processing logic and data structures within the boundaries of a component. This testing is conducted in parallel for multiple components. We use unit test to remove following common errors: Incorrect initialization. Precision inaccuracy. Incorrect symbolic representation of an expression.

Performing unit test on our software has removed errors such as :

Comparison of different data types. Incorrect logical operators or precedence. Expectation of equality when precision makes equality unlikely. Incorrect comparison of variables.

MODULE TESTING :

o This type of testing focuses verification effort on the software component or module. o Every module is tested separately. o Correction is made as per the requirement. o Each and every module has to go in the testing process.

Page | 27

o The tested module is used letter on the process.

TEST CASES :

Following are the different test cases that are performed while developing the software :

o Check whether user is valid or not. If the user enters correct username and password than and than he/she can access the software otherwise user cannot access the software.

o Data Validation. In the modules like category, room and customer different inputs are given and checked whether it is valid or not. If the inputs are wrong than corresponding message will come. And if the input is correct than message of successful insertion will come.

o Another test case that is performed is that whether user is deleting or editing the correct information or not. And if the edit is performed than corresponding changes in

Page | 28

the database has to be occurred. And if the data are deleted than this data must also be deleted from the database.

5. CONCLUSION/DOUBTS/QUERIES :

Our software can manage the data very effectively.

Page | 29

Also the data entry of different module can be performed very easily. Once the data is entered, user can also update, delete or view the data very easily using this software. Although we have made complete effort to make error free software, there are some limitations as mentioned above. In the feature we will try to overcome those limitations.

Page | 30