基于C#语言(VS平台)+SQL(数据库)物流管理系统

 

 

 

物流管理系统可以说是一个综合性的系统，它集成了系统管理，订单管理，运输管理，客户管理等多种功能，因而具有较强的实用性和先进性。

21世纪以来，人类经济高速发展，人们发生了日新月异的变化，特别是计算机的应用及普及到经济和社会生活的各个领域。使原本的旧的管理方法越来越不适应现在社会的发展。许多人还停留在以前的手工操作。这大大地阻碍了人类经济的发展。为了适应现代社会人们高度强烈的时间观念，物流管理系统软件为物流公司来了极大的方便。随着物流公司规模的不断扩大，物流相关数据急剧增加，有关物流各种信息量也成倍增长。面对庞大的信息量，就需要有物流管理系统来提高物流管理工作的效率。通过这样的系统，可以做到信息的规范管理、科学统计和快速的查询，从而减少人员直接管理方面的工作量。

1)      考虑到操作人员的计算机知识较差,要求有操作简单的人机界面;

2)      由于该系统的使用对象多,要求有较好的权限管理;

3)      原始数据修改简单方便,支持多条件修改

4)      方便的数据查询，支持多条件查询;

5)      在相应的权限下，删除数据方便简单，数据稳定性好；

6)      数据计算自动完成，尽量减少人工干预;

7)      为了用户更好的控制界面，对弹出窗体进行了浏览器式控制。

可行性研究的目的是用最小的代价在尽可能的时间内确定问题是否能够解决。由于本系统管理的对象较多，且每个数据内容具有较强的关联性，涉及的计算过程比较复杂，因此比较适合于采用数据库管理。随着物流公司的规模不断扩大，物流数据急剧增加，有关物流的各种信息量也成倍增长。面对庞大的信息量，就需要有物流管理系统来提高物流管理工作的效率。通过这样的系统，可以做到信息的规范管理、科学统计和快速的查询，从而减少管理方面的工作量。当前物流公司用于物流管理的微机都是PIII以上的机器，在存储量、速度方面都能满足数据库运行的要求。在技术难度方面，由于有指导老师的指导和相关参考文献，特别是网上资料，特别是参考其它程序的功能，因此完全可以实现。

本系统的设计是在Windows XP中文版操作系统环境下，使用Visual Studio 2005中文版开发成功的。数据库是MIS中的重要支持技术，在MIS开发过程中，如何选择数据库管理是一个重要的问题，目前，数据库产品较多，每种产品都具有各自的特点和适用范围，因此，在选择数据库时，应考虑数据库应用的特点及适用范围，本系统选用的数据库语言介绍如下：

Visual Studio 2005语言总的来说，Visual Studio 2005具有以下特点：

Ø        可视化编程：

用传统程序设计语言设计程序时，都是通过编写程序代码来设计用户界面，在设计过程中看不到界面的实际显示效果，必须编译后运行程序才能观察。如果对界面的效果不满意，还要回到程序中修改。有时候，这种编程-编译-修改的操作可能要反复多次，大大影响了软件开发效率。Visual Studio 2005提供了可视化设计工具，把Windows界面设计的复杂性“封装”起来，开发人员不必为界面设计而编写大量程序代码。只需要按设计要求的屏幕布局，用系统提供的工具，在屏幕上画出各种“部件”，即图形对象，并设置这些图形对象的属性。Visual Studio 2005自动产生界面设计代码，程序设计人员只需要编写实现程序功能的那部分代码，从而可以大大提高程序设计的效率。

Ø        面向对象的程序设计

Visual Studio 2005支持面向对象的程序设计，但它与一般的面向对象的程序设计语言(C++)不完全相同。在一般的面向对象程序设计语言中，对象由程序代码和数据组成，是抽象的概念；而Visual Studio 2005则是应用面向对象的程序设计方法(OOP)，把程序和数据封装起来作为一个对象，并为每个对象赋予应有的属性，使对象成为实在的东西。在设计对象时，不必编写建立和描述每个对象的程序代码，而是用工具画在界面上，Visual Studio 2005自动生成对象的程序代码并封装起来。每个对象以图形方式显示在界面上，都是可视的。

Ø        结构化程序设计语言

Visual Studio 2005是在BASIC语言的基础上发展起来的，具有高级程序设计语言的语句结构，接近于自然语言和人类的逻辑思维方式。Visual Studio 2005语句简单易懂，其编辑器支持彩色代码，可自动进行语法错误检查，同时具有功能强大且使用灵活的调试器和编译器。

Visual Studio 2005是解释型语言，在输入代码的同时，解释系统将高级语言分解翻译成计算机可以识别的机器指令，并判断每个语句的语法错误。在设计Visual Studio 2005程序的过程中，随时可以运行程序，而在整个程序设计好之后，可以编译生成可执行文件(.EXE)，脱离Visual Studio 2005环境，直接在Windows环境下运行。

Ø        事件驱动编程机制

Visual Studio 2005通过事件来执行对象的操作。一个对象可能会产生多个事件，每个事件都可以通过一段程序来响应。例如，命令按钮是一个对象，当用户单击该按钮时，将产生一个“单击”(CLICK)事件，而在产生该事件时将执行一段程序，用来实现指定的操作。

在用Visual Studio 2005设计大型应用软件时，不必建立具有明显开始和结束的程序，而是编写若干个微小的子程序，即过程。这些过程分别面向不同的对象，由用户操作引发某个事件来驱动完成某种特定的功能，或者由事件驱动程序调用通用过程来执行指定的操作，这样可以方便编程人员，提高效率。

Ø        访问数据库

Visual Studio 2005具有强大的数据库管理功能，利用数据控件和数据库管理窗口，可以直接建立或处理SQL Server格式的数据库，并提供了强大的数据存储和检索功能。同时，Visual Studio 2005还能直接编辑和访问其他外部数据库，如SQL Server, , Oracle等，这些数据库格式都可以用Visual Studio 2005编辑和处理。

Visual Studio 2005提供开放式数据连接，即ODBC功能，可通过直接访问或建立连接的方式使用并操作后台大型网络数据库，如SQL Server，Oracle等。在应用程序中，可以使用结构化查询语言SQL数据标准，直接访问服务器上的数据库，并提供了简单的面向对象的库操作指令和多用户数据库访问的加锁机制和网络数据库的SQL的编程技术，为单机上运行的数据库提供了SQL网络接口，以便在分布式环境中快速而有效地实现客户/服务器(client/server)方案。

Ø        动态数据交换(DDE)

利用动态数据交换(Dynamic Data Exchange)技术，可以把一种应用程序中的数据动态地链接到另一种应用程序中，使两种完全不同的应用程序建立起一条动态数据链路。当原始数据变化时，可以自动更新链接的数据。Visual Studio 2005提供了动态数据交换的编程技术，可以在应用程序中与其他Windows应用程序建立动态数据交换，在不同的应用程序之间进行通信。

Ø        对象的链接与嵌入(OLE)

对象的链接与嵌入(OLE)将每个应用程序都看作是一个对象(object)，将不同的对象链接(link)起来，再嵌入(embed)某个应用程序中，从而可以得到具有声音、影像、图像、动画、文字等各种信息的集合式的文件。OLE技术是Microsoft公司对象技术的战略，它把多个应用程序合为一体，将每个应用程序看作是一个对象进行链接和嵌入，是一种应用程序一体化的技术。利用OLE技术，可以方便地建立复合式文档(compound document)，这种文档由来自多个不同应用程序的对象组成，文档中的每个对象都与原来的应用程序相联系，并可执行与原来应用程序完全相同的操作。

Ø        动态链接库(DLL)

Visual Studio 2005是一种高级程序设计语言，不具备低级语言的功能，对访问机器硬件的操作不太容易实现。但它可以通过动态链接库技术将C/C++或汇编语言编写的程序加入到Visual Studio 2005应用程序中，可以像调用内部函数一样调用其他语言编写的函数。此外，通过动态链接库，还可以调用Windows应用程序接口(API)函数，实现SDK所具有的功能。

出于本系统是物流管理的一个专一性的系统，本系统的设计目标将最终定位于完成以上所述的物流管理业务的基本模型上。该项目开发的软件为物流管理系统软件,是鉴于目前物流公司数据大量增加,物流公司信息呈爆炸性增长的前提下,物流公司对物流管理的自动化与准确化的要求日益强烈的背景下构思出来的,该软件设计完成后可用于大部分物流公司的物流信息的管理.目前社会上信息管理系统发展飞快,各个企事业单位都引入了信息管理软件来管理自己日益增长的各种信息,物流管理系统也是有了很大的发展,商业化的物流管理软件也不少，但本系统完全独立开发,力求使系统功能简洁明了,但功能齐全且简单易于操作。

该软件是使用Visual Studio 2005在windows xp系统下设计完成的所以只要是兼容windows的软件或是操作系统，该软件都可以正确地运行，有较好的适应能力与兼容性。而且应用户的特殊需求软件在完成后，随时满足用户的使用要求。

 

由于系统较小没有外加模块，因为测试工作比较简单，仅靠数据库的一些基本维护测试措施反复运行即可。

各测试项目说明

1）用户登录窗口的测试

该测试的目的是保证登陆窗口的正确性与在错误发生时的容错与纠错性.具体通过在登陆框中输入空用户名，和错误的用户密码来检测系统的出错运行情况。要求系统在遇到这些情况时能给出正确的错误提示。

2）添加系统用户窗口的测试

该测试的目的是保证添加用户窗口的正确性与在数据输入不正确时的容错与纠错性。具体通过在添加记录框中输入重复的用户名，空用户名和密码来检测系统的出错运行情况。要求系统在遇到这些情况时能给出正确的错误提示。

3）修改用户密码窗口的测试

该测试的目的是保证修改用户密码窗口的正确性与在数据输入不正确时的容错与纠错性。具体通过在修改用户密码框中输入错的原用户密码,以及空的新用户密码,来检测系统的出错运行情况。要求系统在遇到这些情况时能给出正确的错误提示。

4）所有的添加信息窗口的测试

该测试的目的是保证添加客户信息窗口的正确性与在数据输入不正确时的容错与纠错性。具体通过在添加学籍信息框中输入空的信息,已存在的信息，或者错误的日期格式,一些不常用的符号来检测系统的出错运行情况。要求系统在遇到这些情况时能给出正确的错误提示。

5）所有的修改信息窗口的测试

该测试的目的是保证修改信息窗口的正确性与在数据输入不正确时的容错与纠错性。具体通过在修改客户信息框中输入空的信息,已存在的信息，或者错误的日期格式,一些不常用的符号来检测系统的出错运行情况。要求系统在遇到这些情况时能给出正确的错误提示。

6）所有的查询信息窗口的测试

该测试的目的是保证查询信息窗口的正确性与在数据输入不正确时的容错与纠错性。具体通过在查询信息的查询方式框中输入空的查询信息来检测系统的出错运行情况。要求系统在遇到这些情况时能给出正确的错误提示。

7）系统信息窗口的测试

该测试的目的是保证输出的系统信息和作者信息的正确性与完整性。

8） 评价

以上所有的模块测试过程都要求系统能在用户输入出错时给出正确的相应并不影响到数据的安全与完整性。成功的系统设计必须通过以上的要求。

 

在本系统的开发过程中，由于本人是初次开发软件，在知识、经验方面都存在着许多的欠缺，时间也比较仓促。因此，该系统必然会存在一些缺陷和不足。由于对物流管理的整个流程不够熟悉，在需求分析时未能做到完全满足用户的需求。当前物流管理系统的应用正在兴起，支持B/S,C/S的物流管理系统必然是当前乃至未来的重要发展方向，在本次开发过程由于硬件和本人精力、能力方面有限，未能实现B/S功能是我的一个很大的遗憾，因此在以后如果我还会对系统更新的话我一定会尽力弥补我当前存在的问题与不足。

尽管本管理系统存在着很多不足，但其用到接口、扩展能力比较强，易于日后程序更新、数据库管理容易、界面友好、操作方便、效率高、安全性好等优点是本管理系统所必需的。相信物流管理系统将是一套物流公司必不可少的管理软件，通过开发这个系统，我掌握了的项本过程，了解了的基本知识巩固了我对Visual Studio 2005的学习，但在这次毕业设计中的最大收获并不是掌握这几门开发工具的应用，而是学会了设计系统的思维方法，以及与同学们之间相互帮助的精神。

[1] 周佩德.数据库原理及应用.电子工业出版社,2001年4月第一版

[2] 张巍，李静芳。企业物流外包决策[EB/OL].

[3] 田宇，龚国华。第三方物流决策研究[J].物流技术，2000

[4] 崔介何。企业物流[M].北京：中国物资出版社，2002

[5] Visual Studio 2005 Team System专家教程清华大学出版社  2007

[6] Visual Studio 2005技术大全 （美）鲍尔，（美）斯内尔著，人民邮电出版社

[7] 李红等. 管理信息系统开发与应用.电子工业出版社，2003

[8] 周之英缟. 现代软件工程设计.科学出版社，2003

[9] 物流信息系统——现代物流管理系列教材 林自葵 著 北方交通大学出版社 2004

[10] C＃高级编程(第4版) （美）内格尔等著清华大学出版社 2006

[11] 微软院校认证课程系列教程 Microsoft 著 高等教育出版社

在论文即将完成之际，回顾紧张但又充实的学习和开发过程，本人在此向所有关心我的及帮助我的老师和同学们致以我最衷心的感谢。

在本次毕业设计中，我从我的毕业设计指导老师--------张敏老师身上学到了很多东西。他认真负责的工作态度，严谨的治学精神和深厚的理论水平都使我收益匪浅。他无论在理论上还是在实践中，都给与我极大的帮助，使我得到很大的提高，这对于我以后的工作和学习都有一定的帮助，在此真心的感谢他给予我耐心的辅导。在撰写论文阶段，我的一位学长也几次审阅我的论文，提出了许多宝贵意见，在次我也感谢他给我的帮助。

另外，我还要衷心感谢在这几年来所有为教导我付出过辛勤汗水的老师们，你们孜孜不倦的教诲不但让我学到了很多计算机专业方面的知识，而且培养我养成了好的学习方法，还有就是在他们身上学到了做人处事的道理，这些宝贵的东西将在我将来的前进路上如灯塔一样照亮了我前进的方向给予了我前进的力量，在此我对他们表示深深的感谢。还有就是在系统开发过程中，我们同寝室的几位同学都共同的致力于数据库方面项目的制作，在这样的一个环境中我从他们身上也学习到了很多东西，感受到了团队的温暖，对于他们给予的帮助与支持我也向他们致以由衷的感谢。

在此也衷心感谢为评阅本论文而付出辛勤劳动的各位专家和学者！

In this column,we'll explore the internals of SQL Server memory management from a developer's perspective.That is,we'll discuss the way the server manages memory in terms of the APIs and operating system facilities it makes use of and how they work. Exploring a product in this fashion helps us get inside the heads of the developers who built it and helps us understand how they intended it to be used. Understanding how a product works internally and its intended use is key to mastering it.

We'll begin our investigation by first covering some basic Windows memory management fundamentals. Like all 32-bit Windows applications, SQL Server makes use of Windows memory management facilities to allocate, free, and generally manage memory resources. It calls Win32 memory management API functions to interact with the memory resources provided by the operating system in the same way that any Windows application does.

Because nearly all memory allocations within SQL Server make use of virtual memory (rather than heaps), most allocation code eventually resolves to a call to the Win32 VirtualAlloc or VirtualFree API function. The server calls VirtualAlloc to reserve and commit virtual memory and VirtualFree to free virtual memory.

Virtual Memory vs. Physical Memory:

On the x86 family of processors, Windows provides all processes a 4GB virtual memory sandbox in which to play. By "virtual," I mean that the memory isn't memory in the traditional sense. It is merely a range of addresses with no physical storage implicitly associated with it. As a process makes memory allocations, these addresses are used and physical storage is associated with them. However, this physical storage is not necessarily (and not usually) physical memory. It is usually disk drive space. Specifically, it is space in the system paging file(s). This 4GB address space is divided into two partitions: the user mode partition and the kernel mode partition. By default, each of these is sized at 2GB, though you can change this through BOOT.INI switches on the Windows NT® family of the operating system (OS). (Windows NT, Windows 2000, Windows XP, and Windows Server™ 2003 are members of the Windows NT family; Windows 9x and Windows ME are not.)

Memory Regions:

SQL Server organizes the memory it allocates into two distinct regions: the BPool (buffer pool) and MemToLeave (memory to leave) regions. If you make use of AWE memory, there's actually a third region: the physical memory above 3GB made available by the Windows AWE support.

The BPool is the preeminent region of the three. It is the primary allocation pool in SQL Server, serves primarily as a data and index page cache, and is also used for memory allocations less than 8KB. MemToLeave consists of the virtual memory space within the user mode address space that is not used by the BPool. The AWE memory above 3GB functions as an extension of the BPool and provides additional space for caching data and index pages.

So, once SQL Server has started, the BPool has been reserved, but not committed, and the MemToLeave region is essentially free space within the virtual memory address space of the process. As I said earlier, reserved space is just address space—it does not have physical storage behind it until it is committed. Over time, the amount of memory committed to the BPool will increase until it reaches the upper limit computed when the server was originally started.

Monitoring SQL Server Virtual Memory Use

You can track the computed maximum size of the BPool via the SQL Server:Buffer Manager\Target Pages Perfmon counter. Because most of SQL Server's virtual memory usage comes from the BPool, these two counters will, generally speaking, increase or level off in tandem (keep in mind that, when AWE support has been enabled, the Private Bytes counter won't reflect the entirety of SQL Server's memory use). If the Total Pages counter levels off but the Private Bytes counter continues to climb, this usually indicates continued allocations from the MemToLeave region.

Allocations：

A memory consumer within the server initiates a memory allocation by first creating a memory object to manage the request. When the object allocates the request, it calls on the appropriate memory manager within the server to fulfill the request from either the BPool or the MemToLeave region. For requests of less than 8KB, the request is usually filled using memory from the BPool. For requests of 8KB or more of contiguous space, the request is usually filled using memory from the MemToLeave region. However, xprocs are a special exception. When an xproc calls the Open Data Services srv_alloc API function, it is treated just like any other consumer within the server. Generally speaking, srv_alloc requests for less than 8KB of memory are allocated from the BPool. Larger allocations come from the MemToLeave space.

The Memory Manager：

As the server runs, the memory manager checks to make sure that a given amount of physical memory remains available on the server so that Windows and other applications on the server continue to run smoothly.

There is a separate free list for each CPU on the system. When a free page is needed to satisfy an allocation request, the free list associated with the current CPU requesting the allocation is checked first, followed by the lists for the other CPUs on the system. This is done to improve scalability by making better use of the local cache for each processor on a multiprocessor system. You can monitor a specific BPool partition via the SQL Server:Buffer Partition Perfmon object. You can monitor the free list for all partitions via the SQL Server:Buffer Manager\Free Pages Perfmon counter.

So, throughout the time that it runs, SQL Server's memory manager process monitors the memory status of the system to be sure that a reasonable amount of free physical memory remains available to the rest of the system and that a healthy number of free pages remains available for use by new memory allocation requests. The BPool begins by acquiring and locking physical memory on the machine. The amount of memory it locks varies based on whether maximum server memory has been set. If it has, the BPool attempts to lock the amount specified by maximum server memory. If it has not, the BPool locks all of the physical memory on the machine except for approximately 128MB, which it leaves available for other processes. The BPool then uses the physical memory above 3GB (the AWE memory) as a kind of paging file for data and index pages. It maps physical pages from this region into the virtual memory address space as necessary so they can be referenced via 32-bit pointers.