小型超市管理信息系统.doc
《小型超市管理信息系统.doc》由会员分享，可在线阅读，更多相关《小型超市管理信息系统.doc（27页珍藏版）》请在冰点文库上搜索。
课程设计报告
学生姓名：
学号:
学院:
班级:
题目:
小型超市管理信息系统
采购管理子系统分析与设计
王欣
指导教师：
职称:
教授
2011年7月12日
目录
目录
1选课背景 1
1.1背景 1
1.2系统组织结构调查 1
2采购管理系统需求分析 2
2.1采购管理系统的需求陈述 2
2.2需求分析 2
2.2.1功能需求 2
2.2.2性能需求 3
2.3系统需求建模 4
2.3.1确定参与者 4
2.3.2确定用例 4
2.3.3系统用例建模 5
2.3.4用例描述 6
3系统分析 7
3.1系统用例建模 7
3.1.2详细用例描述 9
3.2静态结构模型 10
3.2.1类的识别 10
3.2.2类的关联分析 10
3.2.3类的属性描述 11
3.2.4类图的构建 11
3.3系统动态模型 12
3.3.1系统执行顺序分析 12
3.3.2系统的协作分析 14
3.3.3系统状态分析 16
3.3.4活动分析 16
4系统设计与实现 18
4.1UML体系结构设计 18
4.1.1硬件体系结构设计 18
4.1.2软件体系结构设计 18
4.2对象模型设计 19
4.3系统实现 20
4.3.1组件分析 20
4.3.2配置分析 21
5设计心得体会 22
参考文献 23
i
第1章选课背景
第1章选课背景
1.1背景
超市软件系统从企业运营及管理的实际情况出发，结合当前中国零售业业态发展趋势，顺应了零售行业对信息化的要求，为商业管理信息系统提供了系统全面的技术解决方案。
基于以上原因，超市信息管理系统目前在各个商业领域都发挥了很大的作用，也得到了越来越多的大、中、小型商业企业的应用。
但就目前的应用状况分析，管理系统在中、高端企业得到了广泛的应用和重视，在小型企业、零售店的应用仅局限于信息化的表面层次，没有得到高度的重视。
同时，小企业也因资金发面问题限制了其向更高程度信息化的应用！
本课题以UML建模技术为基础，以小型超市采购系统为分析设计中心，体现出充分利用先进计算机技术、集成化设计超市信息管理系统以方便超市运营为中心的设计思想。
既要适用于当前小型超市的既成管理模式，又可以为提高运作效率提供最有力的支持和保证。
1.2系统组织结构调查
对现行超市管理信息系统进行调查之后，超市管理信息系统主要由采购管理子系统库存管理子系统；销售管理子系统及财务管理子系统组成，其组织机构图如图1.1所示。
销售部门
超市管理信息系统
采购部门
库存部门
财务部门
请购单管理
订购单管理
合同管理
资金请求管理
图1.1超市管理信息系统组织机构图
23
第2章超市管理系统需求分析
第2章采购管理系统需求分析
2.1采购管理系统的需求陈述
商品采购是超市主要业务活动之一。
为了保证企业进行科学的商品采购，超市必须根据自身状况建立相应的采购机构，根据库存量，形成商品请购单，根据商品经营范围、品种，形成商品经营目录，确定采购渠道，进行进货洽谈、签订订货合同，完成商品检验与验收活动。
首先对超市采购管理子系统的需求进行分析：
库存管理人员根据库存信息提交需要采购的商品信息，采购员根据库存人员的要求进行请购单的编写，然后将最后生成的采购单上交给超市经理进行审批，经理审批合格后采购员生成订购单，并联系供货商，采购员根据订购单生成合同，采购方与供货方无异议后签订合同，供货方发货，采购员收到货物根据合同向财务部申请采购资金，财务人员拨款，财务部门向供货商付款，采购员合计部门资金余额，通知库存部门取货，记录采购信息。
通过对超市采购流程的调查，超市采购管理大致分为以下九部分：
用户根据用户名、密码登陆系统，系统可以明确记录库存管理人员向采购部门提出的商品列表，采购员根据列表生成请购单，并可以添加、删除、修改请购单并保存；超市经理接收请购单，审批，若合格采购员继续生成订购单，订购单有商品的详细信息，采购员根据系统中保存的供货商的信息选择合适的供货商，并记录联系，根据订货单生成合同并发给供货商，接收供货商的签订合同后向财务部门进行采购金额的输送，货物到后准确记录采购信息。
2.2需求分析
2.2.1功能需求
采购管理系统是超市管理信息系统的中的一部分。
本系统完成了以下功能：
（1）请购单管理：
包括需求商品的详细信息：
商品号、名称、规格、需求时间等。
接受库存部门的请购信息，供超市经理审批时参照使用。
审批结束后对请购单是否被批准进行分类记录。
（2）订购单管理：
根据审批通过的请购单，生成订购单，除了请购的基本内容外还包括供应商，运输方式，付款方式，付款条件，交货日期等详细情况。
按不同的状态实现订购单的新建、修改、撤销功能。
具体地说，未执行状态下才能新建、撤销订购单，执行状态下的才能修改和撤销，订购单一旦完成，就不允许修改和撤销。
另外也对订购单按状态分类列表记录。
（3）合同管理：
一份订购单生成后对应生成采购合同，订购单号与合同单号对应。
对撤销、执行中、已执行的合同分类列表记录，并且合同状态与订购单状态有效关联；按供应商名称与商品名称提供供应商供货记录查询列表；按供应商名称、商品名称和合同执行时间提供进货数量统计；按合同的付款信息，及时向财务部门反馈用款信息，经批准后更新部门可用资金数目，合同完成后，为库存提供到货信息。
（4）资金请求管理：
生成请购单时核对部门资金余额，订购单完成后向财务部门申请资金，合同完成后更新部门可用资金并付款，采购完成后记录资金余额。
（5）系统管理：
管理员对采购管理子系统进行维护与检测。
（6）查询管理：
对请购单、订购单、合同与资金各个模块管理进行实时查询管理。
2.2.2性能需求
在系统的设计和开发中，以下问题是应该注意的：
新系统应该尽可能地解决现有系统存在的问题。
例如：
减少手工操作和重复劳动，提高计算机管理程度，尽可能的杜绝漏费现象，方便查询、统计，方便数据的管理和备份等等。
系统应具备较好的可维护性，较长的生存期，避免较短的时间内被推倒重来的情况发生。
针对现行超市管理系统运行状况的调查分析结果，建设本超市采购管理系统的性能需求主要有如下几个方面：
1.时间响应特性
查询服务部分：
用户通过电脑提交查询命令到返回结果不超过5秒钟。
数据管理部分：
提交某一数据录入到结果返回不超过5秒钟。
2.数据量大
系统要记录每个学生选课的记录，因此，整个系统对信息量的要求相对较高，开发者应采取相应措施，解决存储量大的问题，同时还要兼顾信息的方便利用。
3.系统实用性：
为了提高系统效率，系统提供了多种形式的对话框，并在设计过程中考虑尽量减少用户的输入。
4.安全可靠性
本系统运行在Internet上，前端通过windows的浏览器进行使用，要考虑可能会受到外来的安全威胁；操作员口令应采用加密存放方式，不同权限的用户对数据有不同层次的访问；要适当的对系统数据进行备份存档，避免数据的丢失带来不便。
5.环境规定
（1）硬件环境
服务器端为一台标准服务器。
客户端包括多媒体电脑、PC客户机等。
（2）软件环境
学生网上选课系统的设计与运行基于采用C/S结构。
后台操作系统为MicrosoftWindowsXP，数据库为MicrosoftSQLServer2000；浏览器为IE6.0以上版本。
6良好的人机交互
在开发中应重视良好人机交互性能的设计，包括更好的引导性界面，更方便的在线帮助提示，更简单的操作方法，更易学、快捷的汉字信息录入等，尽力减少用户文字信息的键盘输入。
2.3系统需求建模
在进行用例建模之前，我们首先了解到用例模型描述的是外部执行者（Actor）所理解的系统功能。
它主要用于需求分析阶段，它的建立是系统开发者和用户反复讨论的结果，表明了开发者和用户对需求规格达成的共识。
它的重要作用对于我们住院管理系统的分析和设计主要体现在以下几个方面：
首先，它描述了待开发系统（住院管理系统）的功能需求；
其次，它将系统看作黑盒，从外部执行者的角度来理解系统；
再次，它驱动了需求分析之后各阶段的开发工作，不仅在开发过程中保证了系统所有功能的实现，而且被用于验证和检测所开发的系统，从而影响到开发工作的各个阶段和UML的各个模型。
从本质上讲，一个用例是用户与计算机之间的一次典型交互作用。
在UML中，用例被定义成系统执行的一系列动作，动作执行的结果能被指定执行者察觉到。
几乎在任何情况下都会使用用例。
用例用来获取需求，规划和控制项目。
用例的获取是需求分析阶段的主要任务之一，而且是首先要做的工作。
大部分用例将在项目的需求分析阶段产生，并且随着工作的深入会发现更多的用例，这些都应及时增添到已有的用例集中。
2.3.1确定参与者
在分析过程开始的时候，我们考虑到获取用例首先要找出系统的执行者。
，有鉴于此，我们通过用户回答一些问题的答案来识别执行者。
1.谁使用系统的主要功能（主要使用者）。
2.谁需要系统支持他们的日常工作。
3.谁来维护、管理使系统正常工作（辅助使用者）。
4.系统需要操纵哪些硬件。
5.系统需要与哪些其它系统交互，包含其它计算机系统和其它应用程序。
6.对系统产生的结果感兴趣的人或事物。
通过回答这六个问题以后，再进一步分析可以识别出本系统的四个角色：
采购员、系统管理员、超市经理、库存管理员。
2.3.2确定用例
在对现行住院管理系统的分析过程中，在我们获取了执行者之后，我们就对每个执行者提出以下问题以获取用例。
1.执行者要求系统提供哪些功能（执行者需要做什么）。
2.执行者需要读、产生、删除、修改或存储的信息有哪些类型。
3.必须提醒执行者的系统事件有哪些，或者执行者必须提醒系统的事件有哪些，怎样把这些事件表示成用例中的功能。
4.为了完整地描述用例，还需要知道执行者的某些典型功能能否被系统自动实现。
除了以上考虑到的问题之外，我们还考虑了一些不针对具体执行者问题（即针对整个系统的问题），以使自己的分析结果更加准确。
1.系统需要何种输入输出，输入从何处来，输出到何处。
2.当前运行系统（也许是一些手工操作而不是计算机系统）的主要问题。
因为系统比较大，因此不可能给出全部的分析过程，因此列举出在采购分系统中一部分比较有代表性的过程。
通过分析可以初步识别出系统的用例为：
登陆管理、信息查询、信息修改、订购管理、请购管理、合同管理、商品信息管理、商品入库管理、用户管理、添加商品信息、删除商品信息、修改商品信息。
2.3.3系统用例建模
针对超市采购系统的流程的分析，我们采用的是面向对象的分析方法（OOA）。
使用用例图来描述参与者与外部用户所能观察到的系统功能的模型图，在此模型中列出了系统中的用例和参与者，并显示哪个参与者参与了哪个用例的执行。
用例图如下图2-1所示。
图2-1用例图
2.3.4用例描述
1.请购管理
概述：
该用例说明请求订购的过程。
前置条件：
仓库管理员提交库存不足商品列表。
后置条件：
建立请购单商品详细信息。
实现过程：
（1）仓库管理人员提交库存不足商品列表
（2）采购员根据仓库人员提交的列表进行请购单的编制。
（3）对请购单中商品的订购数量、价格等详细信息进行记录。
（4）对请购单的信息进行添加、删除、修改。
（5）生成最终的请购单。
2.订购管理
概述：
该用例用来说明订购商品的过程。
前置条件：
超市经理批准请购单。
后置条件：
生成订购单，联系供货商。
实现过程（事件流）：
（1）.根据请购单进行订购单的编制。
（2）.书写合同。
（3）联系供货商。
3.合同管理
概述：
该用例说明采购方与供货方进行的纸上协议。
前置条件：
订货单生成。
后置条件：
供货商签订合同。
实现过程（事件流）：
（1）.根据订购单制定相应的合同。
（2）.将合同交予供货商。
（3）.签订合同。
（4）.供货方根据合同催款。
（5）.对合同进行记录。
4用户管理
概述：
系统管理员对登录系统人员的管理。
前置条件：
用户申请登录。
后置条件：
用户登录界面。
实现过程：
用户登录前需经系统管理人员的审核，信息无误即可登录界面。
第3章系统分析
第3章系统分析
3.1系统用例建模
3.1.1超市采购管理子系统
超市采购管理子系统是指由请购单管理、订购单管理、合同管理、资金请求管理与系统管理构成。
下面分别对请购单管理、订购单管理与合同管理进行详细用例描述：
请购单管理如下图3-1所示。
图3-1请购单管理用例图
订购单管理用例图如下图3-2所示。
图3-2订货单管理用例图
合同管理用例图如下图3-3所示。
图3-3合同管理用例图
3.1.2详细用例描述
表3-1形成请购单
用例名称
形成请购单
标识符
UC01
用例描述
对需要采购的商品生成请购信息
参与者
采购员
前置条件
仓库管理员
后置条件
经理审批
基本操作流程
采购员针对仓库管理员的提交列表对库存不足的商品进行详细记录
表3-2审批请购单
用例名称
审批请购单
标识符
UC02
用例描述
对请购单进行审批
参与者
超市经理
表3-3生成订购单
用例名称
生成订购单
标识符
UC03
前置条件
审批请购单合格
后置条件
生成合同
基本操作流程
对请购单进行补充完整，添加供货商等详细信息
表3-4合同管理
用例名称
合同管理
标识符
UC06
用例描述
生成采购方与供货方签订的合同
参与者
采购员、供货方
前置条件
订购单完成
后置条件
供货方发货
基本操作流程
针对采购方与供货方编制合同，双方签订后进行记录存档
3.2静态结构模型
3.2.1类的识别
首先对超市采购管理子系统的需求进行分析：
库存管理人员根据库存信息提交需要采购的商品信息，采购员根据库存人员的要求进行请购单的编写，然后将最后生成的采购单上交给超市经理进行审批，经理审批合格后采购员生成订购单，并联系供货商，采购员根据订购单生成合同，采购方与供货方无异议后签订合同，供货方发货，采购员收到货物根据合同向财务部申请采购资金，财务人员拨款，财务部门向供货商付款，采购员合计部门资金余额，通知库存部门取货，记录采购信息。
1找出候选的类与对象在该需求中可以找出如下名词：
库存管理人员、库存信息、商品信息、信息、采购员、库存人员、请购单、超市经理、订购单、供货商、合同、财务部、资金、财务人员、库存部门、余额、采购信息。
2筛选出正确的类与对象
（1）冗余库存管理人员、库存人员和库存部门表达了同样的信息，所以只保留库存管理员；财务部与财务部门冗余，保留财务部门。
（2）笼统信息是泛指名词，应去掉。
（3）属性资金、余额、商品信息与采购信息是描述对象的属性，应去掉。
综上所述，在超市采购管理子系统中，经初步筛选，剩下的类与对象有：
库存管理人员采购员、请购单、超市经理、订购单、供货商、合同与财务部门。
3.2.2类的关联分析
超市采购管理子系统的对象和类已经初步识别了出来，随后通过提取动词词组初步得出它们之间的关联，通过分析前文中的需求陈述可以找出陈述中隐含的关联，经过分析之后，初步确定出下列关联：
1库存管理人员向采购员提交需采购商品信息
2采购员整理商品信息
3采购员制定请购单
4超市经理审批请购单
5采购员制定订购单
6采购员联系供货商
7采购员制定合同
8供货商得到合同
9采购员签订合同
10供货商签订合同
11采购员向财务部门申请采购资金
12财务部门向供货商付款
13采购员核算部门资金
14采购员记录采购信息
然后去掉已筛选的类之间的关联与和问题无关的或在实现阶段考虑的关联，最终确定的关联如下：
1库存管理人员向采购员提交需采购商品信息
2采购员制定请购单
3超市经理审批请购单
4采购员制定订购单
5采购员联系供货商
6采购员制定合同
7供货商得到合同
8采购员签订合同
9供货商签订合同
10采购员向财务部门申请采购资金
11财务部门向供货商付款
3.2.3类的属性描述
属性是对象的性质，通过对象类和结构有更深入，更具体的认识。
一般来说确定属性的过程包括分析和选择两个步骤。
属性的确定既与问题有关，也和目标系统的任务有关。
应该仅考虑与具体应用直接相关的属性，不要考虑那些超出所要解决的问题范围的属性。
在分析过程中应该首先找出最重要的属性，以后在逐渐把其余属性添加进去。
此次分析过程中，我们在分析阶段没有考虑那些纯粹用于实现的属性。
只是在最后认真考察了经初步分析而确定下来的那些属性，从中删掉了那些不正确的或不必要的属性。
部分对象类的属性描述如下：
商品信息——商品名称、商品编号、商品单价、商品厂商、商品数量.
采购信息——采购日期、采购金额、供货商名称、采购商品.
余额——日期、金额.
3.2.4类图的构建
超市采购管理子系统类图入下图3-4所示。
图3-4超市采购管理类图
3.3系统动态模型
3.3.1系统执行顺序分析
顺序图是一种交互图，常用来描述一个用例的行为，超市采购管理子系统中采购员的顺序图分析如下：
采购员接收仓库管理人员的提交列表，进行请购单的编制，然后上交超市经理进行审批，合格后采购员制定订购单，联系供货商，签订合同，并将采购金额交给财务部门。
采购员顺序图如下图3-5所示。
图3-5采购顺序图
根据对用户登录用例的分析，实现用户登录有以下说明：
（1）系统提示输入账号密码
（2）用户输入账号和密码
（3）系统查询登陆者信息
（4）登录信息正确，返回登陆成功
用户登录成功
超市采购管理子系统的登录顺序图如下图3-6所示。
图3-6登录顺序图
3.3.2系统的协作分析
协作图用于描述相互合作的对象间的交互关系，它描述的交互关系是对象间的消息连接关系。
以采购员为例，采购员接收仓库管理人员的提交列表，进行请购单的编制，然后上交超市经理进行审批，合格后采购员制定订购单，联系供货商，签订合同，并将采购金额交给财务部门。
采购协作图如下图3-6所示。
图3-7采购协作图
针对超市采购管理子系统用户登录系统的协作图有如下说明：
用户登录窗口，系统提示输入账号密码，系统验证注册信息是否存在，向数据库发送验证信息，若不存在则添加注册信息并返回注册结果，若存在则返回登录成功并返回用户。
登录协作图如下图3-8所示。
图3-8登录协作图
3.3.3系统状态分析
状态图描述了事件和对象状态的关系。
以采购员为例，采购员制定请购单，审批合格后订订购单，生成订购单后根据订购单编写合同，生成有效合同后进行签订，并自动生成合同编号，最后提醒财务部门进行付款。
采购员状态图如下图3-9所示。
图3-9采购员状态图
3.3.4活动分析
活动图是由状态图转化而来的，它描述了系统中各种活动执行的顺序，刻画了一个系统中所要进行的各项活动的执行流程。
根据上文中绘制得出的顺序图以及合作图，对两图中相互交互的对象进行分析可以得出系统主要的活动如下：
（1）统计订货商品：
由库存部门提出要求进行订货商品的统计。
（2）生成请购单：
填写请购单，添加、删除、修改相关信息，生成最后的请购单。
（3）审批：
将最后生成的请购单交给超市经理进行审批。
采购员活动图如下图3-10所示.
图3-10采购员活动图
系统设计与实现
第4章系统设计与实现
4.1UML体系结构设计
超市采购管理子系统采用面向对象技术对系统进行总体的设计和实现，用UML及其集成环境RationalRose对系统进行分析和建模，采用PowerBuilder’s完成组件平台建设，后端数据存储是当前流行的Oracle9i数据库。
本系统基于PowerBuilder’s构建三层C/S结构，数据库服务器运行数据库管理系统软件，COM+组件运行在应用服务器上，客户机运行超市管理系统客户端软件。
4.1.1硬件体系结构设计
客户机戴尔
数据库服务器interE5300
CPU
超市管理系统
图4-1硬件体系结构图
4.1.2软件体系结构设计
信息系统的软件结构是由信息系统软件的各子系统按照确定的关系构成的结构框架，一般呈现多层次结构模式。
子系统是对软件进行分解的一种中间形式，也是组织和描述软件的一种方法。
软件结构设计就是把软件分解成多个子系统，并确定各子系统及其接口之间的相互关系。
超市采购管理子系统的软件结构如图4-2所示。
用户
采购员
用户界面
采购信息
请购管理
数据库
商品信息
供货商信息
请购单信息
订购管理
订购单信息
合同管理
合同信息
系统管理
用户信息
用户层
用户界面层
应用层
数据库层
图4-2软件体系结构图
4.2对象模型设计
本系统根据对象模型设计原则，设计优化和结构求精的启发规则，建立了订购单管理、请购单管理等系统模块，同时建立了采购员、供货商、库存管理人员与超市经理等对象模型。
在采购员这个对象中，采购员根据商品信息，添加、修改、删除请购单。
在超市经理这个对象中，经理审核请购单是否批准。
在选课单这个对象中，生成课程表，供用户查询。
在供货商这个对象中，签订合同并催款。
经分析，该系统的对象模型如图4-3所示。
图4-3系统对象模型
4.3系统实现
本章使用UML建模技术，对住院管理系统进行了建模设计，使的开发出的产品在面对不同的客户时方便修改和维护，大大减少了投入的人力和时间，同时大大缩小了产品的成本。
在UML中，描述实现的视图称为组件视图。
它对模型中的组件建模，描述应用程序搭建的软件单元以及组件之间的依赖，从而可以估计更改的影响。
它还对类及其他元素在组件中的分配建模。
布局视图包括组件图、配件图以及配置图，他们分别从不同的角度反映并显示了本系统的软件和硬件的物理配置。
4.3.1组件分析
组件可以看作包与类对应的物理代码模块，逻辑上与包、类对应，它实际上是一个文件，可以有源代码构件、二进制构件、可执行构件。
构件对外提供的可见操作和属性称为构件的界面。
在UML中，组件图描述了组件及组件之间的关系，表示了组件之间的组织和依赖关系。
组件图是用来为面向对象系统的物理方面建模的图形之一。
经过分析，超市采购管理子系统的组件图如图4-4所示。
图4-4系统组件图
4.3.2配置分析
配置图用来描述系统硬件的物理拓扑结构以及在此结构上执行的软件，即系统运行时刻的结构。
可以显示计算机结点的拓扑结构和通信路径，结点上执行的软构件，软构件包含的逻辑单元等，特别对于分布式系统，配置图可以清楚的描述系统中硬件设备的配置，通信以及在各硬件设备上各种软构件和对象的配置。
配置图是描述任何基于计算机的应用系统的物理配置或逻辑配置的有力工具，住院管理子系统的配置图如图4-5所示。
数据库服
升级会员 