Medicine Distribution Management System: M. Siddique Roll No 847

Medicine Distribution Management System
MEDICINE DISTRIBUTION MANAGEMENT

SYSTEM
M. Siddique
Roll No 847
BS (IT)
Session 2010-2014
Department Of Computer Science & IT

THE GOVT S.E COLLEGE BAHAWALPUR
i
Department of Computer Science and Information Technology
ii
PROJECT BRIEF
Project Name:
Medicine Management System
Objective:
The main aim of the project is to develop a complete desktop application of Medicine
Management System which will facilitate the administration to manage all the
information regarding all data of the medicine. Record all the information about the
medicine and customer and vendors. Manage information of product supply to the
customers; also maintain information receiving products from the vendors.
iii
Undertaken BY:
M.Siddique
Supervised By:
Sir Asghar Sab

Lecturer in Department Of Computer Science & IT.
Operating System:
Windows 8(64bit) Ultimate
Project Stared:
June-01-2014
Project Finished:
September-10-2014
Source Language:
C# /MySql Server 2010
iv
GOD HELPS THOSE WHO HELP THEMSELVES
MAY ALLAH HELP ME IN EACH AND EVERY PATH OF

MY LIFE FOR MY SUCCESS
(AMEEN)
v
DEDICATION
Our Loving Parents and Respected Teachers, My Brother and My Friends
Whos Support?
Give me Strength
And determination
To Accomplish my Goal
vi
ACKNOWLEDGEMENT
First of all, our deepest gratitude to almighty ALLAH: the most beneficent, compassionate,
most merciful and most gracious whose favor and kindness made it possible for me to
complete this project work.
A very special thanks and appreciation goes to my parents and other family members for
always encouraging me. They really deserve me for enduring my problems with great
patience and love and whose endless prayers are a source of determination for me.
We wish to thank to Mr. Asghar Sir Head of Department for providing me the facility and
best environment to complete my task.
We also greatly indebted to my respectable teacher Madam Hina Sattar for his
supervision, kind support, unforgettable devotion and encouraging behavior.
We are also thankful to all staff members of the Department of Computer Science & IT
for their coordination.
M.Siddique
vii
CONTENTS
DEDICATION........................................................................................................... VI
ACKNOWLEDGEMENT ....................................................................................... VII
ABSTRACT ............................................................................................................... XI
CHAPTER # 1 .............................................................................................................. 1
INTRODUCTION ..................................................................................................... 1
1.1. PROBLEM STATEMENT: ........................................................................................ 2
1.2 PROJECT/PRODUCT FEASIBILITY REPORT:............................................................. 2
1.2.1. Technical Feasibility: ................................................................................... 2
1.2.2.Operational Feasibility: ................................................................................. 2
1.2.3.Economic Feasibility: ................................................................................... 2
1.2.4. Schedule Feasibility: .................................................................................... 2
1.2.5. Specification Feasibility: ............................................................................. 3
1.2.6. Information Feasibility: ............................................................................... 3
1.2.7. Motivational Feasibility: .............................................................................. 3
1.2.8. Legal & Ethical Feasibility: ......................................................................... 3
1.3. PROJECT SCOPE: ................................................................................................... 3
1.4. TOOLS AND TECHNOLOGY: .................................................................................. 4
1.4.1 Front-End Technology (ASP.Net 2010): ...................................................... 4
1.4.2.Back-End Technology (SQL Server 2008): .................................................. 5
1.5. VISION DOCUMENT: ............................................................................................. 6
1.6. RISK LIST: ............................................................................................................ 6
CHAPTER 2 ................................................................................................................. 8
REQUIREMENT ANALYSIS .................................................................................... 8
2.1. SYSTEM SPECIFICATION: ...................................................................................... 9

2.1.1. Summary of Requirements (Initial Requirements): ..................................... 9
2.2. IDENTIFYING EXTERNAL ENTITIES: ...................................................................... 9
2.2.1. Over Specify Entities from Abstract: ........................................................... 9
2.2.2. Refined Entities:......................................................................................... 10
2.3. USER CHARACTERISTICS: ................................................................................... 11
2.4. ALLOCATE REQUIREMENTS:............................................................................... 12
viii
2.5 PRIORITIZE REQUIREMENTS: ......................................................................... 13

2.6. REQUIREMENTS TRACEABILITY MATRIX: .......................................................... 15
CHAPTER # 3 ............................................................................................................ 17
OBJECT ORIENTED ANALYSIS AND DESIGN ................................................ 17
3.1. USE CASE DESCRIPTION: .................................................................................... 19

3.2. SYSTEM SEQUENCE DIAGRAM: ..................................................................... 45
3.3. SEQUENCE DIAGRAM: ........................................................................................ 59
3.4. STATE DIAGRAM: ............................................................................................... 72
DATEBASE INTERNAL &TECHNICAL DESIGN ............................................. 75
4.1. INTRODUCTION OF DATABASE: ........................................................................... 76

4.2. DATABASE SYSTEM: ........................................................................................... 76
4.2.1. Database Management System (DBMS): .................................................. 76
4.2.2. DBMS Approach: ...................................................................................... 77
4.2.3 Three-Level Architecture ............................................................................ 78
4.2.4. Data: ........................................................................................................... 78
4.2.5. Hardware: ................................................................................................... 78
4.2.6. Software: .................................................................................................... 78
4.2.7. Users: ......................................................................................................... 79
4.3. ADVANTAGES OF DATABASE: ............................................................................. 79
4.3.1. Data Security:............................................................................................. 79
4.4. BENEFITS OF DATABASE APPROACH: .................................................................. 80
4.5. DATA INDEPENDENCE: ....................................................................................... 80
4.6. DATA INTEGRITY:............................................................................................... 81
4.6.1. Entity integrity: .......................................................................................... 81
4.6.2. Referential integrity: .................................................................................. 81
4.6.3. Domain integrity: ....................................................................................... 81
4.7 . IDENTIFICATION OF ENTITIES: ........................................................................... 82
4.8. ATTRIBUTE: ....................................................................................................... 83
4.8.1 Primary key attributes: ............................................................................. 83
4.9. NORMALIZATION: ......................................................................................... 84
4.9.1 First Normal Form: .................................................................................. 85
4.9.2 Second Normal Form: .............................................................................. 86
ix
4.9.3 Third Normal Form: ................................................................................. 86

4.10. DATABASE DESIGN: .......................................................................................... 87
4.11. DATA MODELING: ............................................................................................ 87
4.12. SNAP SHOT OF TABLES:- ............................................................................ 97
CHAPTER 5 ............................................................................................................. 102
TESTING .................................................................................................................. 102
5.1. TESTING: .......................................................................................................... 103

5.2. TESTING STRATEGY: ........................................................................................ 103
5.3. TEST CASES ..................................................................................................... 103
5.3.1. Test Case: 1 .............................................................................................. 103
5.2.2. Test Case: 2 .............................................................................................. 104
5.2.3. Test Case: 3 .............................................................................................. 104
5.2.4. Test Case: 4 .............................................................................................. 105
5.2.5. Test Case: 5 .............................................................................................. 106
CHAPTER # 6 .......................................................................................................... 107
USER INTERFACE AND DESIGN ...................................................................... 107
6.1. USER LOGIN ................................................................................................ 107

6.2. LOGIN SAVE ................................................................................................ 107
6.3. MAIN PAGE ................................................................................................. 108
6.4. INVOICE ...................................................................................................... 108
6.5. CITY CODE.................................................................................................. 109
6.6. SALES MAN ................................................................................................ 109
6.7. ADD NEW CUSTOMER ................................................................................. 110
6.8. CUSTOMER TRANSACTION .......................................................................... 110
6.9. CUSTOMER DEBIT NOTE ............................................................................. 111
6.10. CUSTOMER CREDIT NOTE ........................................................................... 111
6.11. ADD VENDOR/COMPANY ............................................................................ 112
6.12. VENDOR/ COMPANY TRANSACTION ............................................................ 112
6.13. ADD NEW STOCK ITEM ............................................................................... 113
6.14. ADD STOCK ................................................................................................ 113
6.15. CRYSTAL REPORT INVOICE: ........................................................................ 114
x
ABSTRACT
Student Project Management and Information system is a model system which
manages the projects and stores their information. It lacked a proper system to
manage the projects of students and store their information. Their earlier system was
manual and they had to maintain a separate register to manage the projects. This
resulted in a waste of time and required enhanced efforts to keep the record of the
projects. This Web Site provides the complete solution for their needs it is constructed
according to their specification and requirements. We provide WEB data entries and
updates for projects information and management.
Project Management and Information System tell how projects are managed. Our
system tell whole procedure which is made on project during its compilation.
Our system also provides searching facility. In our system user can search any project.
Rights in our project are given three type of user. One is Administrator other one is
Supervisor (Internal) user And Third One is Student (Enrolled). Visitors user only
gets information about project. But administrator can change in project. Our System
tells Which Student did which project in which session. This was the external of him
or her.
xi
CHAPTER # 1
INTRODUCTION
1.1. Problem Statement
1.2. Project Feasibility
1.3. Project Scope
1.4. Tools and Technology
1.5. Vision Document
1.6. Risk List
1
The system which I am going to develop as my final project is the Medicine

Management System. This document is developed to serve as a starting point of the
software development process.
1.1. Problem Statement:

The existing system uses the concepts and basis of conventional system with clerical
office and clerical staff to maintain information. The existing system works manually.
The firm itself has to maintain, manage and set policies from the format and maintain
data. This project work is related to the development of Medicine Management
System. This project is built because the existing system is manual and is not efficient
to provide all information in due time.
1.2 Project/Product Feasibility Report:
1.2.1. Technical Feasibility:

The system which is to be developed is Desktop based, and ASP.Net technology
along with MySQL will be used to develop it. The project team has got the status to
use these technologies. The software required for doing this project is easily available.
1.2.2. Operational Feasibility:

The staff that will be designed software so that it is easy to use. They will additionally
provide with help and guidance (if needed) to operate the software.
1.2.3. Economic Feasibility:

There is no need for purchasing the tools and license used during the development of
the project. All tool and technologies that are required during development are already
with the development team. This makes the development economically feasible. Only
costing factor is the effort of the project members and time that is utilized in project
development. The maintenance cost and operation cost is there.
1.2.4. Schedule Feasibility:

Time is an important factor. I have got the required resources to complete the project
on time. I am in the final semester of my program and there is sufficient time
available to me for completing this project on the required date and time.
2
1.2.5. Specification Feasibility:

The project team has a clear picture of what we have to develop and what the system
must have in it to be successful. The project team will have a complete and clearer
picture when we are through with the requirements specification and gathering phase.
The requirements are becoming clearer and definite with the passage of time.
1.2.6. Information Feasibility:

The information regarding its completion, reliability, and meaningfulness is ensured
by the use of the Internet, books, and software development requirements. The project
will itself be informative and helpful to the concerned authorities after completion.
1.2.7. Motivational Feasibility:

The clients staffs that will actually using the system are motivated to use this system
as one of the goals of the system is helping them with their work.
1.2.8. Legal & Ethical Feasibility:

The system is free of any infringements or liabilities. It is not violating any legal or
ethical values.
1.3. Project Scope:

This project has following aspects that help the administration of transport system:
1. To manage the record of all medicine and their information.

2. To manage the record of all work orders and their information.
3. To search particular record in database and Generate different reports from
time to time as required.
4. Ensure that the available date is secure from any intentional of
unintentional changes.
5. A centralized database.
6. It is not costly, only single computer is sufficient to manage the whole
record.
7. It is not a time consuming system & needs only a single person with little
computer literacy.
8. It is easy to add or remove new records according to the requirements
easily.
3
9. Redundancy problem is solved because information stored on a single place
1.4. Tools and Technology:

Project of medicine management system is complex software, which makes selection
of the technologies required for the implementation of the project, crucial and
important.
1.4.1 Front-End Technology (ASP.Net 2010):
History
After four years of development, and a series of beta releases in 2000 and 2001,
ASP.NET 1.0 was released on January 5, 2002 as part of version 1.0 of the .NET
Framework. Even prior to the release, dozens of books had been written about
ASP.NET,[2] and Microsoft promoted it heavily as part of its platform for Web
services. Scott Guthrie became the product unit manager for ASP.NET, and
development continued apace, with version 1.1 being released on April 24, 2003 as a
part of Windows Server 2003. ASP.NET is loosely based on HTML. This release
focused on improving ASP.NET's support for mobile devices.
Characteristics
ASP.NET Web pages, known officially as Web Forms, are the main building blocks
for application development. Web forms are contained in files with a ".aspx"
extension; these files typically contain static (X) HTML markup, as well as markup
defining server-side Web Controls and User Controls where the developers place all
the rc content [further explanation needed] for the Web page. Additionally, dynamic
code which runs on the server can be placed in a page within a block <% -- dynamic
code -- %>, which is similar to other Web development technologies such as PHP,
JSP, and ASP. With ASP.NET Framework 2.0, Microsoft introduced a new code-
behind model which allows static text to remain on the .aspx page, while dynamic
code remains in an .aspx.vb or .aspx.cs or .aspx.fs file (depending on the
programming language used).
4
Directives
A directive is a special instruction on how ASP.NET should process the page. [6] the
most common directive is <%@ Page %> which can specify many attributes used by
the ASP.NET page parser and compiler.
1.4.2.Back-End Technology (SQL Server 2008):

During the development of the .NET Framework, the class libraries were originally
written using a managed code compiler system called Simple Managed C (SMC. In
January 1999, Anders Hejlsberg formed a team to build a new language at the time
called Cool, which stood for "C-like Object Oriented Language. Microsoft had
considered keeping the name "Cool" as the final name of the language, but chose not
to do so for trademark reasons. By the time the .NET project was publicly announced
at the July 2000 Professional Developers Conference, the language had been renamed
C#, and the class libraries and ASP.NET runtime had been ported to C#.
C#'s principal designer and lead architect at Microsoft is Anders Hejlsberg, who was
previously involved with the design of Turbo Pascal, Embarcadero Delphi (formerly
CodeGear Delphi, Inprise Delphi and Borland Delphi), and Visual J++. In interviews
and technical papers he has stated that flaws[citation needed] in most major
programming languages (e.g. C++, Java, Delphi, and Smalltalk) drove the
fundamentals of the Common Language Runtime (CLR), which, in turn, drove the
design of the C# language itself.
The ECMA standard lists these design goals for C#.
The C# language is intended to be a simple, modern, general-purpose, object-oriented

programming language.
The language, and implementations thereof, should provide support for software
engineering principles such as strong type checking, array bounds checking, detection
of attempts to use uninitialized variables, and automatic garbage collection. Software
robustness, durability, and programmer productivity are important.
The language is intended for use in developing software components suitable for
deployment in distributed environments.
5
Source code portability is very important, as is programmer portability, especially for

those programmers already familiar with C and C++.
Support for internationalization is very important.
C# is intended to be suitable for writing applications for both hosted and embedded
systems, ranging from the very large that use sophisticated operating systems, down
to the very small having dedicated functions.
Although C# applications are intended to be economical with regard to memory and
processing power requirements, the language was not intended to compete directly on
performance and size with C or assembly language.
Microsoft Project:
MS Project is Medicine management software that is ideal for the designing and
documentation of large projects. MS Project is designed to assist project managers in
developing plans, assigning resources to tasks, tracking progress, managing budgets
and analyzing workloads.
Microsoft Visio:
Microsoft Visio is used to make diagrams for design phase and documentation.
1.5. Vision Document:

The main objective of Medicine Management System is provide full information
about Medicine scheduling, The focus of the application is on the management of the
Medicine System for the Administrator of Project system and it does not dealing and
solving the student related problems about Project so the scope of the project is
restricted in that way. The overall application is English instructed program to
increase the mobility of program.
Only authorized administrator can update, delete, edit, search and change any records.
The essence of requirements was to develop a flexible Medicine information system

which can be used at for administration, who wants to get information.
1.6. Risk list:

The possible risks that can occur during the course of the project are listed below:
6
Sr# Risks Risk Type Probability Mitigation Actions

1. The schedule pressure can Schedule Risk 50% We have divided the whole
force some function points process in modules.
to be changed or dropped All activities are listed on the
from being implemented network diagram with proper
as planned in the planning planning, and sufficient time
phase. allocated to each activity.
2. The requirements can Scope Risk 40% Sufficient time is provided
change over time. for requirement elicitation.
The applicable changes will
be handled if possible.
3. The product scope can Scope Risk 30% The product will be built by
keep expanding. using relatively independent
modules so that any new
functionality can be added.
4. The transaction time can Technological 25% A relatively simple and
be a bit higher depending Risk efficient solution will be
upon the internet speed found and tried.
5. This is the largest project Organization 15% Experienced people in the
the team has ever Risk related fields will be
attempted, so it can result consulted.
in some pressures and Lack of experience will be
problems because of the reduced by the usage of
lack of experience. knowledge and technology.
6. Although the team People Risk 15% Experienced people in the
members have appropriate related fields will be
skills, but they have not consulted.
used their skills on such a
broader scope.
7. The users of the system Technological 10% The user will be provided
might need some time to Risk with sufficient on the hands
get familiarize with the help to learn the usage of the
system system early and easily.
7
CHAPTER 2
REQUIREMENT ANALYSIS
2.1. System Specification
2.2. Identifying External Entities
2.3. User Characteristics
2.4. Allocate Requirements
2.5. Prioritize Requirements
2.6. Requirements Traceability Matrix
8
In this chapter we have discussed requirements engineering process, which provides

the appropriate mechanism for understanding what the customer wants, analyzing
needs, assessing feasibility, negotiating a reasonable solution, specifying the solution
unambiguously, validating the specification and managing the requirements as they
are transformed into an operational system.
1. Requirements elicitation
2. Requirements analysis and negotiation
3. Requirements specification
4. System modeling
5. Requirements validation
6. Requirements management
Here, requirements specification is to be discussed. Requirements specification would
lead to the following steps:
1. Identify external interfaces
2. Development of context diagram
3. User characteristics
4. Allocate requirements
5. Prioritize requirements
6. Development of requirements traceability matrix
2.1. System Specification:
2.1.1. Summary of Requirements (Initial Requirements):
2.2. Identifying External Entities:

The identification of the external entities is based on the information contained in the
above abstract. The Identification of External entities is done in two phases.
2.2.1. Over Specify Entities from Abstract:

1. Invoice
2. Customer
3. Vendor/ Company
4. Sale Man
5. City Code
9
6. Customer Transaction
7. Customer Type
8. Vendor Transaction
9. Stock
10. Stock Items
11. Debit Note
12. Credit Note
2.2.2. Refined Entities:

After refining the entities we found the following entities to fit our Business Logic.
1. Maintenance Detail
2. Maintenance Item
10
2.3. User Characteristics:
Sr # Initial Requirements
1.0 DB Admin login to the system
1.0 DB Admin shall register all users.
1.0 DB Admin shall update database.
2.0 DB admin shall inert the city code.
2.0 DB Admin shall modifying the city code
2.0 DB admin shall inert the credit note
2.0 DB Admin shall modifying the credit note
2.0 DB admin shall inert the Customer
2.0 DB Admin shall modifying the customer
2.0 DB admin shall inert the customer transection
2.0 DB admin shall modifying the customer transection
2.0 DB admin shall inert the customer type
2.0 DB admin shall modifying the customer type
2.0 DB admin shall inert the debit name
2.0 DB admin shall modifying the debit name
2.0 DB admin shall inert the invoice
2.0 DB admin shall modifying the invoice
2.0 DB admin shall inert the salesman
2.0 DB admin shall modifying the salesman
2.0 DB admin shall inert the stock
2.0 DB admin shall modifying the stock
2.0 DB admin shall inert the stock item
2.0 DB admin shall modifying the stock item
2.0 DB admin shall inert the vendor
2.0 DB Admin shall modifying the vendor
2.0 DB admin shall inert the vendor transection
11
2.4. Allocate Requirements:
Sr # Initial Requirements Use Case Name
1.0 DB Admin login to the system UC_Admin Login

1.0 DB Admin shall register all users. UC_Register
1.0 DB Admin shall update database. UC_Update
2.0 DB admin shall inert the city code. UC_insert city code
2.0 DB Admin shall modifying the city code UC_modifying city code
2.0 DB admin shall inert the credit note UC_insert credit note
2.0 DB Admin shall modifying the credit note UC_modifying credit note
2.0 DB admin shall inert the Customer UC_insert customer
2.0 DB Admin shall modifying the customer UC_modifying customer
2.0 DB admin shall inert the customer transection UC_insert transection
2.0 DB admin shall modifying the customer transection UC_modifying transection
2.0 DB admin shall inert the customer type UC_insert customer type
2.0 DB admin shall modifying the customer type UC_modifying customer type
2.0 DB admin shall inert the debit name UC_insert debit name
2.0 DB admin shall modifying the debit name UC_modifying debit name
2.0 DB admin shall inert the invoice UC_insert invoice
2.0 DB admin shall modifying the invoice UC_modifying invoice
2.0 DB admin shall inert the salesman UC_insert salesman
2.0 DB admin shall modifying the salesman UC_modifying salesman
2.0 DB admin shall inert the stock UC_insert stock
2.0 DB admin shall modifying the stock UC_modifying stock
2.0 DB admin shall inert the stock item UC_insert stock items
2.0 DB admin shall modifying the stock item UC_modifying stock items
2.0 DB admin shall inert the vendor UC_insert vendor
2.0 DB Admin shall modifying the vendor UC_modifying vendor
2.0 DB admin shall inert the vendor transection UC_insert vendor transection
2.0 DB Admin shall modifying the vendor transection UC_modifying vendor
transection
12
2.5 Prioritize Requirements:
Sr# Rank Initial Requirements Use Case ID Use Case Name
1.0 High DB Admin login to the system UC_01 UC_Admin Login
1.0 High DB Admin shall register all users. UC_02 UC_Register
1.0 High DB Admin shall update database. UC_03 UC_Update
2.0 Medium DB admin shall inert the city code. UC_04 UC_insert city code
2.0 Medium DB Admin shall modifying the city UC_05 UC_modifying city code
code
2.0 Medium DB admin shall inert the credit note UC_07 UC_insert credit note
2.0 Medium DB Admin shall modifying the credit UC_08 UC_modifying credit note
note
2.0 Medium DB admin shall inert the Customer UC_09 UC_insert customer
2.0 Medium DB Admin shall modifying the UC_10 UC_modifying customer

customer
2.0 Medium DB admin shall inert the customer UC_11 UC_insert transection
transection
2.0 Medium DB admin shall modifying the UC_12 UC_modifying transection

customer transection
2.0 Medium DB admin shall inert the customer UC_13 UC_insert customer type
type
2.0 Medium DB admin shall modifying the UC_14 UC_modifying customer type
customer type
2.0 Medium DB admin shall inert the debit name UC_15 UC_insert debit name
2.0 Medium DB admin shall modifying the debit UC_16 UC_modifying debit name
name
2.0 Medium DB admin shall inert the invoice UC_17 UC_insert invoice
2.0 Medium DB admin shall modifying the UC_18 UC_modifying invoice

invoice
2.0 Medium DB admin shall inert the salesman UC_19 UC_insert salesman
13
2.0 Medium DB admin shall modifying the UC_20 UC_modifying salesman

salesman
2.0 Medium DB admin shall inert the stock UC_21 UC_insert stock
2.0 Medium DB admin shall modifying the stock UC_22 UC_modifying stock
2.0 Medium DB admin shall inert the stock item UC_23 UC_insert stock items
2.0 Medium DB admin shall modifying the stock UC_24 UC_modifying stock items
item
2.0 Medium DB admin shall inert the vendor UC_25 UC_insert vendor
2.0 Medium DB Admin shall modifying the UC_26 UC_modifying vendor

vendor
2.0 Medium DB admin shall inert the vendor UC_27 UC_insert vendor transection
transection
2.0 Medium DB Admin shall modifying the UC_28 UC_modifying vendor

vendor transection transection
14
2.6. Requirements Traceability Matrix:
Sr # No # Initial Requirements Build Use Case Name Category
1 1.0 DB Admin login to the system B1 UC_Admin Login Business
2 1.0 DB Admin shall register all B1 UC_Register Business

users.
3 1.0 DB Admin shall update B1 UC_Update Business
database.
4 2.0 DB admin shall inert the city B1 UC_insert city code Business
code.
5 2.0 DB Admin shall modifying the B1 UC_modifying city code Business
city code
7 2.0 DB admin shall inert the credit B1 UC_insert credit note Business
note
8 2.0 DB Admin shall modifying the B1 UC_modifying credit note Business
credit note
9 2.0 DB admin shall inert the B1 UC_insert customer Business
Customer
10 2.0 DB Admin shall modifying the B1 UC_modifying customer Business
customer
11 2.0 DB admin shall inert the B1 UC_insert transection Business
12 2.0 DB admin shall modifying the B1 UC_modifying transection Business
13 2.0 DB admin shall inert the B1 UC_insert customer type Business
customer type
14 2.0 DB admin shall modifying the B1 UC_modifying customer Business
customer type type
15 2.0 DB admin shall inert the debit B1 UC_insert debit name Business
name
16 2.0 DB admin shall modifying the B1 UC_modifying debit Business
15
debit name name

17 2.0 DB admin shall inert the invoice B1 UC_insert invoice Business
18 2.0 DB admin shall modifying the B1 UC_modifying invoice Business

invoice
19 2.0 DB admin shall inert the B1 UC_insert salesman Business
salesman
20 2.0 DB admin shall modifying the B1 UC_modifying salesman Business
salesman
21 2.0 DB admin shall inert the stock B1 UC_insert stock Business
22 2.0 DB admin shall modifying the B1 UC_modifying stock Business
stock
23 2.0 DB admin shall inert the stock B1 UC_insert stock items Business
item
24 2.0 DB admin shall modifying the B1 UC_modifying stock Business
stock item items
25 2.0 DB admin shall inert the vendor B1 UC_insert vendor Business
26 2.0 DB Admin shall modifying the B1 UC_modifying vendor Business
vendor
27 2.0 DB admin shall inert the vendor B1 UC_insert vendor Business
transection transection
28 2.0 DB Admin shall modifying the B1 UC_modifying vendor Business
vendor transection transection
16
CHAPTER # 3
OBJECT ORIENTED ANALYSIS AND DESIGN
3.1. Use case Description
3.2. System Sequence Diagram
3.3. Sequence Diagram
3.4. State chart diagram
17
The objective of Object Oriented Analysis and Design is to develop a model that
describes computer software as it works to satisfy a set of requirements. After
understanding the current situation of the problem domain the team is ready to strive
for the solution by using OOAD approach.
Actors:
Following are the actors that interact with Medicine Management System.
Administrator
User (Driver)
Figure:
Administrator: User:
USER
18
3.1. Use case Description:
UC_ID UC_01
UC-Name UC_Login
Pre-Condition:
The administrator and user must have a valid username and password.
Description:
This use case describes how an administrator and user can login the system.
Basic Flow:
1. Admin or user opens the project and run the project.

2. Admin or user enters his username and password and clicks on the Login
button.
3. If admin or user is validated by the system he is shown main form depending
on his privilege level.
4. The admin or user is ready for doing his work.
Alternative Flow:
3. If the username and/or password is wrong the user remains on the same screen.
The user can cancel the process at any time.
Post-Condition: A log is created.
Extensions: None.
19
UC-ID UC-02
UC-Name UC_Register
Pre-Condition: The DB Admin must login in the system with administrator login.
Description: This use case describes the creation of user accounts and addition of
new data in any form i.e. driver and register them so that they can use the system.
Basic Flow:
1. DB Admin clicks on create a new account link.

2. A Window form appears in front of him.
3. DB Admin fills in the required data (i.e. username, password of the user).
4. DB Admin clicks on the save button and exits.
Alternative Flow: The user can cancel the process at any time.
Post-Condition: DB Admin informs the desired person of his username and

password.
Extensions: None.
20
UC-ID UC-03
UC-Name UC_Update
Pre-Condition: The DB Admin must login the system as admin.
Description:
This use case describes how the DB Admin updates any form of the system.
Basic Flow:
1. DB Admin double clicks on the button on the main form

2. DB Admin updates the required information
3. DB Admin clicks on the Update Button of the form.
4. DB Admin clicks on Exit Button
Extensions: None.
21
UC-ID UC-04
UC-Name UC_Insert the City Code
Pre-Condition:
Admin must log in.
Description: This use case describes how admin insert the City Code in the system.
Basic Flow:
1. The admin opens the Party Form from Main Menu.

2. The admin must create the new page name as city code.
3. When the insert so click on the save button.
Alternative Flow: The admin can cancel the process at any time.
Extensions: None.
22
UC-ID UC-05
UC-Name UC_modifying the city code
Pre-Condition:
Admin must log in and open the page which he wants to modify.
Description: This use case describes how Admin can modify the city code and their
all actions.
Basic Flow:
1. Admin opens the driver form from Main Menu.

2. Admin clicks on the campuses button to see the data of all the city code.
3. page opens in front of the admin.
4. Admin clicks the save button or Exit Button.
Alternative Flow:
Extensions: None.
23
UC-ID UC-06
UC-Name UC_Insert the credit note
Pre-Condition:
Admin must log in.
Description: This use case describes how admin insert the credit note in the system.
Basic Flow:

5. The admin must create the new page name as credit note.
Post-Condition:
The Data is entered, update and deleted form the Data Base.
Extensions: None.
24
UC-ID UC-07
UC-Name UC_modifying the credit note
Pre-Condition:
Description: This use case describes how Admin can modify the credit note and their
all actions.
Basic Flow:

2. Admin clicks on the campuses button to see the data of all the credit note.
3. Page opens in front of the admin.
Alternative Flow:
Extensions: None.
25
UC-ID UC-08
UC-Name UC_Insert the customers
Pre-Condition:
Admin must log in.
Description: This use case describes how admin insert the customer in the system.
Basic Flow:

2. The admin must create the new page name as customer.
Post-Condition:
Extensions: None.
26
UC-ID UC-09
UC-Name UC_modifying the customer
Pre-Condition:
Description: This use case describes how Admin can modify the customer and their
all actions.
Basic Flow:

2. Admin clicks on the campuses button to see the data of the entire customer.
Alternative Flow:
Extensions: None.
27
UC-ID UC-10
UC-Name UC_Insert the customer transection
Pre-Condition:
Admin must log in.
Description: This use case describes how admin insert the customer transection in the
system.
Basic Flow:

2. The admin must create the new page name as customer transection.
Post-Condition:
Extensions: None.
28
UC-ID UC-11
UC-Name UC_modifying the customer transectiton
Pre-Condition:
Description: This use case describes how Admin can modify the customer transection
and their all actions.
Basic Flow:

2. Admin clicks on the campuses button to see the data of all the customer
transactions.
Alternative Flow:
Extensions: None.
29
UC-ID UC-12
UC-Name UC_Insert the customer type
Pre-Condition:
Admin must log in.
Description: This use case describes how admin insert the customer type in the system.
Basic Flow:

2. The admin must create the new page name as customer tpye.
Extensions: None.
30
UC-ID UC-13
UC-Name UC_modifying the customer type
Pre-Condition:
Description: This use case describes how Admin can modify the customer type and
their all actions.
Basic Flow:

2. Admin clicks on the campuses button to see the data of all the customer
type.
Alternative Flow:
Extensions: None.
31
UC-ID UC-14
UC-Name UC_Insert the debit note
Pre-Condition:
Admin must log in.
Description: This use case describes how admin insert the debit note in the system.
Basic Flow:

2. The admin must create the new page name as debit note.
Extensions: None.
32
UC-ID UC-15
UC-Name UC_modifying the debit note
Pre-Condition:
Description: This use case describes how Admin can modify the debit note and their all
actions.
Basic Flow:

2. Admin clicks on the campuses button to see the data of all the debit note.
Alternative Flow:
Extensions: None.
33
UC-ID UC-16
UC-Name UC_Insert the invoice
Pre-Condition:
Admin must log in.
Description: This use case describes how admin insert the invoice in the system.
Basic Flow:

2. The admin must create the new page name as invoice.
Extensions: None.
34
UC-ID UC-17
UC-Name UC_modifying the invoice
Pre-Condition:
Description: This use case describes how Admin can modify the invoice and their all
actions.
Basic Flow:

2. Admin clicks on the campuses button to see the data of the entire invoice.
Extensions: None.
35
UC-ID UC-18
UC-Name UC_Insert the salesman
Pre-Condition:
Admin must log in.
Description: This use case describes how admin insert the salesman in the system.
Basic Flow:

2. The admin must create the new page name as salesman.
Extensions: None.
36
UC-ID UC-19
UC-Name UC_ modifying the salesman
Pre-Condition:
Description: This use case describes how Admin can modify the salesman and their
all actions.
Basic Flow:

2. Admin clicks on the campuses button to see the data of the entire salesman.
Alternative Flow:
Extensions: None.
37
UC-ID UC-20
UC-Name UC_ Insert the stock
Pre-Condition:
Admin must log in.
Description: This use case describes how admin insert the stock in the system.
Basic Flow:

2. The admin must create the new page name as stock.
Extensions: None.
38
UC-ID UC-21
UC-Name UC_modifying the stock
Pre-Condition:
Description: This use case describes how Admin can modify the stock and their all
actions.
Basic Flow:

2. Admin clicks on the campuses button to see the data of all the stock.
Alternative Flow:
Extensions: None.
39
UC-ID UC-22
UC-Name UC_Insert the stock items
Pre-Condition:
Admin must log in.
Description: This use case describes how admin insert the stock items in the system.
Basic Flow:

2. The admin must create the new page name as stock items.
Extensions: None.
40
UC-ID UC-23
UC-Name UC_modifying the stock items
Pre-Condition:
Description: This use case describes how Admin can modify the stock items and their
all actions.
Basic Flow:

2. Admin clicks on the campuses button to see the data of all the stock items.
Alternative Flow:
Extensions: None.
41
UC-ID UC-24
UC-Name UC_ Insert the vendor.
Pre-Condition:
Admin must log in.
Description: This use case describes how admin insert the vendor in the system.
Basic Flow:

2. The admin must create the new page name as vendor.
Extensions: None.
42
UC-ID UC-25
UC-Name UC_ modifying the vendor
Pre-Condition:
Description: This use case describes how Admin can modify the vendor and their all
actions.
Basic Flow:

2. Admin clicks on the campuses button to see the data of the entire vendor.
Alternative Flow:
Extensions: None.
43
UC-ID UC-26
UC-Name UC_ Insert the vendor transection
Pre-Condition:
Admin must log in.
Description: This use case describes how admin insert the vendor transection in the
system.
Basic Flow:

2. The admin must create the new page name as vendor transection.
Extensions: None.
44
3.2. System Sequence Diagram:
The UML system sequence diagram (SSD) illustrates events sequentially inputs from
external source to the system. The SSD will define the system events and operations.
System sequence diagrams are a timeline drawing of an expanded use case. Events are
related by time with the top events occurring first. System events are the important
items. These are events that cause a system response.
The System Sequence Diagrams of the Transport Management System of the Islamia
University of Bahawalpur are shown below.
3.5.1 UC_ Login:
SYSTEM
USER
1: Invoke Login Form
2: Show Login Form
3: Login (User Name, Password)
4: Validate(U,P)
5: Invalid Login
6: Show Main Form
45
UC_ City Code:
SYSTEM
USER
1: Invoke Main Form
2: Show Main Form
3.Select CityCods Form From Main Menu
4.Show CityCodes Form
5: Fill Required Fields
6: Action(action)
7: Action()
8: Required Action Performed
46
UC_ Credit Note:
SYSTEM
USER
1: Invoke Main Form
2: Show Main Form
3.Select CreditNote Form From Main Menu
4.Show CreditNote Form
6: Action(action)
7: Action()
47
UC_ Customer:
SYSTEM
USER
1: Invoke Main Form
2: Show Main Form
3.Select Customer Form From Main Menu
4.Show Customer Form
6: Action(action)
7: Action()
48
UC_ Log Out:
SYSTEM
USER
1: Invoke Main Form
2: Show Main Form
3: Select Log Out from Main Form
4: Out from Log Table(Data Adapter)
5: Log Out From System
49
UC_ Customer Transaction:
SYSTEM
USER
1: Invoke Main Form
2: Show Main Form
3.Select Customer Transaction From Main Menu
4.Show Customer
Transaction Form
6: Action(action)
7: Action()
50
UC_ Customer Type:
SYSTEM
USER
1: Invoke Main Form
2: Show Main Form
3.Select Customer Type From Main Menu
4.Show Customer Type

Form
6: Action(action)
7: Action()
51
UC_ Debit Name:
SYSTEM
USER
1: Invoke Main Form
2: Show Main Form
3.Select Debitname From Main Menu
4.Show Debit name Form
6: Action(action)
7: Action()
52
UC_ Invoice:
SYSTEM
USER
1: Invoke Main Form
2: Show Main Form
3.Select Invoice From Main Menu
4.Show Invoice name Form
6: Action(action)
7: Action()
53
UC_ Salesman:
SYSTEM
USER
1: Invoke Main Form
2: Show Main Form
3.Select salesman From Main Menu
4.Show salesman name Form
6: Action(action)
7: Action()
54
UC_ Stock:
SYSTEM
USER
1: Invoke Main Form
2: Show Main Form
3.Select stock From Main Menu
4.Show stock name Form
6: Action(action)
7: Action()
55
UC_ Stock Item:
SYSTEM
USER
1: Invoke Main Form
2: Show Main Form
3.Select stock item From Main Menu
4.Show stock item name Form
6: Action(action)
7: Action()
56
UC_ Vendor:
SYSTEM
USER
1: Invoke Main Form
2: Show Main Form
3.Select Vendor From Main Menu
4.Show Vendor name Form
6: Action(action)
7: Action()
57
UC_ Vendor Transection:
SYSTEM
USER
1: Invoke Main Form
2: Show Main Form
3.Select Vendor transection From Main Menu
4.Show Vendor transection Form
6: Action(action)
7: Action()
58
3.3. Sequence Diagram:

A Sequence diagram depicts the sequence of actions that occur in a system. The
invocation of methods in each object, and the order in which the invocation occurs is
captured in a Sequence diagram. This makes the Sequence diagram a very useful tool
to easily represent the dynamic behavior of a system.
A Sequence diagram is two-dimensional in nature. On the horizontal axis, it shows

the life of the object that it represents, while on the vertical axis, it shows the
sequence of the creation or invocation of these objects.
UC_ log in:
System Screen DB Handler User Screen

USER
1: Login
2: Prompt User Information
3: Enter(username, password)
4: Valid Input
5: Valid input(username, password)
6: Initilaize User Screen
7: Show Main Form
59
UC _City Code:
User User Screen CityCode Page DB Handler
1. Click on the Results Link
2. Prepare CityCode page
3. CityCode page Displayed
4. fille the required fields
5 Click on the Save Button
6. Valid Input
7. input Reqired Data
8. Data Inserted
9. Data Inserted Succesfully
60
UC_ Credit Note:
User User Screen CireditNOte Page DB Handler
2. Prepare CreditNote page
3. CreditNote page Displayed
6. Valid Input
8. Data Inserted
61
UC_ Customer:
User User Screen Customer Page DB Handler
2. Prepare Customer page
3. Customer page Displayed
6. Valid Input
8. Data Inserted
62
UC_ Customer Transection:
Customer Transection
User User Screen DB Handler
Page
2. Prepare Customer Transection page
3. Customer Transection page Displayed
6. Valid Input
8. Data Inserted
63
UC_ Customer Type:
User User Screen Customer Type Page DB Handler
2. Prepare Customer Type page
3. Customer Type page Displayed
6. Valid Input
8. Data Inserted
64
UC_ Debit Name:
User User Screen Debit Name Page DB Handler
2. Prepare DebitName Type page
3. Debit Name page Displayed
6. Valid Input
8. Data Inserted
65
UC_ Invoice:
User User Screen Invoice Page DB Handler
2. Prepare Invoice Type page
3. Invoice page Displayed
6. Valid Input
8. Data Inserted
66
UC_ Salesman:
User User Screen Salesman Page DB Handler
2. Prepare Salesman page
3. Salesman page Displayed
6. Valid Input
8. Data Inserted
67
UC_ Stock:
User User Screen Stock Page DB Handler
2. Prepare Stock page
3. Stock page Displayed
6. Valid Input
8. Data Inserted
68
UC_ Stock Item:
User User Screen Stock Item Page DB Handler
2. Prepare Stock item page
3. Stock item page Displayed
6. Valid Input
8. Data Inserted
69
UC_ Vendor:
User User Screen Vendor Item Page DB Handler
2. Prepare Vendor item page
3. Vendor item page Displayed
6. Valid Input
8. Data Inserted
70
Vendor Transection Item

User User Screen DB Handler
Page
2. Prepare Vendor Transection item page
3. Vendor Transection page Displayed
6. Valid Input
8. Data Inserted
71
3.4. State Diagram:
UC_ City Code:
/ Fill Required Fields
/ Click on CityCode Link

Admin Screen City Code page
UC_ Credit Note:
/ Click on CreditNote Link

Admin Screen CreditNote page
UC_ Customer:
/ Click on Customer Link

Admin Screen Customer page
UC_ Customer Transection:
/ Click on Customer Transection Link

Admin Screen Customer transection page
72
UC_ Customer Type:
/ Click on Customer Type Link

Admin Screen Customer type page
UC_ Debit Name:
/ Click on DebitNAme Link

Admin Screen DebitName page
UC_ Invoice:
/ Click on Invoice Link

Admin Screen Invoice page
UC_ Salesman:
/ Click on Salesman Link

Admin Screen Salesman page
73
UC_ Stock:
/ Click on Stock Link

Admin Screen Stock page
UC_ Stock Item:
/ Click on Stock item Link

Admin Screen Stock Item page
UC_ Vendor:
/ Click on Vendor Link

Admin Screen Vendor page
/ Click on VendorTransection Link

Admin Screen Vendor Transection page
74
CHAPTER # 4
DATEBASE INTERNAL &TECHNICAL DESIGN
4.1. Introduction to Database
4.2. Database system
4.3. Advantages of Database
4.4. Benefits of Database approach
4.5. Data Independence
4.6. Data Integrity
4.7. Identification of Entities
4.8. Attribute
4.9. Normalization
4.10. Database design
4.11. Data Modeling
4.12. Snap-Shots of Table
75
4.1. Introduction of database:

A database is a collection of information that is organized so that it can easily be
accessed, managed, and updated. In one view, databases can be classified according to
types of content: bibliographic, full-text, numeric, and images.
In computing, databases are sometimes classified according to their organizational

approach. The most prevalent approach is the relational database, a tabular database in
which data is defined so that it can be reorganized and accessed in a number of
different ways. A distributed database is one that can be dispersed or replicated
among different points in a network. An object-oriented programming database is one
that is congruent with the data defined in object classes and subclasses.
Computer databases typically contain aggregations of data records or files, such as

sales transactions, product catalogs and inventories, and customer profiles. Typically,
a database manager provides users the capabilities of controlling read/write access,
specifying report generation, and analyzing usage. Databases and database managers
are prevalent in large mainframe systems, but are also present in smaller distributed
workstation and mid-range systems such as the AS/400 and on personal computers.
SQL (Structured Query Language) is a standard language for making interactive
queries from and updating a database such as IBM's DB2, Microsoft's SQL Server,
and database products from Oracle, Sybase, and Computer Associates.
4.2. Database system:

A database system is a term that is typically used to encapsulate the constructs of a
data model, database Management system (DBMS) and database
4.2.1. Database Management System (DBMS):
Stands for Database Management System." In short, a DBMS is a database program.

Technically speaking, it is a software system that uses a standard method of
cataloging, retrieving, and running queries on data. The DBMS manages incoming
data, organizes it, and provides ways for the data to be modified or extracted by users
or other programs.
76
Some DBMS examples include MySQL, PostgreSQL, Microsoft Access, SQL Server,
FileMaker, Oracle, RDBMS, dBASE, Clipper, and FoxPro. Since there are so many
database management systems available, it is important for there to be a way for them
to communicate with each other. For this reason, most database software comes with
an Open Database Connectivity (ODBC) driver that allows the database to integrate
with other databases. For example, common SQL statements such as SELECT and
INSERT are translated from a program's proprietary syntax into a syntax other
databases can understand.
4.2.2. DBMS Approach:

DBMS:
Separation of data and metadata
Flexibility of changing metadata
Program-data independence
Data access language:
Standardized SQL
Ad-hoc query formulation easy
System development:
Less effort required
Concentration on logical level design is enough
Components to organize data storage
Process queries, manage concurrent access, recovery from failures,
manage access control are all available.
77
4.2.3 Three-Level Architecture
4.2.4. Data:
Data is information that has been translated into a form that is more convenient to
move or process. Relative to today's computers and transmission media, data is
information converted into binary digital form.
4.2.5. Hardware:
Hardware is a machine which we use to store access manipulates and manages the
data it consist of following two things
1. The secondary storage volumes typically moving head magnetic tapes.

2. The processor and associated main memory that are used to support the
execution of the database system software.
4.2.6. Software:
The request from users is processed by the DBMS.
78
4.2.7. Users:
a) Application programmer:
An Application programmer is someone who works in many different programming

languages to create the source code, which is responsible for creating small or large
parts of a piece of software in concert with others. Applications programming is the
meat and potatoes of programming, and requires a very creative mind, as well as one
that can retain lots of information about the requirements of the software, the
requirements of their teammates and the code itself.
b) End user:
The second class of user is end user. End-users use the software to assist with some
task. This may be flying an aircraft managing insurance policies, writing a books etc.
They want to know how the software can help them. They are not interested in
computer or administration details. These were final or ultimate user of a computer
system. The end user is the individual who uses the product after it has been fully
developed and marketed
c) Database administrator:
A database administrator (DBA) is a person responsible for the design,

implementation, maintenance and repair of an organization's database. They are also
known by the titles Database Coordinator or Database Programmer, and are closely
related to the Database Analyst.
4.3. Advantages of database:

The advantages for database system over traditional paper based record keeping will
perhaps be more readily apparent in these examples
4.3.1. Data Security:

Data is the most important asset. Therefore, there is a need for data security. Database
management systems help to keep the data secured.
Compactness
No need for possible voluminous paper files.
79
Speed
Machines can retrieve and update data for faster than human can.
Accuracy
Accurate up to date information is available on demand at any time.
4.4. Benefits of database approach:
The benefits of the database approach are as follows
Data Independence
Consistency of Data
Control Over Redundancy
Integrity of Data
Greater Security of Data
Centralized Control of Data
Increased Productivity
Minimal Data Redundancy
Data Sharing
Ease of application development
Enforcement of standards
Data can be shared
Physical data independence
Logical data independence
4.5. Data independence:
Data independence is the type of data transparency that matters for a centralized
DBMS. It refers to the immunity of user applications to make changes in the
definition and organization of data. Physical data independence deals with hiding the
details of the storage structure from user applications. The application should not be
involved with these issues, since there is no difference in the operation carried out
against the data. The data independence and operation independence together gives
the feature of data abstraction.
80
4.6. Data integrity:
Data integrity is data that has a complete or whole structure. All characteristics of the
data including business rules, rules for how pieces of data relate dates, definitions and
lineage must be correct for data to be complete. Data that has integrity is identically
maintained during any operation (such as transfer, storage or retrieval). Put simply in
business terms, data integrity is the assurance that data is consistent, certified and can
be reconciled.
4.6.1. Entity integrity:
Entity integrity concerns the concept of a primary key. Entity integrity is an integrity
rule which states that every table must have a primary key and that the column or
columns chosen to be the primary key should be unique and not null.
4.6.2. Referential integrity:
Referential integrity concerns the concept of a foreign key. The referential integrity
rule states that any foreign key value can only be in one of two states. The usual state
of affairs is that the foreign key value refers to a primary key value of some table in
the database. Occasionally, and this will depend on the rules of the business, a foreign
key value can be null. In this case we are explicitly saying that either there is no
relationship between the objects represented in the database or that this relationship is
unknown.
4.6.3. Domain integrity:
Domain integrity specifies that all columns in relational database must be declared
upon a defined domain. The primary unit of data in the relational data model is the
data item. Such data items are said to be non-decomposable or atomic. A domain is a
set of values of the same type. Domains are therefore pools of values from which
actual values appearing in the columns of a table are drawn.
81
4.7 . Identification of Entities:
Entity is a basic data object in database modeling. Entity can be person, a place, an
event or a thing about which we have to save data in the database. If we assume that
our database is a language then we can say that entities are nouns. Database is a
collection of entities. The first step in database modeling is to identify entities of
database. This is of the major parts in conceptual database modeling. Following are
some characteristics of an entity and it is very important to consider these while
identifying entities.
Each entity should be significant.

Each entity should be generic.
Each entity should be fundamental.
Each entity should be unitary.
a) Significant:
List only entities that are important to your database users and that are worth the
trouble and expense of computer tabulation.
b) Generic:
List only types of things, not individual instances. For instance, symphony might
be an entity, but Beethoven's Fifth would be an entity instance or entity
occurrence
C) Fundamental:
List only entities that were exist independently and do not need something else to
explain them. Anything you might call a trait, a feature, or a description is not an
entity. For example, a part number is a feature of the fundamental entity called
part.
d) Unitary:
Be sure that each entity you name represents a single class. It cannot be separated
into subcategories, each with its own features. In the telephone directory example,
82
the telephone number, an apparently simple entity, actually consists of three

categories, each with different features.
e) Weak entity:
A weak entity is an entity that exists only if is related to a set of uniquely

determined entities, which are called the owners of the weak entity. For instance,
we could extend our library with a weak entity type edition; each book has several
editions, and certainly it is nonsense to speak about an edition if this does not
happen in the context of a specific book. From a user interface viewpoint, weak
entities are usually edited in the context of (one of) their owners. When an entity
is deleted from a schema instance, all owned weak entities are deleted, too. We
shall call the type of a weak entity a weak entity type.
4.8. Attribute:
Entity contains a set of attributes. We can call attributes as properties, features or

quality of the entity. An attributes is smallest information that cant be divided
further. If we say that entity is a table then columns would be attributes.
While defining attributes, we should consider following points.
Attributes should be significant.

Attributes should not be derived.
Attributes should not be decomposable.
Data of attributes should be of same type.
4.8.1 Primary key attributes:
The primary key of a relational table uniquely identifies each record in the table.
It can either be a normal attribute that is guaranteed to be unique (such as Social
Security Number in a table with no more than one record per person) or it can be
generated by the DBMS (such as a globally unique identifier, or GUID, in
Microsoft SQL Server). Primary keys may consist of a single attribute or
multiple attributes in combination.
83
Primary key attributes are given below:
Primary key should be unique

Primary key should not be null.
Primary key should be not updateable.
4.9. Normalization:
Normalization is a process to organize the data in an efficient manner. There are two
basic results which we expect from normalization. First is to remove redundant data
and second is avoid duplicate date to be recorded in database.
Std_id Name Address Subject Credit
1 Ali 2-C D.B 3.0
2 Abi 3-C O.S 3.0
Table2: Maintenance detail Table
Through this example we explain different problems that might occur if the table is
not normalized.
a) Redundant Data:
Just consider that if we want to add a new entry of Maintenance then we has to enter
all the information regarding item again, in the above table, there are only a few
records. Just imagine what will happen where we have to store thousands of records.
b) Modification Anomaly:
Now consider another situation where we have to update the record of maintenance
item then we have to update it at many places, now what would happen when we will
have millions of records.
84
c) Deletion Anomaly:
What if we want to delete any record of any item from above mentioned table, then
we will also lose the information about slip no so what if we want to keep the record
of thesis maintenance information but still want to delete some information ?
d) Insertion Anomaly:
Suppose another situation where we have to insert a new record of thesis maintenance
information but we do not want insert data about vehicle.
To avoid such situations which are described above, we have to normalize the
database.
We can divide the whole normalization process into four steps; until and unless, we
are done with first step we cannot move to next step.
These four steps are given below:
First Normal Form

Second Normal Form
Third Normal Form
Boyce-Codd Normal Form
4.9.1 First Normal Form:

First normal form enforce that the value of each column in table should be atomic
which means there should not be a group of data for one column. To understand
the concept of first normal form just considers the following example where we
want to store the record of suppliers.
Std_id Name Subject Credits Address
1 Abdullah Iqbal D.B 3.0 2-C
2 Siddique O.S 3.0 3-C
Table2: Maintenance detail Table
In This Maintenance Detail table Receipt _no will be a primary key.
85
Hence we can say, in first normalization form, we have to do following things:
Eliminate Redundant Data.

Declare Primary Key.
4.9.2 Second Normal Form:

First of all, to implement second normal form, we have to implement first normal
form. First normal form requires maintaining the atomicity of data and second normal
form requires relationship between the key and non-key attributes.
According to second normal form, all non-key attributes must be dependent on key
attribute. If primary key is composite then non key attribute must depend on all the
key columns.
Understand the concept of second normal form, consider the following example.
Std_id Name Dept Session Status
1 Abdullah Iqbal C.S 2010 Fresh
2 Shahzad Math 2010 Fresh

Akram
Std_id Course Date Completed
1 C# X/Y/Z
2 SQL SERVAR X/Y/Z
4.9.3 Third Normal Form:

Third normal form requires that all the non key attributes should complete depend on
primary key attribute which mean that there should be any transitive dependency in
table attributes.
Transitive dependency means that any non-key attribute is depending on any other
non-key attribute which is depending on key attribute.
86
There is a general rule to find whether your table is in third normal form or not. You
have to identity column which need upgrading when you upgrade any other column in
that table.
Std_id Name Major Advisor
1 Aamir Math ALI
2 Luqman English JAWAAD
Some time, it can make things too complex while implementing these normal form so
best way is to find a balance as when it gets too complex then many DBMS requires
more resource or it can decrease the performance.
4.10. Database design:
A carefully thought-out database design forms the foundation for future success.
These links will help you plan your database designs to maintain performance and
integrity through future growth. Database design is the process of producing a
detailed data model of a database. This logical data model contains all the needed
logical and physical design choices and physical storage parameters needed to
generate a design in a Data Definition Language, which can then be used to create a
database. A fully attributed data model contains detailed attributes for each entity.
4.11. Data Modeling:
Data modeling in software engineering is the process of creating a data model by

applying formal data model descriptions using data modeling techniques. The data
requirements are recorded as a conceptual data model with associated data definitions.
Actual implementation of the conceptual model is called a logical data model.
After creating conceptual database design, you have to represent that by using any
modeling techniques. Currently, there are many modeling tools and techniques are
available which are given below:
Unified Modeling Language(UML)
87
Entity Relationship Diagram(ERD)

Relation Model
Relational Algebra
Here in this document, we are going to discuss entity relationship diagram and
UML as this is the most widely used technique in the world.
a) Entity Relationship Diagram (ERD)
An entity-relationship diagram is a data modeling technique that creates a

graphical representation of the entities, and the relationships between entities,
within an information system. Entity Relationship diagram can also help
developers in initial phases to create better understanding of users requirements.
Now we are going to explain the basic principles to develop entity relationship
diagram.
Identify Entities
Define relationships
Define Cardinality of relationships
Identify Attributes and Primary Keys
Map all Attribute
88
Basic Objects:
Use rectangle to represent an entity
Use Diamand to draw reationalship between two entites
Use Ellipe to represent attributes
Use to Show the linkage
Use to represent for weak entity
Use to show multi valued attributes
----- ------ ---------- -------- Use to represent foreign key attributes
_______________
Us e to mention primary key attribute
89
c) Developing ERD:
To understand the core concept of ERD, consider the Book Wholesale System. There
is following steps for Developing ERD.
Step 1- Identify Entities:
The first step of developing ERD is identifying entities. We can identify following
entities.
1. City Code
2. Credit Note
3. Customer
4. Customer transection
5. Customer type
6. Debit Name
7. Invoice
8. Salesman
9. Stock
10. Stock Items
11. Vendor
12. Vendor transection
Step-2 Identify Relationship:
Second step of Developing ERD is to identify relationship between listed entities.

First of All, we are going to examine which entities have relation between them. So
from problem statement, we can include that physician can given Prescription to
patient and Prescription has medicines for illness. Physician, Patient, medicine has
relationship with prescription and illness has relationship with the medicine as well as
with patients
Step -3 Identify Cardinality:
Cardinality is the original number of occurrences in both entities of relationship. We

can categories cardinality in three groups which are given below.
90
- One to One (1:1)
- One to Many (1: N)
- Many to Many (N: M)
In one to one relation there can be only one occurrence in both entities, for instance
the relationship between person and finger prints pattern will be one to one as a
person can only have one kind of finger prints. In one to many relationships there can
multiple instances in second table against one instance in first table but there will be
only one instance in first table against one instance in second table. Consider the
example of father and kids. A father can have many children but one child will have
only one father. In many to many relationships there can multiple instances in second
table against one instance in first table also there can be multiple instances in first
table against one instance in second table. To understand the concept of many to
many relationship please consider the example of students and courses. A student can
have more than one course and in one course there can be multiple students willing to
attend.
Step-4 Identify Attributes:
The following attributes were identified
Attributes Of users:
UserId Login Password

User(Login)1
PK UserId
Login
User(Login) Password
91
Attributes of City Code:
City Code
Address
Phone No
Salesman Name
Salesman Name Address
Phone NO
CityCode
Attributes Of Credit Note:
CityName Credit Note

CityCode
City Code
City Name
CreditNote
92
Attributes Of Customer:
Amount
InvoiceCode DateTime Customer
CustomerCode Customer Type ID
Invoice Code
Customer
Amount
Date Time
Attribute Of Customer Transection:
CustomerType
CustomerTypeID
Customer
Transection
Customer Type ID
Customer Type
Customer Transection
93
Attribute Of Debit Note:

Debit Note
Date
Debit Document No
CustomerCode DebitAmount
DebitDocument Customer Code

NO
Date
Remarks
Debit Amount
DebitNote
Remarks
Invoice
Attribute of Invoice:
Net Value
Invoice Code
CustomerCode
Salesman Code
ItemCode
SalesmanCo
de Total value Total value
SaleTax
Quntatiy
InvoiceCode Customer code
CustomerDate
Sales tax
Invoice
Netvalue Item Code

Retail price
Quantity
Discount Total amount
Customer Code
Retail price
Total amount
discount
94
Stock code
Attribute of Stock Items:
Item Group name
Vendor Code
Trade mark
Retail price Salesman Code

Description packing
tradeprice
expiry Description
SalesmanCo
VendorCode de
bonus
Trademark
StockCode Trade price

ItemsGroup
name
salestax Expiry
Issuedate Batch name

Bonus
Sales tax
Issue date
Batch name
Attribute of Vendor:
CityCode
Phone Number Vendor
Address
Opening Vendor Code
balance
VendorName Vendor Name
Opening date Address
Vendor City Code

VendorCode
Phone number
Status
Current Opening balance

balance
Status
Current balance
95
Attribute of Vendor transection:

Vendor
Transection Transection
type Amount
VendorCode
Vendor Code
Vendor Vendor Transection

Transection Date
Transection type
Vendor transection
Amount
VendorCode
date
96
4.12. Snap Shot of Tables:-
City code:
Credit Note:
Customer:
97
Customer Transection:
Customer type
Debit Note:
98
Invoice:
Login:
Salesman:
99
Stock table:
Stock items:
100
Vendor:
Vendor transection:
101
Chapter 5
TESTING
5.1. Testing
5.2. Testing Strategy
5.3. Test Cases
102
5.1. Testing:
It is the process used to help identify the correctness, completeness, security, and
quality of developed computer software. Testing is a process of technical
investigation, performed on behalf of stakeholders, that is intended to reveal quality-
related information about the product with respect to the context in which it is
intended to operate.
5.2. Testing Strategy:
Software testing methods are traditionally divided into:
1. White box testing.

2. Black box testing.
This Strategy used for testing is Black Box Testing. Every module is tested and after
the integration of all modules again individually testing is done.
5.3. Test Cases
5.3.1. Test Case: 1
System:
Online job Recruitment system.
Test:
Login form is opened and login and password is entered.
Instructions:
1. Open the main form

2. Enter user name and password.
Expected Result:
Message will appear that please enter correct user name and password.
103
Actual Result:
Error occur with the following message Please enter correct username and password
5.2.2. Test Case: 2
System:
Test:
Main form is opened and username and password is entered to go to a Main Menu.
Instructions:
1. Open the Main Form

2. Select Main Menu to Add student Form.
Expected Result:
Main Information form will be opened.
Actual Result:
Result was as per expected.
5.2.3. Test Case: 3
System:
Test:
Choose Add student Form from Main Menu and Enter Student information and click
Save button.
104
Instructions:
1. Open Student form.

2. Enter Student Information.
3. Click Save button.
Expected Result:
Database will be inserted in the student database.
Actual Result:
5.2.4. Test Case: 4
System:
Test:
Delete Course entry from the course Form.
Instructions:
1. Select required record form the list.

2. Click Delete button.
Expected Result:
Database will be updated and record will be deleted.
Actual Result:
105
5.2.5. Test Case: 5
System: Online job Recruitment system.
.Test:
Update Teacher Form from the Main Form.
Instructions:
1. Open Teacher From.

2. Clicks Update Button.
Expected Result:
Database will be updated and new record is saved.
Actual Result:
Result was as per expected
106
CHAPTER # 6
USER INTERFACE AND DESIGN
6.1. User Login
6.2. Login Save
107
6.3. Main Page
6.4. Invoice
108
6.5. City Code
6.6. Sales Man
109
6.7. Add New Customer
6.8. Customer Transaction
110
6.9. Customer Debit Note
6.10. Customer Credit Note
111
6.11. Add Vendor/Company
6.12. Vendor/ Company Transaction
112
6.13. Add New Stock Item
6.14. Add Stock
113
6.15. Crystal Report Invoice:
114
REFRENCES
Website References:
www.google.com
www.w3schools.com
www.wikipedia.com
115

Medicine Distribution Management System: M. Siddique Roll No 847

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Medicine Distribution Management System: M. Siddique Roll No 847

Uploaded by

Copyright:

Available Formats

Medicine Distribution Management System

MEDICINE DISTRIBUTION MANAGEMENT

Department Of Computer Science & IT

Sir Asghar Sab

Windows 8(64bit) Ultimate

C# /MySql Server 2010

GOD HELPS THOSE WHO HELP THEMSELVES

MAY ALLAH HELP ME IN EACH AND EVERY PATH OF

Our Loving Parents and Respected Teachers, My Brother and My Friends

ACKNOWLEDGEMENT ....................................................................................... VII

REQUIREMENT ANALYSIS .................................................................................... 8

2.1. SYSTEM SPECIFICATION: ...................................................................................... 9

2.5 PRIORITIZE REQUIREMENTS: ......................................................................... 13

OBJECT ORIENTED ANALYSIS AND DESIGN ................................................ 17

3.1. USE CASE DESCRIPTION: .................................................................................... 19

DATEBASE INTERNAL &TECHNICAL DESIGN ............................................. 75

4.1. INTRODUCTION OF DATABASE: ........................................................................... 76

4.9.3 Third Normal Form: ................................................................................. 86

4.12. SNAP SHOT OF TABLES:- ............................................................................ 97

CHAPTER 5 ............................................................................................................. 102

TESTING .................................................................................................................. 102

5.1. TESTING: .......................................................................................................... 103

CHAPTER # 6 .......................................................................................................... 107

USER INTERFACE AND DESIGN ...................................................................... 107

6.1. USER LOGIN ................................................................................................ 107

1.1. Problem Statement

1.2. Project Feasibility

1.3. Project Scope

1.4. Tools and Technology

1.5. Vision Document

1.6. Risk List

The system which I am going to develop as my final project is the Medicine

1.1. Problem Statement:

1.2 Project/Product Feasibility Report:

1.2.1. Technical Feasibility:

1.2.2. Operational Feasibility:

1.2.3. Economic Feasibility:

1.2.4. Schedule Feasibility:

1.2.5. Specification Feasibility:

1.2.6. Information Feasibility:

1.2.7. Motivational Feasibility:

1.2.8. Legal & Ethical Feasibility:

1.3. Project Scope:

1. To manage the record of all medicine and their information.

9. Redundancy problem is solved because information stored on a single place

1.4. Tools and Technology:

1.4.1 Front-End Technology (ASP.Net 2010):

1.4.2.Back-End Technology (SQL Server 2008):

The ECMA standard lists these design goals for C#.

The C# language is intended to be a simple, modern, general-purpose, object-oriented

Source code portability is very important, as is programmer portability, especially for

1.5. Vision Document:

The essence of requirements was to develop a flexible Medicine information system

1.6. Risk list:

Sr# Risks Risk Type Probability Mitigation Actions

2.1. System Specification

2.2. Identifying External Entities

2.3. User Characteristics

2.4. Allocate Requirements

2.5. Prioritize Requirements

2.6. Requirements Traceability Matrix

In this chapter we have discussed requirements engineering process, which provides