为了正常的体验网站,请在浏览器设置里面开启Javascript功能!

进销存系统

2017-09-01 15页 doc 79KB 54阅读

用户头像

is_421808

暂无简介

举报
进销存系统进销存系统 进销存系统用例建模案例 1.案例研究目标 本案例通过对进销存系统进行用例建模,目的是使学生了解用例建模的基本思想方法, 学会从系统外部定义系统功能,能够根据系统需求识别适当的系统参与者和用例,掌握用例 建模的基本步骤。 用例方法完全是站在用户的角度上(从系统的外部)来描述系统的功能的。在用例方法 中,我们把被定义系统看作是一个黑箱,我们并不关心系统内部是如何完成它所提供的功能 的。用例方法首先描述了被定义系统有哪些外部使用者(抽象成为 Actor),这些使用者与 被定义系统发生交互;针对每一参与者,用例方法...
进销存系统
进销存系统 进销存系统用例建模案例 1.案例研究目标 本案例通过对进销存系统进行用例建模,目的是使学生了解用例建模的基本思想方法, 学会从系统外部定义系统功能,能够根据系统需求识别适当的系统参与者和用例,掌握用例 建模的基本步骤。 用例方法完全是站在用户的角度上(从系统的外部)来描述系统的功能的。在用例方法 中,我们把被定义系统看作是一个黑箱,我们并不关心系统内部是如何完成它所提供的功能 的。用例方法首先描述了被定义系统有哪些外部使用者(抽象成为 Actor),这些使用者与 被定义系统发生交互;针对每一参与者,用例方法又描述了系统为这些参与者提供了什么样 的服务(抽象成为 Use Case),或者说系统是如何被这些参与者使用的。所以从用例图中, 我们可以得到对于被定义系统的一个总体印象。 与传统的功能分解方式相比,用例方法完全是从外部来定义系统的功能,它把需求与设 计完全分离开来。在面向对象的方法中,用例模型主要用于表述系统的功能性需 求, 系统的设计主要由对象模型来表述。 2.案例简介——超市进销存系统的需求调查 1、 销售: 售货员接受顾客订购,输入顾客购买的商品,计算 总价 顾客付款并接受清单 售货员保存顾客购买的商品 记录 2、 库存: 库存管理员每天进行 盘点 库存管理员每天发现库存商品有损坏时,及时到相关部门报损 在供应商的商 品到货时,潮湿人员首先检查商品是否合格,并将合格的商品入 库处理 经 理、统计分析员根据需要进行相关商品的模糊查询或详细查询 3、 订货: 订货员用新商品供应商信息更新供应商数据库的信息 订货员统计库存商品是否低于库存下限,然后制作订货单 4、 统计: 经理在促销期间或节日期间,注明相关商品的促销价格和 手段 经理按市场情况经常变动商品价格 3. 案例分析 构造需求用例模型的目的是分析和提取足够的需求信息,创建用例模型。本案例中,首 先要找出系统的主要用例,进行用例建模。模型从用户的角度表示系统需要实现什么;不涉 及系统如何构造和实现的具体细节。用例建模的步骤如下: 1. 确定业务参与者. 2. 确定业务需求用例. 3. 构造用例模型图. 4. 记录业务需求用例描述. 3.1 确定系统参与者 所谓的参与者是指所有存在于系统外部并与系统进行交互的人或其他系统。通俗地讲, 参与者就是我们所要定义系统的使用者。寻找参与者可以从以下问入手: 系统开发完成之后,有哪些人会使用这个系统? 系统需要从哪些人或其他系统中获得数据? 系统会为哪些人或其他系统提供数据? 系统会与哪些其他系统相关联? 系统是由谁来维护和管理的? 本系统按照业务功能分成订货、销售、库存和统计四部分,这些职能对应不同的组织 部 门。超市服务的对象是顾客,系统内部员工可按照组织部门人员的职能分类,分别是订 货人 员、销售员、库存管理员、统计分析员等。因此,可以初步识别该系统的主要参与者 为:顾 客、订货人员、销售员、库存管理员、统计分析员。如图 1 所示: 员工 顾客 管理员 员工 库存管理员 统计分析员 订货员 图 1 系统的主要参与者 3.2 确定业务需求用例 找到参与者之后,我们就可以根据参与者来确定系统的用例,主要是看各参与者需要 系 统提供什么样的服务,或者说参与者是如何使用系统的。寻找用例可以从以下问题入手 (针 对每一个参与者): 参与者为什么要使用该系统? 参与者是否会在系统中创建、修改、删除、访问、存储数据?如果是的话,参与者 又是如何来完成这些操作的? 参与者是否会将外部的某些事件给该系统? 系统是否会将内部的某些事件通知该参与者? 结合本系统,可以识别主要用例如下:销售管理、库存管理、统计查询、订货管理、 身 份验证等主要用例。 3.3 构造用例模型图 在识别了参与者和主要用例后,可以绘制用例图。用例图只是在总体上大致描述了系 统 所能提供的各种服务,让我们对于系统的功能有一个总体的认识。 本系统的主要用例图如下: 1.系统顶层用例图 图[B] 是系统顶层用例图。 销售管理 员工 顾客 订货管理 订货员 库存管理员 库存管理 统计查询 统计分析员 身份验证 员工 图[B] 超市内部的员工每个人有相应的操作权限。这种分工、权限和人正是超市组织人事管 理 的一部分。每个人必须接收系统的认证后才能实施自己的相关职能。 2.销售管理子系统用例图 如图[C] 提取商品信息 <> 订货员 更新商品信息 <> <> 更新销售信息 <> 顾客 打印购物清单 计价 图[C] 3.订货管理子系统用例图 如图[D]所示 <> 订货员 统计订货商品 <> 订货管理 制作订单 图[D] 4.库存管理子系统用例图 如图[E]所示 处理盘点 更新供应商信息 <> 处理报损 <> 商品基本信息修改 订货员 <> 管理设置 特殊商品属性设置 商品入库 图[E] 5.统计分析子系统用例图 如图[F]所示: 查询商品基本信息 查询销售信息 查询供应商信息 统计分析员 查询缺货信息 查询报损信息 查询特殊商品信息 图[F] 6.身份验证子系统用例图 如图[G]所示: <> 员工 修改员工信息 <> 身份验证 找回密码 图[G] 3.4 记录业务需求用例描述 这里注意,用例图不等同于用例建模。用例图只是在总体上大致描述了系统所能提供的 各 种服务,让我们对于系统的功能有一个总体的认识。在用例图的基础上,还需要对用例进 行描 述,记录用例本身的业务需求和逻辑。以销售管理子系统用例为例,该子系统的详细描 述见下表[1]: 表[1] 用例 1 用例名称 提取商品信息 说明 售货员将条形码输入系统,系统根据此码查询并返回商品信息 参与者 售货员 基本操作流程 售货请求——输入条形码——系统查询并返回相关的商品信息 可选操作流程 输入条形码信息——条形码信息出错 扩展的用例 用例“更新商品信息”,“更新销售信息” 用例 2 用例名称 打印购物清单 说明 售货员完成购买商品的输入,形成购买商品的清单,如顾客同意付款,进入打 印购物清单用例。该用例接收顾客付款,计算余额,打印清单。 参与者 售货员 基本操作流程 购买清单——计算总价——输入顾客付款——计算余额——打印清单 可选操作流程 顾客拒绝付款,取消购买 扩展的用例 包含“计价” 订货管理子系统的详细描述见下表[2]: 表[2] 用例 1 用例名称 订货管理 说明 系统首先根据用户提交的请求进行仓库缺货查询,然后将查询的统计结果 制定成单打印出来 参与者 订货员 基本操作流程 提交查询请求——系统查询并返回缺货信息——用户提交订单打印请求—— 打印订单 可选操作流程 提交查询请求——系统查询发现仓库无或缺货——返回首界面 用例 2 用例名称 制作订单 说明 系统根据供应商提交的请求将仓库缺货的结果进行编辑,添加需要的属性从而 制作成单 参与者 订货员 基本操作流程 供应商提交请求——系统编辑缺货信息——系统将编辑结果根据供应商的要 求进行打印 可选操作流程 供应商提交请求——系统查询无货信息——仓库无缺货返回初始界面 被包含的用例 用例“订货管理” 库存管理子系统的详细描述见下表[3]: 表[3] 用例 1 用例名称 处理盘点 说明 库存管理员在每天或者规定的相统间隔阶段都要进行销售信息盘点,以达到随 时掌握超市销售情况,并根据每天或季度销售情况,来决定超市订货的品种 参与者 库存管理员 基本操作流程 用户提交盘点请求——系统返回当天或规定阶段销售信息——体统将显示结 果根据用户需求打印 用例 2 用例名称 处理报损 说明 查实人员发现有库存商品损坏则报损。首先输入条形码,系统进行查询,将报 损商品写入报损表,同时修改商品的库存 参与者 库存管理员 基本操作流程 输入报损条形码——查询商品信息——系统写报损表——更改库存 可选操作流程 用户提交请求——系统查询报损商品信息——无此商品返回 用例 3 用例名称 商品入库 说明 商品到货时,检验是否合格,将合格的商品入库 参与者 库存管理员 基本操作流程 检验商品——输入商品信息,如果合格入库——入库信息 可选操作流程 检验商品——不合格——退货 被包含的用例 用例“管理设置” 用例 4 用例名称 特殊商品属性设置 说明 特殊商品促销降价,需要设置商品的信息来指定促销阶段、原因、价格等信息 参与者 经理或者库存管理员 基本操作流程 输入条形码——查询商品信息——修改相应的属性 可选操作流程 输入条形码——查询商品信息——无信息返回界面 被包含的用例 用例“管理设置” 用例 5 用例名称 查询缺货信息 说明 统计分析员了解库存情况,输入关键字进行查询或者进行模糊查询,系统查询 并返回查询结果 参与者 经理或者统计分析员 基本操作流程 输入关键字或提交模糊查询请求——系统查询缺货信息并返回信息 可选操作流程 输入关键字或提交模糊查询请求——系统查询缺货信息并返回信息——如无 相关信息则返回首页 身份验证子系统对进入的任何员工都要认证身份、确定权限。下表[4]是其详细描述: 表[4] 用例 1 用例名称 身份验证 说明 超市员工要进入系统的时候,首先要通过身份验证,验证成功后才能如愿进入 系统。系统根据员工输入的信息,与系统员工数据库连接验证,成功系统自动 查询验证员工的身份并进入相应的系统界面 参与者 各部门的员工 基本操作流程 输入员工信息——提取信息并验证——自动查询员工身份并进入相应界面 可选操作流程 输入员工信息——提取信息并验证——验证失败则提示重新输入员工信息 被继承的用例 用例“找回密码”,“修改员工信息” 用例 2 用例名称 修改员工信息 说明 系统员工想要修改员工信息的时候,首先要通过身份验证,验证成功后才能如 愿进行修改操作。系统根据员工输入的信息 ,与系统数据库连接验证,成功 后系统要求员工输入新的用户信息,然后将信息存储到数据库中 参与者 经理 基本操作流程 输入员工信息——系统验证旧员工的信息——输入新员工的信息——存储新 员工信息 可选操作流程 输入员工信息——系统验证旧员工的信息——验证失败——提示重新输入 用例 3 用例名称 找回密码 说明 系统员工忘记密码时,使用该用例 参与者 经理 基本操作流程 输入员工信息——系统弹出提示问题——输入答案——输入新员工信息—— 存储新员工信息 可选操作流程 输入旧员工信息——系统弹出提示问题——答错则返回初始界面 4. 案例总结 本案例通过对进销存系统的简要分析,建立了初步的用例模型。由于方便理解,这里 仅 列出了最基本的用例,表述参与者和用例之间的一般关系,即它们之间的通讯关联。 除此之外,我们还可以描述参与者与参与者之间的泛化(generalization)、用例和用例 之间的包含(include)、扩展(extend)和泛化(generalization)关系。利用这些关系来调整 已有的用例模型,把一些公共的信息抽取出来重用,使得用例模型更易于维护。但是在应用 中要小心选用这些关系,一般来说这些关系都会增加用例和关系的个数,从而增加用例模型 的复杂度。而且一般都是在用例模型完成之后才对用例模型进行调整,所以在用例建模的初 期不必要急于抽象用例之间的关系。 在一个用例模型中,如果参与者和用例之间存在着多对多的关系,并且他们之间的关 系 比较复杂,如果在同一个用例图中表述所有的参与者和用例就显得不够清晰,这时我们 可创 建多个用例图来分别表示各种关系。每个用例包都可以有一个独立的用例图来描述该 用例包 中所有的参与者和用例的关系。
/
本文档为【进销存系统】,请使用软件OFFICE或WPS软件打开。作品中的文字与图均可以修改和编辑, 图片更改请在作品中右键图片并更换,文字修改请直接点击文字进行修改,也可以新增和删除文档中的内容。
[版权声明] 本站所有资料为用户分享产生,若发现您的权利被侵害,请联系客服邮件isharekefu@iask.cn,我们尽快处理。 本作品所展示的图片、画像、字体、音乐的版权可能需版权方额外授权,请谨慎使用。 网站提供的党政主题相关内容(国旗、国徽、党徽..)目的在于配合国家政策宣传,仅限个人学习分享使用,禁止用于任何广告和商用目的。

历史搜索

    清空历史搜索