SYSTEM DESIGN Introduction

When the requirements document for the software to be developed is available the design activity begins. The main aim of design process is to produce a model or representation of the system, which can be used later to bind the system. The produced model is called design of the system. A system design is a top down approach to minimize complexity and make a problem manageable by subdivided it into smaller segments. The most changing phase of the system development of life cycle is system design. It refers to the technical specification that will be applied in implementing the candidate system. The design phase is a translation from user oriented document to document oriented to programmers. The potential objects are thoroughly analyzed. Class hierarchies are to check whether the system is behaving the way it has to. There after the classes are individually tested and subsequently they are integrated from the overall system. This level focuses on deciding which modules are needed for system the specifications for those modules and how these modules are that interconnected.

Context Flow Diagram (CFD):

A Context Flow Diagram is a top level (also known as level 0) data flow diagram. It only contains one process node (process 0) that generalizes the function of the entire system in relationship to external entities. A Context Flow Diagram is a diagram that shows the inputs and output of a system. It shows all the external entities with the system and the data flows between these entities and the system.

Gives order to, enquire n Customer

give order to Admin Supplier Provide goods View products, Order , Bill,reports

su

Supply products Add products, Order details, Generate bills, Supplier details

Sales and inventory management system

Data base

Structure of detail design document: 1.Introduction

The design level in which the internal design of the modules, or how the specifications of the module can be satisfied is decided, is often called as the Detailed Design or Logic design. Detailed design essentially expands the system design and the database design to contain a more detailed description of the processing logic and data structures so that the design is sufficiently complete for coding.

The first step before the detailed design or code for a module can be developed is that the specification of the module be given precisely specified, the internal logic for the module that will implement the given specification can be decided.

2. Applicable Documents:
This section describes the general factors that affect the software and its requirements. Specific requirements are not mentioned, but a general overview is presented to make the understanding of the specific requirements easier. The proposed software is intended to collect, maintain and update all the information about the shop. It is used to define the class of the establishment. Management any faculty can also use this software to search out information of their interest. This software has been developed using VB as front-end language and SQL server as back-end language which is supported by Microsoft Windows Operating System.

3. Structure of the software package:

The Functional components identified during the System Design are: Functional component 1 Functional component 2 Functional component 3 Functional component 4 Functional component 5 Functional component 6 : Administrator : Category : Product : Supplier : Customer : Payments and Bill maintenance.

4. Modular Decomposition of component 4.1 Modules of Login

4.1.1 Design Assumption: This module is designed with the intension to provide security to user. The Login contains the necessary information of the tables and forms included in the applications. 4.1.2 Identification of Modules: Username: Allows user to enter their name. Password: Allows user to enter their valid password.

4.1.3 Structure chart showing the hierarchy of modules: Structure chart is a graphical representation of the control logic of processing functions or modules representing a system. It is one of the most commonly used methods for system design. In a structure chart, each program module is represented by a rectangular box. Modules at the top level of the structure chart call the modules at the lower level. The connections between modules are represented by lines between the rectangular boxes. The connection describes data flows between the called and calling modules.
LOGIN

MASTER PAGE

4.1.4 Data structures shared among modules: Tables used are listed as follows: Login 4.2 Modules of Category : 4.2.1 Design Assumption: This module of Application will displays the category of the product under which it belongs. It also maintains the measure type which displays how different types of products are measured. 4.2.2 Identification of Modules: Category Id Category Name Measure Name : Id of category. : It displays the category name. : Name of the measurement type.

4.2.3 Structure chart showing the hierarchy of modules.

MASTER PAGE

CATEGORY

SAVE

UPDATE

DELETE

4.2.4 Data structures shared among modules: Tables used are listed as follows: Category Measurement

4.3 Modules of product : 4.3.1 Design Assumption: This module is used to add ,save ,delete the products .This module is also used view the whole stock by the use of grid. 4.3.2 Identification of Modules: Product Id : This number is allocated for particular product. Product Name : Describes the name of the product. Category : The category of the products can be extracted. Quantity : The quantity of the products. Product Price : Price of the product. Product description:Description of the product.

4.3.3 Structure chart showing the hierarchy of modules:

MASTER PAGE

PRODUCT

SAVE

UPDATE

DELETE

VIEW

4.3.4 Data structures shared among modules: Tables used are listed as follows, Product

4.4 Modules of Supplier: 4.4.1 Design Assumption: This module application will stores and maintains the details of the Suppliers of Hardware suppliers. 4.4.2 Identification of Modules: Supplier Id Name Address Phone no Email id Company : Id of the supplier. : Name of the supplier. : Address of the supplier. : Supplier phone number. : Supplier email_id. : Name of the company.

4.4.3 Structure chart showing the hierarchy of modules:

MASTER PAGE

SUPPLIER

SAVE

UPDATE

DELETE

VIEW

4.4.4 Data structures shared among modules: Tables used are listed as follows, Supplier

4.5 Modules of Customer: 4.5.1 Design Assumption: This module stores and maintains the details of the customers. 4.5.2 Identification of Modules: Order No Customer Name Address PhoneNo Product Name Price Qty Order Date Delivery Date : It generates the order number. : It allows to enter customer name. : It allows to enter customer address. : It allows enter customer telephone number. : It allows to enter name of the product. : It allows to enter price of the product. : It allows to enter quantity of the product. : It allows to enter order date of the product. : It allows to enter delivery date of the product.

4.5.3 Structure chart showing the hierarchy of modules:

ORDER

CUSTOMER

SAVE

UPDATE UPDATE

VIEW

4.5.4 Data structures shared among modules: Tables used are listed as follows, Customer Order 4.6 Modules of Payments and Bill Maintenance Module: 4.6.1 Design Assumption: This module is used to keep track of all the payments done by each and every customer. 4.6.2 Identification of Modules: Bill No CName CAdd PName Cat Qty Price Tax Total : It generates bill. : It generates customer name. : It generates customer address. : It generates name of the product. : It generates category of the product. : It generates quantity of the product. : It generates price of particular product. : Allows to enter rate of tax. : It generates total amount to pay.

4.6.3 Data structures shared among modules: Tables used are listed as follows, Bill

5. Detail Design: 5.1.Data Flow Diagram (DFD):

A Data Flow Diagram (DFD) is a graphical representation of the "flow" of data through an Information System. A data flow diagram can also be used for the visualization of Data Processing. It is common practice for a designer to draw a context-level DFD first which shows the interaction between the system and outside entities. This context-level DFD is then "exploded" to show more detail of the system being modeled. A DFD represents flow of data through a system. Data flow diagrams are commonly used during problem analysis. It views a system as a function that transforms the input into desired output. A DFD shows movement of data through the different transformations or processes in the system. Dataflow diagrams can be used to provide the end user with a physical idea of where the data they input ultimately has an effect upon the structure of the whole system from order to dispatch to restock how any system is developed can be determined through a dataflow diagram. The appropriate register saved in database and maintained by appropriate authorities.

DATA Diagram Notation

FUNCTION

DATABASE

DATAFLOW

Input/Output

5.2. Module design of component 1 5.2.1 Module 1: User login 5.2.1.1 Input: Table used: Login 5.2.1.2 Procedural details:

Level -0 DFD

Invalid

Enter User name ADMIN And Password

LOGIN

Valid Sales And Inventory

DB

5.2.1.3 File I/O interface 5.2.1.4 Outputs

: Graphical User Interface : Admin enters the system successfully

5.2.2 All Modules

Level-1 DFD

ADD DB DELETE

Category

UPDATE ADD DB DELETE

ADMIN

Product UPDATE VIEW Supplier ADD DB

Search Supplier Order

DELETE UPDATE

Customer Order VIEW

VIEW

ORDER DB CANCEL ORDER CANCEL DB

DB

DATABASE DESIGN AS APPLICABLE TO THE SOFTWARE

Database design maintains the data required by the system. One of the key design issues involve in the database to design is the distribution of data in a way that minimizes transactions traffic. Another key design issues is the choice of the database management system. Database tables used are described in the following section.

DATABASE TABELS Login Table Field name username password Type varchar varchar Size 50 50 Description username password Constraint Not Null Not Null

Category Table Field name cat_id cat_name mesure_name Product Table Field name p_id p_name cat_name p_price p_desc p_quantity mesure_name Type varchar varchar varchar numeric varchar numeric varchar Size 50 50 50 18,0 50 18,0 50 Description Product id Product name Category name Product price Product description Product quantity Measurement name Constraint Not Null Not Null Not Null Not Null Not Null Not Null Not Null Type varchar varchar varchar Size 50 50 50 Description Category id Category name Measurement name Constraint Not Null Not Null Not Null

Supplier Table Field name s_id s_name s_add s_pno s_eid s_cmpy Type varchar varchar varchar numeric varchar varchar Size 50 50 50 18,0 50 50 Description Supplier id Supplier name Supplier address Supplier phone number Supplier email id Supplier company Constraint Not Null Not Null Not Null Not Null Not Null Not Null

Customer order Table Field name orderno c_name address phone_no p_name price qty order_date delivery_order Type varchar varchar varchar numeric varchar numeric numeric datetime datetime Size 50 50 50 18,0 50 18,0 18,0 Description Order number Customer name Address Phone number Product name Price Quantity Order date Delivery date Constraint Not Null Not Null Not Null Not Null Not Null Not Null Not Null Not Null Not Null

Supplier order Table Field name o_no s_name p_name qty odate ddate status Type numeric varchar varchar numeric datetime datetime varchar Size 18,0 50 50 18,0 50 Description Order date Supplier name Product name Quantity Order date Delivery date Status Constraint Not Null Not Null Not Null Not Null Not Null Not Null Not Null

ER-Diagram
An Entity Relation(ER) Diagram is a specialized graphics that illustrates the interrelationship between entities in a database. ER diagrams often use symbols to represent 3 different types of information. Boxes are commonly used to represent entities. Diamonds are normally used to represent relationships and ovals are used to represent attributes.

S_name S_cmpy Admin Adds S_cid S_id S_pno Cat_id Category takes Mesure_name Providing Cat_name S_add

Supplier

address D_date

orderno P_name price C_name Phone_no

Belongs to

p_id p_name

Customer order

p_price e Product p_desc

cat_name

O_date

qty

mesure_name P_quantity

cadd Bill no tax Bill Each order has price qty cname total cat pname