珠宝管理销售系统软件建模与分析

经济与管理学院经济与管理学院 软件分析与建模软件分析与建模综合实验周报告综合实验周报告 （2013/2014 学年 第一学期） 学生姓名：学生姓名： 朱志喆 专业班级：专业班级： 信管 112001 班 学学生生学学号号： 201120020128 指导教师指导教师： 武 妍 2013 年 12 月 27 日 珠宝销售系统珠宝销售系统财务管理财务管理 目目 录录 第一章 系统概述.1 1.1 整体系统概述.1 1.1.1 系统开发背景1 1.1.2 系统开发的意义2 1.1.3 系统的可行性分析2 1.1.4 系统功能2 1.2 本人所做工作.3 第二章 业务建模.4 2.1 财务管理的业务介绍.4 2.1.1 设置期初4 2.1.2 结账4 2.1.3 现金上交5 2.1.4 欠款单据5 2.1.5 收支查询6 2.2 财务管理业务模型的建立.6 2.2.1 设置期初的业务流程图6 2.2.2 现金上交的业务流程图7 2.2.3 欠款单据的业务流程图7 第三章 数据建模.8 3.1 概念数据模型.8 3.1.1 概念数据模型的描述8 3.1.2 概念数据模型的建立9 3.1.3 概念数据模型之间的联系.10 3.2 物理数据模型11 3.2.1 物理数据模型的描述.11 3.2.2 物理数据模型的建立.11 第四章 应用程序建模13 4.1 应用程序建模描述13 4.2 用例图14 4.3 类图14 总结.17 参考文献.18 第一章 系统概述 1.1 整体系统概述 1.1.1 系统开发背景 在我国很多商业企业是通过一套人工单据流转程序来实现信息流对商品流 的跟踪，通过财务库存资金账来控制进销过程；通过仓库账来核查物流过程； 通过定期盘点对账来调整账目和商品的损益。由此造成物流、款流、票据流分 离，财务信息滞后实际业务，所以只有通过盘点才能较准确的了解经营情况。 而对各类票据、供销单位、应收、应付款等信息查找困难，易出差错，商品进、 销、存数量及金额记录统计量工作大，不准确，各类经营统计数据严重滞后实 际业务需要，现代商业的迅猛发展，对手工管理模式提出了严峻挑战，商品品 种日益丰富，流行周期越来越短，企业活动节奏加快，调价、削价、移库等各 种情况，信息量大、变化加快、赊账、代销、折让、退换等方式频繁应用，这 些都增加经营管理中的结算和统计难度，手工管理难以完全胜任。在现代化大 工业、大生产的组织原则应用于流通领域，更需要用现代化的手段使其管理思 想真正的得以实现。近几年来，随着计算机的发展与完善，其在商品流通领域 中的应用越来越广泛，因而，用计算机建立一种准确、及时、高效、操作方便、 易于掌握的商品进销存数据管理系统是非常必要的。 由于珠宝经营涉及多个环节，而且种类繁多，款式多样，大多需要单件管 理，因此操作量巨大，在经营过程中容易出错。珠宝属于贵重物品，体积小， 价格高，如果管理跟不上，一旦造成商品丢失，将给经营者造成巨大损失，而 计算机管理可以大幅度提高日常管理效率，每一款珠宝从入库就开始由计算机 自动赋予唯一编号，跟随该珠宝做完出货和销售的全过程。在此过程中，只需 要输入商品编号，即可显示商品的详细信息、不仅可以提高工作效率，也大大 减少出错的可能，为经营者提供了切实可靠的依据。 1.1.2 系统开发的意义 此系统的开发大大解放了劳动力，提高了工作效率，并且全面、及时、准 确的提供进销存信息，避免了由于人工而出现的各种错误。 1 1.1.3 系统的可行性分析 (1) 技术可行性 随着计算机的发展，越来越多的程序员都掌握了很多面向对象的程序设计 语言，再加上计算机本来的硬件方面的发展，实现系统在技术这方面是可行的。 (2) 经济可行性 由于系统是作为毕业设计由我们学生自己开发的，在经济上的投入甚微， 系统建成之后将为今后珠宝销售管理提供很大的方便，因此在经济上是可行的。 (3) 操作可行性 只要各管理员熟练计算机的应用方法，掌握计算机的基本操作技能，而且 对珠宝管理系统有初步的认识就足以进行操作，因此在操作上也是可行的。 1.1.4 系统功能 珠宝管理系统由系统管理模块、系统维护模块、进货管理、销售管理模块、 库存管理模块、查询统计模块、财务管理模块七大模块组成。系统功能模块图 如图 1.1 所示。 珠 宝 管 理 系 统 系统管理模块 系统维护模块 进货管理 销售管理 库存管理 查询统计管理 财务管理 图 1.1 珠宝管理系统的功能模块图 2.1 本人所做工作 我们小组这次做的是珠宝管理系统中的财务管理模块，此模块包括：设置 期初、结账、现金上交、欠款单据及收支查询。作为一个财务管理系统来说， 它的一些功能是借助于其它的功能模块来实现的。珠宝销售系统中的的财务管 理模块就依赖于销售管理模块、库存管理模块、查询统计管理等模块，有一些 表格也是涉及到的，这在报告的第三章具体介绍。 3 第二章 业务建模 2.1 财务管理的业务介绍 2.1.1 设置期初 期初金额是一个重要数据，销售额是否准确很大程度上是取决于这个数据 录入的是否准确。期初金额指用户每月提前预留的现金额，用户必须在每月之 初设置期初金额，以保证销售额的计算正确。功能效果如图 2.1 所示。 图 2.1 设置期初功能效果图 2.1.2 结账 结账是在每月月底将所有业务产生的金额汇总上交，结账完毕后影响下个 月的期初金额。期初金额=期初+（现金合计+退货合计+兑换销售+其他收入）- （回收金额+退货金额+其它支出）-上交金额。功能效果如图 2.2 所示。 图 2.2 结账功能效果图 2.1.3 现金上交 销售人员每到月底结账时，对本周期的每一笔业务进行汇总。现金上交详 细统计了各销售业务产生的销售金额，并统计出需要上交现金的总金额。用户 填写好上交金额后，即可将现金上交给财务部门，并更新数据库。功能效果如 图 2.3 所示。 图 2.3 现金上交功能效果图 2.1.4 欠款单据 欠款单据统计日常业务操作中没有正常结算的业务信息，用户通过此模块 可以了解何时、何人、何种业务产生的欠款和欠款金额，并可将欠款金额续交。 功能效果如图 2.4 所示。 5 是 否 是否修改期初 设置财务月份为当前月 填写期初金额 根据当前月份获取期初金额 更新数据库 图 2.4 欠款单据功能效果图 2.1.5 收支查询 按照时间段，根据收支属性分类显示所有业务类型，按照业务类型分类汇 总每项的收支金额。功能效果如图 2.5 所示。 图 2.5 收支查询功能效果图 2.2 财务管理业务模型的建立 2.2.1 设置期初的业务流程图 无 有 否 是 日志记录 从销售主表中查找没有结算的销售单据 选择结账单据 有无选择单据 欠款单据结算，并修改数据库 填写收款金额 结算 收款金额是否小于欠款金额 图 2.6 设置期初的业务流程图 2.2.2 现金上交的业务流程图 图 2.7 现金上交的业务流程图 2.2.3 欠款单据的业务流程图 7 图 2.8 欠款单据的业务流程图 第三章 数据建模 3.1 概念数据模型 3.1.1 概念数据模型的描述 数据模型是现实世界中数据特征的抽象。数据模型应该满足三个方面的要 求： 1）能够比较真实地模拟现实世界； 2）容易为人所理解； 3）便于计算机实现； 概念数据模型也称信息模型，它以实体联系(简称 E-R)理论为基础，并 对这一理论进行了扩充。它从用户的观点出发对信息进行建模，主要用于数据 库的概念级设计。 通常人们先将现实世界抽象为概念世界，然后再将概念世界转为机器世界。 换句话说，就是先将现实世界中的客观对象抽象为实体(Entity)和联系 (Relationship),它并不依赖于具体的计算机系统或某个 DBMS 系统，这种模型 就是我们所说的 CDM;然后再将 CDM 转换为计算机上某个 DBMS 所支持的数 据模型，这样的模型就是物理数据模型,即 PDM。 CDM 是一组严格定义的模型元素的集合，这些模型元素精确地描述了系统 的静态特性、动态特性以及完整性约束条件等，其中包括了数据结构、数据操 作和完整性约束三部分。 1）数据结构表达为实体和属性； 2）数据操作表达为实体中的记录的插入、删除、修改、查询等操作； 3）完整性约束表达为数据的自身完整性约束（如数据类型、检查、规则等） 和数据间的参照完整性约束（如联系、继承联系等） ； 3.1.2 概念数据模型的建立 （1）结账功能的概念数据模型,cwShopAllDate 表(各店面的财务信息表)如图 3.1 所示。 图 3.1 结账功能的概念数据模型 （2）欠款单据功能的概念数据模型，涉及到 SalesOrder(销售主表)，如图 3.2 所示。 图 3.2 销售主表的概念数据模型 （3）收支查询功能的概念数据模型，涉及到 SZML(收支项目字典表)、 SZDetail(收支明细表)，如图 3.3、3.4 所示. 图 3.3 收支项目字典表 9 图 3.4 收支明细表 3.1.3 概念数据模型之间的联系 （1）欠款单据功能的概念数据模型之间的联系（注：因为此功能牵涉到系统中 的其他功能，这里只是一部分，主要涉及到 ReturnedPurchase(退/换货主表)、 SalesOrderItem(销售明细表)、SalesOrder(销售主表)）如图 3.5 所示。 图 3.5 欠款单据功能的概念数据模型之间的联系 （2）收支查询功能的概念数据模型之间的联系如图 3.6 所示。 图 3.6 收支查询功能的概念数据模型之间的联系 3.2 物理数据模型 3.2.1 物理数据模型的描述 物理数据模型（Physical Data Model）PDM，提供了系统初始设计所需要的 基础元素，以及相关元素之间的关系。即用于存储结构和访问机制的更高层描 述，描述数据是如何在计算机中存储的，如何表达记录结构、记录顺序和访问 路径等信息。使用物理数据模型，可以在系统层实现数据库。数据库的物理设 计阶段必须在此基础上进行详细的后台设计，包括数据库的存储过程、操作、 触发、视图和索引表等； 3.2.2 物理数据模型的建立 （1）欠款单据功能的物理数据模型的建立（注：因为此功能牵涉到系统中的其 他功能，这里只是一部分，主要涉及到退/换货主表、销售明细表、销售主表） 如图 3.7 所示。 11 图 3.7 欠款单据功能的物理数据模型 （2）收支查询功能的物理数据模型的建立如图 3.8 所示。 图 3.8 收支查询功能的物理数据模型 第四章 应用程序建模 4.1 应用程序建模描述 所谓应用程序建模就是面向对象建模。面向对象模型是一种新兴的数据模 型，它采用面向对象的方法来设计数据库。面向对象的数据库存储对象是以对 13 象为单位，每个对象包含对象的属性和方法，具有类和继承等特点。 4.2 用例图 用例图是对包括变量在内的一组动作序列的描述，系统执行这些动作并产 生传递特定参与者的价值的可观察结果，用例图的作用主要有：获取需求，指 导测试，对其他工作流起到指导作用。用例图是从用户的角度来收集需求。财 务管理子系统的用例图如图 4.1 所示。 图 4.1 财务管理子系统的用例图 4.3 类图 类图可由 CDM 图转化而成。其中本子模块的类图即是有退换货及单据作废 模块的 CDM 图转化而成。具体如下： （1）欠款单据功能的类图如图 4.2 所示 图 4.2 欠款单据功能的类图 （2）收支查询功能的类图如图 4.3 所示。 15 图 4.3 收支查询功能的类图 总结 这次的软件分析与建模实验通过两周的时间，虽然时间紧迫，强度和工作 量和企业相比微不足道，但是通过自己努力的去实践，从理论阶段步入实践层 面，无疑也是一种突破。在本系统开发的过程中，我全面实践一个软件分析与 建模综的设计过程，学习很多有关的知识。这样的项目对我们学过的软件分析 与建模课程是一个综合性很高的实践。一些以前没有学得很扎实的课程内容， 由于需要在实践中运行，刚开始我也感到头痛，但回过头来再去看教课书，在 网上搜集资料，经历着一段时间的实践，对于这些知识点有关的背景，概念和 解决方案理解得更透彻了，学习起来也越来越有兴趣，越来越轻松。最主要的， 通过努力做出个东西，多少会有点成就感。 另外我还充分体会了从事系统开发工作需要特别谨慎认真地态度和作风， 一点都不能马虎。每个细微的细节都必须十分注意，如果不认真思考决策，就 会出现或大或小的错误。如果早期的错误隐藏下来，对后面的工作影响就会很 大，甚至有时会推倒很多前面做的工作重来。所以，必须怀着严谨的作风，绝 不允许投机取巧。在实验中，会经常遇到一些问题