The Warehouse Web Application

The WareHouse Web Application

By: George Kour & Hanny Danial

Contents

Table of figures 4

Abstract 5

Acknowledgement 6

Requirements 7

Project Management 10

Code writing convention 10

Project Hosting 10

SVN 10

TORTISESVN 10

Google Code 11

WareHouse hosting in Google code 11

Working Procedures 11

Wiki Pages 11

Work Plans 14

Defect Handling Procedures 15

Issues Handling 17

Development Environment 18

Microsoft Visual Studio 2008 18

Microsoft SQL Server 2005 18

Technologies 19

ASP.NET 19

ADO.NET 19

AJAX 19

Project Design 20

Database Layer 21

Entity relationship diagram 21

Data Structure Diagram 21

Tables design 22

Data Set 24

Business Logic Layer 25

Events handling class 33

Exception handling 34

User Interface Layer 35

Site Map 35

Master Page 35

Validation Controls 36

ToolTips 37

Security 38

Passwords 38

Passwords in database 38

Password in UI 38

Session Control 39

Concurrency 40

Issues and Decisions: 42

Limitations 43

Supported Environments 44

Server side 44

Client Side 44

Summary 45

Bibliography 46

Table of figures

Figure 1 11

Figure 2 12

Figure 3 17

Figure 4 20

Figure 5 21

Figure 6 21

Figure 7 27

Figure 8 28

Figure 9 31

Figure 10 31

Figure 11 32

Figure 12 33

Abstract

The warehouse application was designed to give a full solution to the warehouse employees and manager. It gives them the ability to manage the warehouse components, Items, users, customers and deliveries.

The main objective of this project is to get the experience of programming in a web based environment which includes a database, using the most popular and common design pattern for such software, the 3-tier design.

This project was developed using the most advanced programming tools. Web 2.0 components, .Net 3.5 frameworks, ASP.Net, AJAX technology and more.

Through the development process we have emphasized the working procedures and the project management. We have set a clear timelines and milestones, defined a defects handling procedures, etc. In addition, we have written many wiki pages to help documenting our work.

Like in real life projects, the system security was one of our top concerns.

Acknowledgement

We want to thank our families especially our parents for supporting us during the development of this project.

We also want to thank Engineer Vicktor Kulikov, our instructor, for the precious information he have passed to us and for his guidance when things wasn’t clear and for his support.

Finally, we would like to thank the Networked Software Systems Lab staff for his valuable support.

Requirements

Our requirement was written in Hebrew.

10 מאי 2009

מסמך דרישות

כללי: המערכת תשמש לניהול מחסן המכיל רכיבים הממוקם בבניין הפקולטה להנדסת חשמל בטכניון.

ממשק משתמש: ממשק המערכת יהיה מבוסס WEB. (WUI)

תפקידי המערכת:

1. ניהול המשתמשים במערכת.

2. ניהול הרכיבים במחסן.

3. ניהול ספקים.

4. ניהול לקוחות.

5. ניהול השאלות של רכיבים ללקוחות.

1. ניהול המשתמשים במערכת.

1. קיימים שני סוגי משתמשים במערכת.

מנהל יחיד של המחסן המשמש גם כמנהל המערכת (להלן: "מנהל המערכת") .
עובדי המחסן שהם משתמשים רגילים במערכת (להלן: "משתמש").

2. עבור כל משתמש במערכת קיימים שם משתמש וסיסמה אשר בעזרתם המשתמש יתחבר למערכת.

3. מנהל המערכת ינהל את המשתמשים במערכת.

4. סמכויות מנהל המערכת:

מנהל המערכת יכול להוסיף משתמש חדש במערכת.
מנהל המערכת יכול לשנות את סיסמתו ואת סיסמת כל אחד ממשתמשי המערכת כולל את סיסמתו הפרטית.
מנהל המערכת יכול לעדכן פרטי משתמש במערכת.
מנהל המערכת יכול למחוק משתמש קיים במערכת.
שאילתות המבוצעות ע"י מנהל המערכת:
חיפוש משתמש לפי כל אחת מתכונות המשתמש.

5. ניתן יהיה להפיק דו"ח עבור כל אחת מהשאילתות לעיל.

2. ניהול הרכיבים במחסן.

1. המערכת תשמור נתונים אודות רכיבים השייכים למחסן.

2. הרכיבים במחסן ממוינים לפי קטגוריות.

3. הרכיבים מסופקים ע"י ספקים. (יש לציין עבור כל רכיב ספק)

4. לכל רכיב קיים תאריך גמר אחריות.

5. קיימים שני סוגי רכיבים – חד פעמיים ורב שימושיים.

6. הרכיבים הרב שימושיים במערכת יכולים להימצא פיזית במחסן או להיות מושאלים ע"י לקוחות המחסן.

7. ניהול מלאי הרכיבים מתבצע ע"י משתמש המערכת.

8. סמכויות המשתמשים הרגילים:

משתמש יכול להכניס רכיב חדש למערכת.
משתמש יכול לעדכן פרטי רכיב במערכת.
עבור רכיבים חד פעמיים ניתן לשנות את הכמות במחסן.
שאילתות המבוצעות ע"י המשתמש:
חיפוש רכיבים ע"י כל אחד מתכונות הרכיב.(קטגוריה,שם, מספר סידורי, מיקום,...)
בדיקת כמות הרכיבים מקטגוריה מסוימת – כמות מושאלת וכמות במחסן.

9. סמכויות מנהל המערכת:

מנהל המערכת יכול לבצע את כל הפעולות שמשתמש רגיל יכול לבצע.
מנהל המערכת יכול להוסיף קטגוריות של רכיבים.
מנהל המערכת יכול למחוק רכיבים מהמערכת.
מנהל המערכת יכול למחוק קטגוריות מהמערכת.

10. המערכת תשלח דוא"ל באופן אוטומטי למנהל המערכת ותודיע לו במקרה ומספר הרכיבים מקטגוריה מסוימת הנוכחים במחסן קטן מהכמות המינימאלית.

11. ניתן יהיה להפיק דו"ח עבור כל אחת מהשאילתות לעיל.

3. ניהול ספקים.

1. המערכת תשמור נתונים אודות הספקים של המחסן.

2. ניהול הספקים מתבצע ע"י משתמשי המערכת.

3. לכל ספק יש לשמור את התכונות הבאות: מס' זיהוי, טלפון, ...

4. סמכויות המשתמשים הרגילים:

משתמש יכול להוסיף ספק למערכת.
משתמש יכול לעדכן פרטי ספקים קיימים במערכת.
שאילתות המבוצעות ע"י המשתמש:
חיפוש ספקים ע"י כל אחד מתכונות הספק.
שליחת דוא"ל לספק.

5. סמכויות מנהל המערכת:

מנהל המערכת יכול לבצע את כל הפעולות שמשתמש רגיל יכול לבצע.
מנהל המערכת יכול למחוק ספקים מהמערכת.

6. ניתן יהיה להפיק דו"ח עבור כל אחת מהשאילתות לעיל.

4. ניהול לקוחות.

1. המערכת תשמור נתונים אודות לקוחות המחסן.

2. הלקוחות במחסן ממוינים לפי סוגים.

3. ניהול הלקוחות מתבצע ע"י משתמשי המערכת.

4. סמכויות המשתמשים הרגילים:

משתמש יכול להוסיף לקוחות למערכת.
משתמש יכול לעדכן פרטי לקוחות קיימים במערכת.
שאילתות המבוצעות ע"י המשתמש:
חיפוש לקוחות ע"י כל אחד מתכונות הלקוח.
שליחת דוא"ל ללקוח.

5. סמכויות מנהל המערכת:

מנהל המערכת יכול לבצע את כל הפעולות שמשתמש רגיל יכול לבצע.
מנהל המערכת יכול למחוק לקוחות מהמערכת.
מנהל המערכת יכול להוסיף סוגי לקוחות חדשים במערכת.

6. ניתן יהיה להפיק דו"ח עבור כל אחת מהשאילתות לעיל.

5. ניהול השאלות של רכיבים ללקוחות.

1. המערכת תשמור מידע אודות השאלות של רכיבים ללקוחות ע"י משתמשי המערכת.

2. עבור רכיבים רב שימושים: כל השאלה של רכיב היא ללקוח בתאריך מסוים עם תאריך החזרה.

3. עבור רכיבים חד פעמיים: לא קיים תאריך חזרה.

4. ניהול ההשאלות יתבצעו ע"י משתמשי המערכת.

5. סמכויות משתמשים רגילים:

השאלה של רכיב במחסן ללקוח. (או נתינה של רכיב חד פעמי)
עדכון כי רכיב מושאל הוחזר למחסן.
שינוי מועד החזרה של רכיב מושאל.
שאילתות המבוצעות ע"י המשתמש:
מהם הרכיבים המושאלים ע"י לקוח נתון.
מיהו הלקוחות שהשאילו רכיב נתון ומתי.
מיהם הלקוחות שהשאילו רכיבים מקטגוריה נתונה.
מתי מוחזר רכיב נתון.
מהם הרכיבים שהושאלו ע"י משתמש נתון ולמי.
המשתמש יוכל לקבל מידע לגבי ההשאלות שהתבצעו בטווח תאריכים נתון.
המשתמש יוכל לקבל מידע לגביל ההשאלות שאמורות לחזור בטווח תאריכים נתון .

6. סמכויות מנהל המערכת:

מנהל המערכת יכול לבצע את כל הפעולות שמשתמש רגיל יכול לבצע.

7. המערכת תשלח דוא"ל באופן אוטומטי ללקוח שעליו להחזיר רכיב כשבוע לפי מועד ההחזרה כמוכן תשלח למשתמש שהשאיל את הרכיב העתק של הודעה זו.

8. ניתן יהיה להפיק דו"ח עבור כל אחת מהשאילתות לעיל.

Project Management

To manage our project we have assisted some web tools.

Code writing convention

We have used the naming convention described in irritatedvowel web site in the following article: NET Programming Standards and Naming Conventions

Project Hosting

SVN

It is used to maintain current and historical versions of files such as source code, web pages, and documentation. Its goal is to be a mostly-compatible successor to the widely used Concurrent Versions System (CVS).

TORTISESVN

TortoiseSVN is a really easy to use Revision control / version control

Source control software for Windows. It is based on Subversion. TortoiseSVN provides a nice and easy user interface for Subversion.

It is developed under the GPL. Which means it is completely free, including the source code. But just in case you don't know the GPL too well: you can use TortoiseSVN to develop commercial applications or just use it in your company without any restrictions.

Since it's not integration for a specific IDE like Visual Studio, Eclipse or others, you can use it with whatever development tools you like.

As a Subversion client, TortoiseSVN has all the features of Subversion itself, including:

· Most current CVS features.

· Directories, renames, and file meta-data are versioned.

· Commits are truly atomic.

· Branching and tagging are cheap (constant time) operations.

· Efficient handling of binary files.

Google Code

Google Code runs a project hosting service that provides revision control offering both Subversion and Mercurial , an issue tracker, a wiki for documentation, and a file download feature. The service is available and free for all Open Source projects that are licensed under one of nine licenses (Apache, Artistic, BSD, GPLv2, GPLv3, LGPL, MIT, MPL and EPL). The site limits the number of projects one person can have to 25. Additionally, there is a limit as to the number of projects that may be created in one day.

WareHouse hosting in Google code

The URL to the project home in Google code is: http://code.google.com/p/webwarehouseapp/

Working Procedures

Wiki Pages

As mentioned above, Google code project hosting offers wiki section.

Figure 1

Figure 2

Example of a wiki page:

TipsAndTricks

Common problems/issues and fixes

Introduction

This page contains tips and tricks to fix frequent defects in our beautiful project.

When you find a fix to some common problem please write down the problem's description and fix in this page to avoid the situation of both of us looking for the same fix to the same issue.

Guid in BLL

In our implementation the update function in the business logic gets an GUID parameter as a string and then pass it to the DAL as GUID. This causes a problem with the DetailesView.

Fix: the update function should get the a GUID as a parameter!

The GUI can pass a Guid so the parameter of the BLL should be Guid and not string and thus avoid the

New GuId(bla_bla)

code in the body of the functions in the BLL.

Parameters names in the BLL

In our initial implementation, the names of the parameters in the BLL didn't match the names of the parameters of the Dal so when you work on a page, fix the corresponding BLL file. This may avoid a lot of problems in the pages.

Entities Num

We have to decide where to show the Num (guid) field and where to invisible it. In both cases you should not delete it from the detailsview beacause its being use by the update and delete functions. So you can just invisible it.

databound function in grid view

Watch and learn:

foreach (GridViewRow row in LendGridView.Rows)
{
Label user = (Label)row.FindControl("UserLabel");
Label customer = (Label)row.FindControl("CustomerLabel");
Label item = (Label)row.FindControl("ItemLabel");
if (user != null customer != null item != null)
{
UserBLL userBLL = new UserBLL();
CustomerBLL customerBLL = new CustomerBLL();
LendItemBLL lendItemBLL = new LendItemBLL();
try
{
user.Text = userBLL.userGetByNum(new Guid(user.Text))[0].user_name;
customer.Text = customerBLL.CustomerGetByNum(new Guid(customer.Text))[0].customer_name;
item.Text = lendItemBLL.LendItemByNum(new Guid(item.Text))[0].lend_item_serial;
}
finally
{
//TODO
//we should add dispose here
// we need to add dispose function foreach bll
// or maybe the detailsview disposes alone ,
// need to check, because there exists disposing event
}
}
}

Work Plans

Each milestone, we wrote a work plan, that’s including the division of tasks for the near future. This work plan was written as a wiki page in Google code.

Example for a work plan:

Plan for George:

1. Resolve the defect 31 (Ajax user friendly enhancement).

2. Resolve defect 30 add update progress in all mail pages.

3. Resolve defect 27 (research for changing the Ajax combo box ugly style).

Plan for Hanny:

1. Fix all the bugs set to you (mostly regular expression issues).

2. Add title to the excel generated.

3. Suggest enhancements.

Code Freeze: 29.10

by this date all the defects should be fixed.

Stabilization: 30.10-31.10

In the Stabilization period we should try use the system, look for bugs and resolve them immediately. No new features are added in this period.

Working on the book: from 1.11 till 7.11

Working on the presentation: from 8.11 till 11.11

Presentation: we should coordinate with Viktor. Between 13.11 - 20.11

Defect Handling Procedures

Quoted from our wiki:

WorkProcedures
Our Work procedures for debugging the Project
Scope
This WIKI page describes our work procedures in opening a defect, fixing and verifying it.
We have almost completed the heavy code writing of the project, Now, It’s the time for giving the final touch, in other word QA-ing the project.
Motivation
No work can be done beautifully if there is no clear and comprehensible work procedures.
A defect-free software is almost non-exist, but as a (brilliant) software engineers, we should make sure our products contains, as less as possible, defects in its functionality.
Opening a Defect
Assume a developer encounters a mal-functionality in the project.
· If he knows how to fix it, he should fix it immediately.
1. If he thinks that the defect may appear in many other places, he should open a defect describing it, and write down the fix.
2. Mark the defect asVerified.
· Else, he should open a defect and make sure that the responsible developer knows about the defect, by sending mail in the defect CC.
Make sure you classify the defect according to its severity. Note The severity matrix in this page bottom.
Fixing a defect
· If a developer sees a defect in his responsibility area, he should fix it as soon as possible.
· If he plans to fix it in the future he should mark it asAccepted.
· He should write down the fix, to remember for the next time. (most of the bugs are duplicated in many places)
· After the fix, he should mark it as fixed.
Verifying a Defect
· Note: Only the person who opened a defect (owns the defect) can mark it as Verified.
· Assume a developer sees a fixed defect he owns.
1. He should try to reproduce.
2. If it can be reproduced, he should reopen it and write down a comment.
3. Else, he should mark it asverified.
Definitions
User Impact - how does the defect disturbing the user doing his task? How it’s hard to find a workaround.
Failure Likelihood - what is his percentage of users that will encounter the defect.
Severity Matrix
User Impact \ Failure Likelihood / Low / Medium / High
Low / Low / Low / Medium
Medium / Medium / Medium / High
High / Medium / High / Critical

Issues Handling

We have used the issues pane in the Google code site intensively; here we have managed our project defects.